Bill Bumgarner

2004-11-16

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.

Comment on this post [ so far] ... more like this: [Mac OS X] ... topic exchange: [Mac OS X]

Ohio Redux

It looks like the Ohio votes will be recounted.

As I had written in an earlier post, my primary concern with this election was less about the outcome and more about the utter stupidity of the voting procedures that were deployed across the country.

The electronic voting machines are poorly designed and have an even worse implementation. Worse, many precincts had no idea how to deal with voters that wanted to use paper ballots. Thousands-- millions?-- of paper ballots were considered "provisional", and likely not counted, that should not have been. The problems were not unique to Ohio. Fortunately, Ohio had exhibited a number of the common problems and, as such, a recount in Ohio will help quantify the depth of the stupidity and help push along the effort to reform election procedures and equipment.

It would appear that shedding light upon the voting procedure itself is the primary motivation for the recount as the recount was triggered by actions taken by independent presidential candidates.

The recount will happen after the election results are certified. I wonder what would offically happen in the extremely unlikely event that the recount shows that Kerry won Ohio?

Comment on this post [ so far] ... more like this: [Politics] ... topic exchange: [Politics]