in which a subject is attempted to be approached objectively, though such a thing is actually impossible
in which a subject is attempted to be approached objectively, though such a thing is actually impossibleIn the past few weeks an odd trend has come across my radar: I've seen a number of hardcore Mac geeks experiment with the classic editors, and I've seen others who wonder why people would give up the comfort of a "modern program" for them. I hesitate to write on the topic because posts that do so often up as flame-bait, but it actually sounds like some folks are genuinely curious and want to learn rather than just repeat the same holy wars of the past, so I will try to stay in the same frame of mind.
One of the complaints you see leveled over and over is that Emacs on OS X doesn't feel "Mac-like". This is asserted as if it's a tragic shortcoming of Emacs, and the person stating it never specifies what advantages would arise if it were "fixed"; it's assumed to be obvious. This usually comes across as cultural elitism, but I don't think that's the intent, any more than Ray Smuckles intends to offend the Russian people when he observes that the Cyrillic alphabet "looks like they commissioned a smartass to make fun of our letters,"—he's just being Ray. That is to say, there are some deeply-held assumptions at work here that are never questioned. It's pretty easy to explain why a buffer list is more effective than a tabbed interface, (an explanation is given below) but I've never heard the reasoning why supposedly a modal file open dialog box is better for text files than reading a location unobtrusively from the minibuffer. It's always just set forth as something the user will grudgingly put up with, even though it has many advantages over what they're used to.
I agree that there are some advantages to a standardized set of conventions for user interfaces that apply across a whole operating system. Lowering the number of context switches involved in day-to-day usage is a definite win. But the problem with standards like these is that they can turn restrictive. If something comes along that is objectively better and the standard doesn't allow for it, the standard is acting as a hindrance.
The most obvious example is to compare the modern convention of multi-document tab-switching to the buffer-switching mechanisms you see in Emacs. Once you start opening a significant number of tabs, the number of documents you can open and see at the same time is limited by the width of your screen. For Firefox on this machine, the number is twelve[1] when it's running full-screen. Even if you can see every document, the title of each will need to be sharply truncated to fit on the small visible tab, making it harder to identify a tab without switching to it. To find the tab you want, you need to just press control-pageup over and over again.
When the ido buffer switcher that comes with Emacs
is invoked, it shows a limited number of targets to switch to,
just like the tab system. So far the only difference is that the
buffers are in order of when they were used last, so it's much
more likely that the one you want is at the front of the list. But
the big win is that you can just start typing a few letters, and
the list will narrow down to only the options that match what
you've typed. So once you invoke the buffer switcher it rarely
takes more than five keystrokes to find what you want even when
you have a large list of open buffers, whereas with tabs you'd
have to search linearly for your target.
With predictable frequency we get folks dropping by the #emacs freenode channel asking things like "can I get a tabbed interface in Emacs?", and the answer is always "of course you can, but you don't want to; try this instead". This probably comes off as cultural elitism too when the enquirer insists that he really does want a tab bar, but I think the motivation is more "we don't want to spend the time explaining in painstaking detail the advantages of this way to someone who doesn't want to listen" than "we don't need the likes of you around here".
The other big under-appreciated advantage is the capability to redefine or add functionality on the fly. I'm fairly sure this can't really be understood until you try it[2], but the thought of going back to apps that don't allow self-modification is usually met with a grimace.
Take the example of the version control interface. It's got a bit of historic baggage, being designed around a single-file-at-a-time mindset encouraged by the version control systems of yore. It's recently been rewritten to work better with multiple files at a time, but since it provides a uniform interface over all the different backends it supports, I noticed a problem with working with git repositories. When you add a file to the repository, it checks to make sure it hasn't been registered yet. This is pretty reasonable with most VCSes, but with git re-registering a file is a common operation when you want to add a single change to the staging area.
If you didn't have the ability to modify functionality on the fly, you'd probably just bite the context-switching bullet and drop into the shell for this (or worse, just quit using git's ability to build up a patch chunk by chunk and just commit with the "-a" option) since it doesn't seem like it's worth fixing. But it's really trivial to fix in Emacs:
(defun my-vc-add-or-register () "Register the file if it hasn't been registered, otherwise git add it." (interactive) (if (eq 'Git (vc-backend buffer-file-name)) (vc-git-register buffer-file-name) (vc-register))) (global-set-key (kbd "C-x v i") 'my-vc-add-or-register)
This took less than two minutes to write, and I was actually able to use the functionality I just wrote to add the change to my dotfiles repository instantly[3], bootstrapping-style.
If you have to use some tacked-on "plugin mechanism" to customize it, then you’re going to be limited at the very least by the imagination of the author of the plugin mechanism; only the things he thought you would want to do with it are doable. But if you’re using the exact same tools as the original authors were using to write the program in the first place, you can bet they put all their effort into making that a seamless, powerful experience, and you'll be able to access things on an entirely new level.
I don't want to say that there aren't any problems with the system I use. The default key bindings are more an accident of history without much advantage from the more standard conventions. The M-x customize interface is frankly pretty embarrassing and comes across as an attempt to shield users from the act of writing and reading code, but this is easy to avoid. The lack of concurrency is a very real problem, though not one that's going unnoticed by the developers.[4] The rendering engine is very text-centric; it's hard to get it display other things. But these are problems that people are working together to address, and it's remarkable how approachable some of them are to someone who knows a little elisp. And the capability to examine and change running code on the fly makes them much easier to deal with.
[1] - Perhaps this is intentional; keeping too many tabs open at a time in Firefox can cause performance issues. But that's another issue entirely.
[2] - The ex-Smalltalkers never have a hard time understanding it.
[3] - Of course, it doesn't stop here; the decent thing to do is send the fix upstream. Unfortunately there's a feature-freeze right now, so this specific feature will probably have to wait for the next release.
[4] - The lexbind branch of
development provides optional lexical binding, the current lack
thereof being the greatest hindrance towards adding concurrency
features. The current plan is to merge it and add coroutines
after the release of version 23 in December.
Technomancy is © 2004 – 2010 Phil Hagelberg
SDG
[ All posts |
Résumé |
Projects |
Colophon |
]
I think your examples show some people like to get a menu (reach for the mouse) and pick and choose, while others like to start the dialog from their end (M-x) and ask about the special of the day. OMG mystery meat. :-)
Isn't Textmate over there the new Emacs? >:-]
On the Windows side (yes I'm from there), either I came too late to the porting party or the Emacs UI is just not much of a problem, since Windows UI itself it just so non-unixy I just throw up my hands and exclaim "Think Different".:-/ The recent change in Emacs 22.x to allow file copies from Windows Explorer to a directory shown by a Dired Buffer (via "drag and drop") seemed to be an anti-improvement IMHO, but I'm sure someone appreciates it. Still I like reaching for Eclipse or VS200x for the "intellisense" visualization. It just works and sometimes I'm in that mood to hit Control-Spacebar. 14 years and I still haven't set this up in my Emacs (I assume, without hesitation, that it is possible).
One thing I would like to know is if Emacs Customize should really, really be avoided. My Customize vs hand-pref ratio in my .emacs is probably 20%:80%, and I feel its convenient for what it does, except for the UI which is really awful. The font face and color selection is just hit and miss. Someone, please, post a "Emacs Customize considered harmful" or "E.C. is full of lose"..
I'd really like to see compelling reasons to switch from TextMate to emacs, if only to suggest improvements for TextMate or other code text-editors.
The big problem I have with Emacs is that it is hard to get into for novices.. I've tried myself at a few occasions. TextMate (among others) makes it easy for novices to get into, and allow you to discover each functionality incrementally.
> And it's just as easy (or easier) to modify the behaviour of the app through the Bundle editor.
The problem with this is that you can't extend it using the same tools that it was written in. The fact that the author says, "look, here—we have a way for you extend the program, but it's not the way I extend the program" means there are a lot of things you just can't do. I've tried to get folks to support Augment in Textmate, and it's simply not possible because the required functionality is just not exposed. That whole notion is rather offensive to begin with; it puts the author in a high holy place that is inaccessible to the users. Users should demand better of the programs they use.
Piyo: In my experience, I haven't found anything customize is good for, though some have said it's good for modifying font faces. (I just use color-theme.) My problem with it is that everything it does can be done better by writing real code instead of having code written for you. It lets you alter the behaviour of libraries without looking at the code for those libraries, but why should you be hesitant to look at the code to begin with?
Just my thoughts though; maybe there's something there I'm missing.
I actually don't think that's a good characterization of how TextMate and bundles interact. Yes, there is a core engine that provides some functionality, but I'd say that 90% of the useful features that TM comes with are implemented as bundles. The fact is that the general author uses bundles for most functionality, so a really surprising amount of functionality is available to them.
(I know there are libraries to save and restore window configurations, but they are not intuitive to use; or you could use frames, but they don't give the user the same sort of visual information.)
The Emacs developers implemented file open dialogs, which no-one in their right mind would use instead of the minibuffer (or dired). So why not tabs? When they answer the question, "can I get a tabbed interface in Emacs?" with "we don't need the likes of you around here", they may not understand that people may not think that "1 tab=1 buffer", but they may really think that "1 tab=1 window configuration" or even "1 tab=1 component in my workflow". And then they are missing a real need.