The role of a command shell is to give you more control over what

your computer does for you.  Not everyone needs this amount of control,

and it does come at a cost: Learning the necessary script commands to

express what you want done… But if you find yourself using your

computer frequently enough, it is more than worthwhile in the long run.

Any tool you use often deserves the time spent learning to master it.

Emphasis mine.  Optimizing for a beginner is a huge mistake, in my opinion.  Sure, if you want to make a lot of money in this early stage of computer development, when adoption isn't very high yet, then it makes sense to optimize the entire experience for beginners.  But in the long haul, we will develop a population of experienced users, not beginners.  And once the average users has not years, but decades of experience with computers, shouldn't we admit that any tool you use that much deserves the time spent learning to master it?  And, given that you are going to master a tool, it makes sense to choose a tool worthy of your time.  That should be the analysis new users should be making, rather than seeing how much they can get done in the first 15 seconds using the system.

So-called “modern desktop environments” converge on total unusability, and present-day mainstream graphical user interfaces in general are far less usable than they are praised to be. Usability simply does not equal low learning curve, and hiding system details from the user, as the Official Truth seems to be these days.

He was right.  It's too bad he left Linux to develop closed software for Windows.

via Rick’s Posterous

The Extensibility of Firefox

Mozilla recently hosted a Summer Design Challenge for 2009 that focused on “Reinventing Tabs in the Browser”.  Firefox is a fabulous platform to host such a challenge on, as it is the most extensible of all the browsers currently available.  Let me digress into why I say this quickly before I get into my main point (which is about tabs!)

Mozilla itself has gone to great length to expose the browser internals by making the browser open source, which allowed for modification. Next, they provided a framework for developers to write add-ons for Firefox, which provided a robust architecture for extension. The primary distinction between modification and extension is that two modifications to a piece of software may well be mutually exclusive, while two extensions are designed to work side-by-side.  These two aspects of Firefox’s feature set have been well known since its release, and the add-on (extension) community has been very active since Firefox’s release.

But, in recent months, Mozilla has released two extensions that make the process of extension itself even easier.  One is called Ubiquity, which provides a command-based interface to the browser and web, and allows for it to be extended by writing Javascript in its configuration interface (in a browser window with the address “about:ubiquity”).  This type of extension caught on quickly with fans of command-based systems like Launchy and QuickSilver, (and later, Google’s Quick Search Box, authored by the developer responsible for Quicksilver, also only available for Mac) but was otherwise relegated to a niche of the Firefox user base.  One of its primary features was the novel mechanism by which Ubiquity could be modified: simply visiting its configuration interface (inside the browser itself), and typing into a text box.  That was it.  No saving, reloading or compiling.  As soon as the code was typed, it was “live”, and immediately available within the Ubiquity launcher.  The distinction between “development” and “use” was almost non-existent.

This feature was so compelling that it deserved its own extension, independent of the concept of a command-based launcher embedded inside Firefox.  Whereas Ubiquity provided an API centered around the user interface of Ubiquity, it offered little to modify aspects of Firefox outside of the Ubiquity interface.  To fill this more general need, JetPack was born, also from Mozilla Labs.  JetPack had all the quick-development goodness of Ubiquity, but without the extra baggage of a command-based interface.  JetPack was designed to allow extensions for Firefox to be written quickly and simply, and distributed on the web with equal ease.  Though still young (JetPack has only been released for a couple of months), it provides a polished interface for development.  Its internal browser-based editor for coding is based on Mozilla’s own Bespin, and provides all the immediacy of Ubiquity development with extra goodies like line numbering and syntax highlighting thrown in.

So, hopefully at this point you understand why I assert that Firefox is the world’s most customizable browser.  My concluding thought on this topic is that this is all part of Mozilla’s effort to work towards a browser that is designed to be restarted only rarely, is extensible while it runs using a built-in interface, and allows users to change their working environment as easily as developers, because no special tools are required.  This vision is not entirely new; if you are familiar with Lisp-based environments, the REPL, or GNU Emacs, all this will sound very familiar.  So, it would seem Mozilla is learning well from successful projects in the past.

Why Tabs?  Why Not “Buffers”?

Which brings me to my main point (sorry it took so long!)  As Mozilla hosted the design challenge to reinvent tabs in the browser, many teams with a wide variety of approaches sought to provide meaningful improvements to the existing interface.  Every team did research with users by watching users use Firefox, and/or interviewing users about their browsing techniques.  Every team noticed one glaring deficiency in the existing tab interface: it doesn’t scale.  Any user of Firefox that has tried to manage 50 tabs has had trouble.  Even the interface has trouble: it tries to show many of them, and finally gives up, reverting to a scrolling tab bar.  So, when asked to improve the existing interface, every team tried to improve the tab interface’s scalability.

What I found so surprising as I reviewed the entries was that, in a community that has learned so much from Lisp and Emacs, most entries completely ignored the notion that a keyboard-based navigation system scales much better than a mouse-based system.  The trade-off, of course, is learning curve and prior knowledge.  We can attribute the meteoric rise in keyboard launchers across all operating systems to “Start Menu Clutter” – the simple problem that, when you install a few hundred programs, each wanting its own start menu item, quick launcher, and desktop shortcut, you rapidly drown in a mosaic of brightly colored icons, all alike.  But, if you know what you want (“Firefox”, “Word”, “Emacs”, or “iTunes”), you can use a keyboard launcher, type a few letters, and avoid the clutter entirely.  Such systems prohibit “browsing” of available programs, but for most users most of the time, the desired program is known in advance, rather than discovered by searching the start menu.

One entry provided effective keyboard navigation (it was called “Collapsible Tab Groups“) and it provided good scalability.  In particular, it provided two pieces of functionality that should be present in more software today, one of which comes straight from Emacs.

First, (this is the non-Emacs feature), it puts the UI elements on the side of the screen, rather that the top or bottom.  Why is this so good?  Most screens are widescreen.  Heck, even the 1600×1200 screens are wider than they are tall, but even those are going out of style to favor wider aspects (I’m typing this on a 1680×1050 display).  So, given the fact that displays are wide, but most material we read is tall (think word documents, most PDFs, and almost every web site), do developers insist on sticking every interface bar on the top or bottom of the screen, further constraining the already-limited vertical dimension?  Well, collapsible tabs groups gets it right, and puts the tabs on the side.

Second (this is the Emacs feature), it provides “search as you type” for navigation.  What does this mean?  It’s the kind of behavior you get in desktop keyboard launchers.  If you type “irefox” or even “ire” into Launchy or QuickSilver, you will get “Firefox” as the launch option because that substring matches the “ire” in “firefox”.  This is the feature Emacs uses to manage buffers with ido-mode.  You open the interface to change buffers (files, roughly) in Emacs and it presents you with a small interface that lists just a couple of the (possibly tens or hundreds of) buffers you can switch to.  As you start typing, each character is added to the search criteria as you type, and the list is refined to reflect the relevant buffers.

This approach works perfectly in a browser.  The problem with Mozilla’s challenge is that they asked people to reinvent tabs; the realization is that we don’t need tabs.  “Tabs” implies a user interface, which should be customizable.  What we really want is a model for navigation, and a set of pluggable user interface elements that attach to that model.  One user interface might be tabs (for users that keep 4 or 5 websites open at a time), but another could be a search-as-you-type mode that doesn’t use any screen real-estate when it is not in use.  There has been a widespread conflation of view (the tab interface) and model (the idea that we have multiple web sites open) in every browser.

The obvious answer is that I should get in gear and write a keyboard-based tab switching interface using JetPack (Ubiquity has one, but it is painfully slow to use for a variety of reasons).  I don’t know…maybe I just convinced myself that I should.

C-0 M-x byte-recompile-directory

will recursively traverse a directory stucture and compile all .el files encountered.  My startup time is back to 4 seconds.

This didn’t really hit me clearly until I noticed that for many web-related activities like checking mail, updating twitter and posting to my blog, Emacs has solutions (VM for mail, twit.el for Twitter and weblogger.el for blogging), but so does Firefox (Gmail for mail, TwitBin for Twitter, and ScribeFire for blogging).

So, everytime I want to blog or update Twitter, or even check mail, I have to consider what I want to use, which is really dependent on what program I happen to be in at the moment. So, in a way, the race is on: will Firefox get a better extension language and text editor, or will Emacs embed a good browsing capability. Personally, I’d like Emacs to embed Gecko with the upcoming libxul, but we’ll see how hard that turns out to be.

(require 'cl)

(defun duration (time)
  "Takes in a time-value and returns the number of seconds since
   the epoch that value represents."
  (+ (* 65536 (car time)) (cadr time)))

(defun uptime ()
  "Prints the current uptime of Emacs as recorded on startup in
   the value 'start-time'"
  (interactive)
  (let* ((total (duration (time-subtract (current-time) start-time)))
         (days  (floor (/ total 86400)))
         (hours (progn (decf total (* days  86400)) (floor (/ total 3600))))
         (mins  (progn (decf total (* hours 3600))  (floor (/ total 60))))
         (secs  (progn (decf total (* mins  60))    (floor total))))
    (message "%d days, %d hours, %d minutes, %d seconds" days hours mins secs)))

; Put this in your .emacs
(setq start-time (current-time))

Emacs keeps track not only of the character class, but also several character flags (this stuff is described in the elisp manual’s section on syntax descriptors). There are no lisp functions to directly access this information, but in section 35.8 on syntax table internals, it mentions that the higher order bits (16+) encode these 6 flags. It turns out that the syntax table is in fact a vector, so using (elt (syntax-table) 53) where 53 is the ASCII code for the character number I care about, I can access the integer representation of the character class and associated flags.

As it turns out, using this method to determine  comment characters doesn’t really work all that well. There are a handful of languages that will simply break because they don’t use the model of commenting I’m assuming when I look at the syntax flags.  After I posted about this in comp.emacs, I received a nice reply explaining why, despite my notion that this would be a nice general approach to accessing comment syntax, it was in fact kind of misguided.

I am now using a simple alist matching major mode  string to a single-line comment character.  I don’t know if it will stay that way, but it works for basic testing.