Why Not Use Emacs

Why is it that I often hear people, especially in the win32 world, saying "I like this editor, it's not perfect but it has feature foo... but I wish it had bar like someothereditor", when almost every time features foo and bar are well supported in emacs? Very strange - why not use emacs, if those are the sorts of features you want? It has been supported on win32 for ages... Paying money for a pale imitation doesn't make much sense to me.

Because there is vi. A conceptually sound editor.

For me, start up time and general non-Windows-ness. In the past, I've been near-guru-level with emacs, too.

I haven't used Emacs since the mid 80's, after the "standard" keyboard moved the Ctrl- key to where it strained my little pinky to find it. Emacs became too uncomfortable. And recently, it has been noted that old-time Emacs users (e.g., Stallman, Gosling) suffer from RepetitiveStrainInjury at a greater rate than old-time Vi users. -- DaveSmith

Yes... I remember those keyboards fondly. Unix users generally use control a lot, and caps lock very little. On older Sun keyboards (and perhaps newer ones) these appear in the opposite positions that they occupy on modern PC keyboards. Emacs relies on hitting control a lot, and when I first starting using it on a PC I found the required hand motions to be pretty painful. I highly recommend the following fix for anyone learning emacs: [RemapCapsLock].

As to WhyNotUseEmacs? Unfortunately-- like the Matrix-- no one can be told about Emacs, you must see it for yourself. There *is* a learning curve. It *is* worth it. -- KevinStone?

I've been noticing some strain on my left pinky, and it's from the control key. That thing gets held down. I'm looking for something to map it, and decided to throw in my two cents. I'm already using dvorak and was surprised to find a text editor that'll kill my hands. NolanEakins?

After a fellow programmer got RSI in his early twenties he started using the KinesisKeyboard. I had to program at his desk sometimes so I ended up having to use it. The thumb placement of ctrl, alt, and delete (this one mapped) make emacs key sequences effortless. This is on top of the general increase in typing efficiency due to key placement. Have a look at the typing faq. http://www.tifaq.com/keyboards.html -- Beni Kavanagh

I don't have any 'standard' keyboards; the few intel machines I use have been re-mapped or replaced. I don't know if your statistics are meaningful on the RSI front certainly a couple of highly-likely-to-get-RSI types like those don't mean anything. Anyway, with my bindings (highly customized) I don't find emacs pushes me off home more than vi did. I left vi begrudgingly, as at the time the feature set of emacs was a big win

No fingers are strained when one hits Ctrl with the hand's outer edge.

My editing needs are minimal, but below conscious thought. If I try a few obvious keys strokes, and nothing works, I quickly go back to a Windows editor. If I need to actually hack text, I'll write a Python script, not mess around programming an editor.

If you want Windows-style keys under emacs, this extension gets you a good chunk of the way there: http://www.cua.dk/cua.html .

Hmmm. Making python do any non-trivial subset of what emacs can do out-of-the box would be a huge job. Even then, Elisp is better suited to the task [editing]... However, I concur with the frustration level being low; that is exactly what happens to me whenever I try and use a windows editor - the 'obvious' keystrokes don't work, so I end up looking for a unix editor pretty quickly. I guess 'obvious' is pretty much in the eye of the beholder.

It's not necessary to reproduce a subset of emacs in Python; it's just that, for any slightly odd text-related task I might need to do, if the editor won't do it, I can hack it up as a batch Python script in a few minutes.

I've been using SlickEdit for quite a while, even though it has a few annoyances. I used NE.COM for years. The switch to NE.EXE was traumatic. I used to use emacs on Pr1me, but that was awhile ago. I still miss EDT under RSTS/E.

There's a related story in TheZenOfProgramming.

The Church of Emacs http://www.dina.dk/~abraham/religion/

A novice of the temple once approached the Chief Priest with a question. "Master, does Emacs have the Buddha nature?" the novice asked. The Chief Priest had been in the temple for many years and could be relied upon to know these things. He thought for several minutes before replying. "I don't see why not. It's got bloody well everything else."

From UltraEdit:

Why are these things considered 'features'? I should think they represent bare minimum capabilities for an editor to be considered acceptable for development. Is the size of emacs really an issue these days? Is it really worth moving to a smaller editor with a subset of its capabilities?

As they say: I don't use Emacs, for I don't want to learn another Operating System.

Others say: I use Emacs, for I don't want to learn another Operating System. (Because Emacs works (largely) the same on all operating systems)

I've also had excuses like "it's insecure" waved around. It's amazing the number of places where one is forbidden from using things like Perl and Emacs because they haven't passed the local corporate security vetting, and yet when you ask to see the vetting procedure or see the vetting results for, say, Outlook, there's no paperwork for it.... -- KatieLucas

The reason not to use Emacs is that it takes so long to learn. Ten years ago, it was worthwhile, but these days there are many other editors out there that support coding just as well without making you spend weeks of your life making faces at the badly-written online help text. -- MichaelGates

hmmmm. If I recall correctly, it took me about 2 weeks. And I have never seen another editor (that wasn't an emacs clone) that supports coding just as well, but I can't say I look too hard. To support coding as well, it has to be as extensible as emacs, of course. Full disclosure: I did learn emacs more than ten years ago.

I tried running XEmacs version 21.4 on Windows 2000 a few months back. I also found its slow loading and non-windows like behaviour is an irritation. But I'd put up with all that if it were stable. It may have the capabilities of the world's best programming editor, but if it crashes or freezes I'd rather stick with something more reliable. -- TerryEbdon?

Around the same time, I found GnuEmacs on Windows more stable than XEmacs; I've been told that XEmacs is better these days.

To support coding as well, it has to be as extensible as emacs, of course.

Why? If the editor you have supports coding already, why must it be extensible? Surely, if you need to extend your editor just to get some work done, that's a sign that your editor isn't up to the job.

Or maybe requirements for software change in unexpected ways? Should my editor authors anticipate that I want to write JoyLanguage source, and then send that source to a running JoyLanguage process?

NB: GNU Emacs has been running stable on Win32 for a lot longer than XEmacs, so the people having trouble may want to try it instead.

Two weeks to get proficient with Emacs? After about five years and many a thousand line of Emacs Lisp, I feel I'm just starting to get the hang of it! This is not because I find it hard to use, but because it can do so many amazing things, so many that I can't believe I lived without.. -- LukeGorrie

I agree. Perhaps 2 weeks to get efficient (w.r.t other editors). Everything after that is gravy. ;)

Man, I want some of the weed you're smoking. In various gigs I have used different flavors of Emacs and Xemacs for months at a time and never became really comfortable with it. I always wanted to find something in a menu or have a handy drop down or have some context sensitive help, and the editor always managed to foil me one way or another. Hmph. -- MartySchrader

Emacs invented context-sensitive help. Try "C-h m" sometime.

Yeah, the "context-sensitive" help. Riiiiight. A lot of circular references to other functions or operations that are supposed to be obvious to the casual observer, eh? Not really all that helpful in my experience. I'll just stick with an editor that I know works -- Codewright. You use whatever makes you productive.

[reworked exchange based on a question taken out of context: "why must it be as extensible [as emacs]?" ]

If the editor you have supports coding already, why must it be as extensible as emacs? Surely, if you need to extend your editor just to get some work done, that's a sign that your editor isn't up to the job. I would much rather have an integrated environment like Visual Studio, where the extensions have been done for me, than a stand-alone editor environment where I have to extend and merge things. I would rather write code than tools.

The point is that for many coders such environments don't exist. If you are willing and able to adjust your employees to some set of rather limited tools, then this can work. For a lot of professionals, this just isn't possible, and you need tools that will adjust to your needs. I have worked with three in-house languages, two in-house versioning systems, two obscure build systems, etc, etc. With an extensible editor, my toolchain can be seamlessly integrated. If I have 100 coders, one of them can be put to work on tools for a few weeks, and it will work for all of them (insomuch as any tools fit everyone). If I buy a non-extensible integrated development environment that doesn't already do everything I want and isn't properly extensible, then this toolchain will never be efficient.

So what are the other 99 programmers doing for the "few weeks" while tool man is extending the editor? It seems that the cost of the project is being driven up due to dependencies upon in-house languages, in-house versioning systems, obscure build systems, etc. If one is forced to use custom tools, then of course off the shelf solutions are not possible. I would, however, categorize this as a restriction, not a benefit. Having worked in embedded environments, I have found that it is much more cost-effective to develop in a standard language (C or C++ come to mind), do the development on standard desktop with a full development suite, and port finished code to the target environment. Having a complete development environment (which I doubt a single tool programmer could create in a few weeks) will speed the development process. The added costs of creating an emulation environment on the development platform will be more than offset by not having to provide copies of the target environment to each programmer.

The other 99 coders were working of course. We're not talking about building an entire toolchain here. We are talking about making your editor work with an existing toolchain smoothly. This is the sort of thing that exists in off-the-shelf solutions *only* for the most mainstream toolchains, on the most mainstream platforms. With an extensible editor, you can often make this work nicely with very little effort. I am talking about things like: proper indentation and highlighting etc of a new (to the editor) language. Interface with a versioning system. Interface with a build tool, and doing something sensible with its error output. Interface with an internal documentation system. Etc. etc. etc. If you want to use an off-the-shelf IDE (at least the ones I have seen), you simply will never be able to get these things smoothly integrated, and *that* will drive your costs up too. Sure, none of these things are cut and dried. But the idea that an OTS IDE meets all the needs of even *most* programmers is simply laughable. Some simple choose to have some tasks be a pita, because otherwise they like the development environment they are using. Others make other choices, especially when you need to work across a heterogeneous set of platforms.

It amazes me that a coder could even come up with this question. I guess if you work in the sort of circles where interchangeable (and expendable) 'programmers' are the stock in trade, this might make sense.

So knowledge of Emacs makes you more valuable?

Not particularly. Not understanding why an extensible editor can be just the thing you want is a bad sign though. My point about the interchangeable coders (who often aren't primarily programmers, hence the quotes) was that in that particular situation, uniformity is more important that powerful tools.

Emacs is a state of mind. I will never take a job where less than 50% of the programmers use Emacs to read their mail. :-) -- LukeGorrie (comment dedicated to the GhostOfUsenetPostingsPast)

For me the primary reason not to use Emacs has been the Emacs user base. See the Lisp references, below.

Interesting! I completely understand the SmugLispWeenies vibe from some CommonLisp people, but the Emacs hacker community (as found gnu.emacs.sources and comp.emacs) is friendly and wonderful!

[Uhh, not really. I found them to be smug, rude, and generally useless. Oh, well.]

I don't see why is it better than eclipse. And eclipse is prettier.

Currently Eclipse has pathetic support for languages that are not Java, and very poor integration with command-line tools. The eye candy doesn't make it more powerful.

I don't use emacs for the same reason I don't use TouchTyping or a DvorakKeyboard. I learned in a vanilla Windows text editor, and by hunting and pecking (Angband and Moria were great for learning key positions one at a time, NetHack less so). I wasn't going to wait for the school's TouchTyping class to learn how to use a computer, and LearningTouchTyping soon took second place to learning to program. Sure, I could type much faster if I knew how to do it properly, but I rarely think much faster than I type - and, when I'm in that situation, I'm too busy typing to learn how to type.

I was able to pick up the basics of vi from a notecard-sized cheat sheet, and vi is great for hunt-and-peck typists (especially if the cursor keys are sane). I could never get the hang of CTRL- this and META- that, probably because my fingers aren't parked on the home row. And so, every time I try to pick up emacs, I just get frustrated and spend five minutes trying to figure out how to undo my changes and quit. Maybe I'll lose my job, and I'll have some free time to learn emacs. Or, someone will make a NetHack clone with emacs key style.

because emacs (and vi, esp because it's modal) are both too complicated. give me NanoEditor any day.

I tried really hard to like emacs. I'm not sure of all the reasons why I failed, but here are some possibilities:

Although, I do envy elisp a bit. I'd really like a vim-like editor that was to guile as emacs is to elisp.

Another feature I'd like to see in an editor would be auto-indent-soft-word-wrap. That is, soft-word-wrap as I describe above, but that indents the softly wrapped words to the same level as the beginning of the line. (Again, no extra whitespace characters added to the file, it's would be purely a display thing.) Anyone seen something like that?

--RobertFisher

Rob, as of September 2014 that very feature has been achieved in (at least GNU) Emacs. You'll need two "minor modes", 'visual line mode' (which is included in Emacs) and 'adaptive wrap mode' (which is not). Emacs 24 comes with a package manage, which will take care of installing for you, but I don't remember if adaptive-wrap-mode is included in the default package repository. It is: http://elpa.gnu.org/packages/adaptive-wrap.html

See: EmacsCodeWrightComparison, SmugLispWeenie, SocialProblemsOfLisp

CategoryEmacs

EditText of this page (last edited September 8, 2014) or FindPage with title or text search