SubEthaEdit 2.1 released
SubEthaEdit 2.1 is now available. It now has a command line utility similar to BBEdit’s.
Once you install SubEthaEdit, add setenv EDITOR ‘/usr/bin/see -w’ to your shell environment. This will cause Subversion, CVS, and other programs to use SubEthaEdit for editing of commit messages and the like.
Very nice. Unlike BBEdit, SubEthaEdit offers spell checking as you type and proper emacs-like key bindings. Really, it is more the case the SEE uses the Cocoa text editing subsystem which provides those features automatically.
Update
map (a coding monkey) pontificated that adding the ‘-r’ flag (export EDITOR=’see -wr’ or setenv EDITOR ‘/usr/bin/see -wr’, depending on your shell of choice) will cause Terminal to return to the frontmost app after you are done editing the file. Nice!
Eric said:
I guess copying is one of the sincerest forms of flattery.
BTW Bill, BBEdit does have common emacs keybindings. Turn them on in “Editing: Keyboard”
Jumping out to a GUI based editor from the command line has been around for much longer than Mac OS X and probably longer than BBEdit’s entire existence. Emacs has supported this via gnuserv/gnuclient for many years. Specifically, when it was added, I don’t know. I do know that OpenStep had this in 1995 or 1996. I wrote a command line tool called tedit that talked via distributed objects to TextEdit. It also supported client/server editing over the Internet. I used it to edit content on colo’d servers from my office desktop.
Secondly, BBEdit’s emacs keybindings do not behave like Emacs. In particular, BBEdit’s notion of “end of line” is the end of the visible line in the editing window. Emacs defines the end of the line as the newline at the end of the paragraph. So, all cursor motion and copy/paste features that depend on the definition of end of line work completely differently in BBEdit than they do in emacs. Not just differently, but BBEdit’s definition of “end of line” renders the commands useless — this isn’t a “just relearn the behavior” problem. For example, if the cursor is one character before the end of the first line of a multiline paragrah, the user would have to hit ctrl-k one time for every character between the cursor and the paragraph ending newline to yank the rest of the paragraph. Not only is this potentially hundreds of keystrokes (compared to one in emacs), but it means that you can’t reliably put everything between the cursor and the end of the paragraph into a yank buffer to be moved elsewhere via ctrl-y.
Now, don’t misinterpret any of this as an attack of BBEdit. I have watched someone who believes in the BBEdit way do amazingly powerful stuff with the application. It is simply the case that I follow the emacs way of editing text, which is incompatible with BBEdit. Fortunately for me, Cocoa’s text editing subsystem also follows the emacs way (likely because the original developers of the AppKit used emacs) and, as a Cocoa App, SubEthaEdit (and TextEdit, for that matter) offer a text editing experience that is compatible with my text editing muscle memory.