Let's just use Emacs | Hacker News Reader

Let's just use Emacs

beastwithin.org

220 pointscodeup160 comments

Articles about why anything you can do in a "simpler" text editor can and should be done in emacs strongly resemble articles about why anything you can do in a less powerful programming language can and should be done in Lisp.

I don't think it's a coïncidence.

I think that's a little unfair. Programming languages are tools for your head: you're always thinking when using them. That means that the impedance mismatch of "switching" between languages is fairly low, and scales with the problem. So pick the tool for the job, and don't sweat the simple stuff.

Editors are tools for your fingers. There are huge penalties to being good with an editor if you are forced to use a different one. I use emacs for writing things other than code (email, web forms like this very comment) not just because I think it's better than whatever built-in editor is provided for the task, but because it hurts so badly to use something other than emacs.

The converse point is that there are huge benefits available if you give up all your existing editing tools and spend some time (and yeah, it can be months to years) getting really, really good at just one. Really, that one has to be emacs or vim, which are the only editors out there designed to scale to this level of specialization.

It always makes me sad to watch other people work and see how much time they spend fighting with their editor, moving their hand around to the arrows or mouse or function keys, fighting with the presentation logic of their word processor to get the page break on the right spot on the screen, etc... It doesn't have to be that way.

What's unfair? That the arguments made by emacs users with respect to less powerful editors resemble the arguments made by Lisp users with respect to less powerful programming languages?

I'm not taking a stand on the argument one way or the other, just pointing out how similar they sound. You said:

"There are huge benefits available if you give up all your existing editing tools and spend some time (and yeah, it can be months to years) getting really, really good at just one. Really, that one has to be emacs or vim, which are the only editors out there designed to scale to this level of specialization."

How does this differ from:

"There are huge benefits available if you give up all your existing languages and spend some time (and yeah, it can be months to years) getting really, really good at just one. Really, that one has to be Lisp, which is the only language out there designed to scale to this level of specialization."

Whether you agree or disagree with the sentiments, haven't you heard people expressing those sentiments in much the same terms?

I'm not taking a stand on the argument one way or the other, just pointing out how similar they sound.

Uh, no. You're making an editorial point that they both seem equally silly, you just aren't saying that. If your only purpose to posting was a bland linguistic analogy with no bearing on the subject being discussed, then I withdraw my argument on the grounds that your post is unimaginably boring. :)

But to respond: the sentences differ in that one statement is truer than the other. "Hugs are good." and "Suffering is good." use the same language too, but you wouldn't use that as part of a sideways argument that huggers are insane, would you?

My words meant exactly what they said, no more and no less. I know this because (a) I wrote them, and (b) I happen to like Lisp, Emacs, and the people I know who use them. I'm pretty sure I am not in the habit of describing their arguments as "silly."

At the risk of appealing to authority, I do not consider this essay silly: http://www.paulgraham.com/avg.html

What I was doing is making a commentary about the similarity between cultures, or perhaps mindsets, or perhaps people.

Now, if you want to believe that when I say X, that I really mean Y, and when I assert "No, I really meant X," that I am lying and I meant Y but have some sort of duplicitous reason for telling you that I meant X, that is your right.

But I'm going to have to let you go your way on this issue, and I will go mine.

For what it's worth, I read derision in your original post as well.

Sometimes, a really simple statement is a Tabula Rasa. We read into it what we believe, or what we think others might believe. Nothing exceptionally wrong with that, and so we ask the author: "Did you mean such-and-such?" If they didn't, they clarify their intent and we move along.

I have spent more time thinking about the nature of programming languages than editors, so I will perhaps ruin a perfectly good neutral statement by talking about my own beliefs. I think there is such a thing as a power continuum in languages. I have no idea whether Haskell is more powerful than Clojure, but I am comfortable describing Java as far down the continuum from Scheme.

I also think there is such a thing as design in programming languages, and I think it has value. So while Python may be less powerful than some other languages in an absolute sense, I understand why many people choose it. It is well-designed in exactly the same way that the original iPod (No Wireless. Less Space Than A Nomad. Lame.) was well-designed. And by well-designed, I don't mean "Has all the features, " I mean, "Has a carefully selected set of features that complement each other."

Given my beliefs, I understand people who prefer to work with more powerful languages and why they might argue that you never need to step down the power continuum. Makes sense. I also understand people who argue a certain tool that is less powerful in an absolute sense but has a design that suits them in some fundamental way. I even understand people who argue that certain languages are more powerful and well-designed, like Haskell.

I honestly don't have a strong feeling that either person is wrong, and I'm fairly comfortable saying that we haven't done enough research to settle the matter empirically.

So no, I am certainly not ridiculing Lisp users who claim that there is no need to step down the power continuum. They may be right, and we don't have enough solid evidence to disprove their claims, just what amounts to folklore about readability and design patterns and significant whitespace and monkey-patching.

Likewise, I cannot really argue with an emacs evangelist. Who can say that such an argument is anything except Blub? I value certain well-designed text editors--I have been enjoying Byword lately--but can I prove that I'm more efficient with Byword than I would be if I spent two weeks or a month or a few years becoming an emacs guru?

So anyways, no I was not being derisive, but I don't fault anybody for wondering if I had something on my mind considering that I tried very hard to say nothing about whether Emacs is or isn't superior to Byword, or whether Ruby is or isn't an acceptable Lisp.

I'll add myself as another data point to sensing a hidden criticism/accusation of brain damage in your original post. Particularly, I think the main problem is this:

> I don't think it's a coïncidence.

This invites the reader to ask "Well, then what's the reason?" And you as the author haven't stated what you think is the answer, which makes the careless reader (in my defense, it's a single post!) bring up a cached thought for the answer. In my case, I see passive arguments all the time that use the same style you tried to use neutrally, where the arguers try to lead the reader to conclude the other side is brain damaged without specifically saying so.

Anyway, interesting case on miscommunication and careless reading. :)

The above goes for me as well. You might not have meant for it to be that way, but you just happened to use a pattern of sentences used by people with hidden criticism quite frequently.

Now I'm really worried. My comment received 36 upvotes. How many were from people who (a) think think that Lisp and Emacs users are brain-damaged and (b) Upvote what they perceive as an insult as a kind of social bullying rather than to signal a contribution to the discussion?

Probably quite a few.

I upvoted it because I found myself agreeing that the arguments for both are kind of similar, whether those arguments are correct or not on their own merits aside.

I'm not sure if you're making a general point, but I don't think it's universally true. Anything you can do on a netbook can be done faster and more accurately on a supercomputer. Working backwards from why we don't all use supercomputers, we can probably figure out why not everyone uses lisp and emacs.

> Anything you can do on a netbook can be done faster and more accurately on a supercomputer.

What about:

  - developing software while on a flight?
  - recording field data for an experiment?
  - using hibernate or sleep to save power?
  - connecting to a projector for a presentation?
  - ...

The point is that it's important to use the right tool for the job, and that for many tasks a netbook is vastly preferable to a supercomputer. "Working backwards from" use the right tool for the job seems more instructive than your implication (whatever it was).

The title raised my hackles as well, but it turned out to be a fun, un-dogmatic read with nothing to do with the editor wars. Upvoted.

Or perhaps it was just that he didn't bash my favorite editor :)

I though the article was fun and informative, but I'll stop short of saying that a post wherein the author questions why people pay for editors that do less than emacs has "nothing to do with the editor wars." I agree that it has nothing to do with the One-True-Editor war between emacs and vim users :-)

  Simple text editor = simple + powerful
  Emacs = complex + powerful
  Lisp = simple + powerful
  Blub = complex + powerful

Given this your association doesn't make much sense.

I think most people prefer simple + powerful. And this isn't black and white - Blub can often be simpler for X simple task. However the real yard stick is whether as your problem domain gets more complex does Blub suddenly lose its veneer of simplicity?

I always bring up Alan Kay in these kind of threads but his observations are always so damn salient - agglutinative PLs (features) vs style PLs (simple principles).

Most of my emacs customizations are pretty simple. M-x [ and M-x ] start and end macros. f5 runs a macro instead of C-M-x e. f6 copies the entire current line. f7 is line-goto. f9 is replace-string, f10 is replace-regexp. M-x g is whole-buffer-copy. I have a bunch of functions that insert standard shebangs and other script boilerplate, which are easily mapped to function keys if I need them.

I've got some other more complex customizations that I don't use very often, for example a set of functions that let me cycle through various background/text color schemes. For awhile I had that mapped to f8. I've also effectively used hotkeys that generate documentation/comment templates. But those tend to come and go, and when I'm not using them they don't interfere at all.

Beyond a few fundamental things, emacs is only as complex as it needs to be. Yes, it's a fairly large base install compared to vi, or a simple text editor, but so far it's never been big enough to get in my way.

I will argue that simple text editor does not usually equal simple + powerful. Most "simple" text editors (think Notepad) are just plain simple.

Emacs seems quite simple to me, actually. Intimidating at first, sure. Complex to master, but simple to use.

Then again, there's an obvious difference between something that is difficult to learn and something that is difficult to use. In fact most tools require training at first to use them, and Emacs is not any different.

Well, emacs is the most popular Lisp implementation and area of application.

I was thinking along these lines. Although, the thing that occurred to me is that Lisp is sometimes called a programmable programming language. And emacs is the canonical programmable text editor. It had occurred to me that it was not a coincidence that someone who had embraced a fully programmable tool (language or editor) would feel this way about it. I thought the article was interesting in that the author was pointing out that emacs' programmability could be used to emulate design features like a distraction-free environment and not just "power" features.

I use Emacs for coding, wanderlust mail, rcirc and jabber-el. All which are provided as packages in the distros I run.

I've been trying to get into clojure which entails installing clojure-mode, swank-clojure, leiningen (which brings the pain of maven) and slime. This is where emacs has always broken down for me. Once I step outside the distro provided packages I find broken tutorials, unspecific versions, and instructions written like:

    First install package.el.
    Add to your .emacs: (add-to-list 'package-archives '("marmalade" . "http://marmalade-repo.org/packages/"))
    C-x C-e to evaluate it, and you're good to go!

http://marmalade-repo.org/

Except that didn't work in two of the three emacs installs I have. Any time I need to download an elisp file I dread reading the instructions. Too often the author forgot that he loads some other required package in his 1000 line .emacs/init.el file. Then you end up with half a set of instructions.

I think the only solution to the problem would be package maintainers providing instructions for how to install their package in a specific vanilla version of emacs from scratch with no other changes. But if they have to give up their custom emacs configs they won't be able to write up an explanation.

Whenever installing software for Emacs, it's usually worth checking ELPA http://tromey.com/elpa/ (which comes installed on Emacs by default now,) to see if the package is there already. The ELPA provide both slime and clojure-mode and they work out of the box with swank-clojure. You'll still need to install Leiningen/Cake with swank-clojure separately, but there isn't much Emacs can do to help there.

Ah, but now you're not following the instructions provided by swank clojure which says to use marmalade (which is an elpa extension/replacement/clone/additional repository?)

The clojure-mode available through elpa ( clojure-mode 1.7.x) is not new enough to deal with swank-clojure which needs 1.9.x (specifically I was after M-x clojure-jack-in)

Plus, the elpa instructions don't include emacs23 because it allegedly comes with 23 (even though the elpa website does not say this). But elpa is not included in emacs 23 on Gentoo.

And thus an evening of mine is lost to trying to get the same emacs environment running on my Gentoo desktop and Ubuntu laptop.

Obviously my problems could be from a lack of experience with Emacs, but I hate that using a text editor is so hard.

And another example is the pain of trying to build wanderlust from scratch which requires apel, flim and semi. Some of which were ONLY hosted on abandoned FTP servers. Luckily Dave Abrahams recently moved those scattered and abandoned packages to a single place https://github.com/wanderlust

Emacs 23 does not come with ELPA installed. The next version of Emacs (24) is going to have a package manager included by default (it is based on ELPA) that will allow you to use Marmalade. If you are using Emacs 23 (which you probably are if you installed from your distro's package manager) then you should use ELPA. If you installed Emacs from a nightly build then you can use Marmalade.

Sorry, you're right. I was confused by the ELPA page which lists instructions only for emacs 21 and 22, but says elpa will be included in the next version of Emacs. (edit: now I can't find where I read this. I'm incredibly confused.)

Now I'm confused about how my other installs have it working.

I've suffered from the same confusion, on finding that ELPA no longer worked for me with Aquamacs 2.0, I tried using the Marmalade repo with no joy.

Quite frustrating as I was using ELPA in my fork of the Aquamacs Emacs Starter Kit: https://github.com/evangineer/aquamacs-emacs-starter-kit

FWIW, things go a lot more smoothly if you use GNU Emacs rather than a fork. For most elisp maintainers it's not even possible to test with Aquamacs.

"Ah, but now you're not following the instructions provided by swank clojure which says to use marmalade (which is an elpa extension/replacement/clone/additional repository?)"

They seem to have changed the instructions again. The folks developing swank-clojure seem to keep changing their install strategy. Boo on them. Near as I can tell, installing from ELPA, installing swank-clojure through Leiningen, running swank-clojure through Leiningen, and calling 'M-x slime-connect' should still work.

"But elpa is not included in emacs 23 on Gentoo."

Holy crap, I just checked this and you're right. (The Gentoo package maintainers seem to have a problem with letting other package managers compete with their precious portage however, so I'm not surprised.) In this case, I'd suggest that the Gentoo devs should be the ones to warn you.

"Obviously my problems could be from a lack of experience with Emacs, but I hate that using a text editor is so hard."

I don't know what to tell you. The problems you listed aren't your fault and they're Emacs' I'd blame the package maintainers in the Gentoo episode but the Clojure stuff is because the Clojure developers still can't decide how they want their stuff to work. I can't blame them much for that. Experience would help, but I doubt that I have that much more than you. I've had similar episodes installing plugins for Eclipse.

I can't say that I've run into this exact issue, or even exactly what the issues have been that I've run into with Emacs, but I know I've spent many hours reading instructions, following tutorials and generally just trying to get a basic emacs/lisp setup running. It's really difficult to do. I think I had a partially working Clojure setup, but then I tried to make it support Common Lisp in addition, and things completely broke down.

I'm not claiming to be a genius level programmer here, but I don't think I have to make that claim either. There's something seriously wrong with Emacs when an experienced programmer has serious issues setting up a basic development environment.

For comparison's sake, I hit "comfort-level" with Vim within two weeks, including a fully customized .vimrc, colour files and keyboard navigation. After a month of using Emacs I was somewhat comfortable with the keyboard shortcuts for basic navigation, but didn't know how to do several things that I could do in Vim. I also had no idea how to add syntax highlighting for language X - managing only to get it working for one dialect of Lisp and nothing else. Ah, and installing from ELPA had a nice tendency to show me error messages instead of actuall installing anything.

Bah, sorry for the rant. It just frustrates me when I hear about Emacs and how great it is, and I totally get on-board with it, but then it's just this fustercluck of configuration hell that never ends well.

> I think I had a partially working Clojure setup, but then I tried to make it support Common Lisp in addition, and things completely broke down.

This is due to the SLIME developers' insistence on making everyone run from CVS trunk. I wish I were joking, but they really seem to have no interest in creating stable release packages, so I have to go in and try to make it work without their cooperation.

Interesting. For what it's worth, I plan to give Emacs another go pretty soon here, but I'll be sticking with Common Lisp. I'm kind of done my courting period with Clojure.

Emacs + Slime for CL should be a piece of cake as long as you don't insist on using your distribution's packages. Mail me (see profile) when you run into any problems and I'll help you out.

Thanks! I'll give it a good, honest go and if I run into issues, I'll take you up on your word. :)

And Dave Abrahams is now actively developing el-get, which I prefer to ELPA. http://github.com/dimitri/el-get

Ditto. With el-get, I can link into the source git repository, and not wait for manual submissions to the ELPA repository, which always lag the actual release.

ELPA/package.el is broken as far as I'm concerned. el-get is a breath of fresh air by comparison.

package.el is included in Emacs 24, not 23.

Once that has had a stable release, this will become a lot easier. In the mean time, the link to package.el for Emacs 23 is right at the top of marmalade-repo.org: http://bit.ly/pkg-el23

Thanks for your clojure work. I'm using a lot of your stuff and I am grateful you take the time to write and release it.

"In the mean time, the link to package.el for Emacs 23 is right at the top of marmalade-repo.org: http://bit.ly/pkg-el23

You know that, but nothing on the page indicates it. In fact, that page leads me to believe it is the same version as tromey.com hosts. It isn't made clear that marmalade is a fork rather than an additional repository.

Plus that package.el does not integrate (or include instructions on how to integrate) with Emacs the same way the one from tromey.com does when you run the code on http://tromey.com/elpa/install.html

ELPA is no longer accepting new uploads; the maintainer has requested that everyone switch to Marmalade.

Regarding Clojure on Emacs, just use the up-to-date stuff by technomancy. The following is based on my notes from a recent talk by Phil Hagelberg at a Boston Clojure Meetup.

1. Download lein from https://github.com/technomancy/leiningen/raw/stable/bin/lein

2. Launch lein (self-install) from the command line.

3. Run lein plugin install swank-clojure 1.3.0 on the command line.

4. When you first run swank, it may complain you do not have project.clj or something like that, because it expects to be launched form inside a project directory. You may create a dummy project directory (cd; lein new dummy; cd dummy).

You need to run the above steps once, to install. Run the following at the beginning of a clojure session:

5. Run lein swank on the command line.

6. In emacs, run slime-connect (with the default parameters, most likely).

In case I have garbled the above, I am sure someone will correct me. Although I did it both on Windows and MacOs and it worked. (On Windows, I use bash shell form the MinGW project, but I see no reason for the standard Windows shell not to work.)

Separately, you may want to install clojure-mode from the same repository.

Happy hacking!

Actually the week after that meetup I realized the process could be simplified dramatically: http://technomancy.us/149 Now once you have Leiningen and clojure-mode installed it's a single M-x clojure-jack-in to get started.

Wish I had thought of that a week earlier! Could have saved us a lot of time at the meetup.

(The way you posted still works fine, so if you've already got it set up there's no need to switch.)

I set it up twice (once at the meetup), and it was not a big deal, but only because I had had prior experience in setting up clojure environments.

A single emacs function to update/start clojure seems a good way to go, however I had it in the past and as soon as the dependencies broke I had to go in and figure out what was going on under the hood and how to fix it. Which is educational but distracting. Will your setup still work in 12 months?

Thanks for all the effort in bringing Clojure to the masses! :-)

P.S. Got an error -- will submit a bug report. EDIT: wrote a blog comment instead.

I deeply love emacs, but its crustier elements really bite on a regular basis. The amount of effort required to make it non-ugly is just... unpleasant (a problem I've noticed with a lot of gnu ui stuff, both with applications and websites - appearance matters guys), the lack of namespaces in elisp is quite horrid (though it's very nice to have a lisp as the language of choice), the weird annoying regex conventions, and just lots of little things (I'd have to sit down and record them as I go to be able to list 'em) which degrade the experience.

By the way, take that as intended - I love emacs very much, but as with people so with software - the little things a beloved gets wrong can be unbelievably annoying... :)

I'm with you. Making Vim look pretty involves adding ":color <whatever>" to your .vimrc. Making Emacs look pretty involves installing color-theme, hopefully compiling it so it doesn't take forever to load, editing your .emacs.d/init.el since you can't customize that via customize-apropos (AFAIK), and so on. Likewise, I'm with you that the default regex implementation is...surreal, at best. Having reb-re-syntax be 'string should be the default.

On the bright side, look at what we're discussing here: the default regex syntax and pretty colors. Compare that to about five years ago, when we'd be instead discussing how to compile Emacs in a way that had fricking TrueType font support. Emacs has come a long way.

Yeah, both 21 -> 22 and especially 22 -> 23 were vast improvements. Appearance issues aside however, emacs is starting to feel a little like windows in a way (uh oh downvotes ahoy), in that it's lumbered by backwards compatibility considerations. Emacs with namespaces + a nicer lisp would be... something very special.

I think even with the existing lisp it would be interesting to keep the interpreter and rewrite a lot of the basic elisp modules. Another Emacs "distribution" would be quite interesting...

They've added lexical scoping in trunk in a fully backwards-compatible way; it wouldn't be hard to do namespaces and a "nicer Lisp" (by which I'm assuming you mean Guile?) in a similar manner.

That said, the number of people who hate on Elisp is surprising to me. No, a hacked-up version of Maclisp is not the best Lisp in existence. But, seriously, you're competing against vimscript. Will even the most diehard Vim addict actually argue that vimscript is even comparable to Elisp?

"standard" regex syntax for emacs would make me really happy.

YMMV, but I find that the latest Emacs on OS X with a good color theme is quite nice looking. Anti-aliased font rendering is fine with me.

Agreed emacs 23 is a vast improvement, however the UI elements i.e. menubar, scrollbars, etc. still suck, as does the initial splash screen. OS X is better than linux for defaults, but no matter what you do have to work hard to get a decent appearance.

I just turn off all the chrome and use it as a text editor.

Me too, but my point is that you have to do that to begin with.

If anyone is interested, this gets rid of the splash screen + chrome:-

    (setq inhibit-splash-screen t)
    (if (fboundp 'scroll-bar-mode) (scroll-bar-mode -1))
    (if (fboundp 'tool-bar-mode) (tool-bar-mode -1))
    (if (fboundp 'menu-bar-mode) (menu-bar-mode -1))

I really don't see what namespaces would achieve. The way it is I can look at something and explicitly see which module it belongs to (e.g. dired-next-line, image-next-line vs. org-agenda-next-line).

In my experience namespaces only introduce notation to distinguish modules but so does a simple convention.

Namespaces are nice when the language lets you name a space at the top of a file or a block and then not repeat the name prefix on every identifier inside. They are not just used to add dots to identifier names, although that would often be NSNice in NSItself.

Should be nc-nice, we are talking lisp here.

Although this looks like a regular prefix. How does the namespaced elisp propose to refer to entities from other namespaces?

This is exactly my point: It isn't nice. I want to grep a file for a name and exactly that name, maybe I even want to replace it.

I just can't do that without any fancy tools as soon as namespaces introduce ambiguity that I can't resolve when I look at a narrow region of a file.

"org-mode developers, in turn, just ask a relevant big question: 'why use separate files when you can conveniently stick the stuff in one file, dammit?'"

It surprises me that you could come away from org-mode thinking that the developers thought you should stick everything in one file. One of the main strengths of org-mode is the way it frees you to put stuff into separate files, wherever you want, and then use the agenda to consolidate them into a single view.

Having said that, yes, org-mode is freaking awesome.

You think 20 years from now people will still be voting up articles about Emacs and Vim? just curious

Yes. They are bound to be discovered and re-discovered by every generation. They are the kind of tools that get the job done. There's also still a lot to be discovered about those editors themselves.

Besides, to quote Wikipedia:

EMACS: initial release: 1976, 34–35 years ago

Vim: initial release 1991, 19–20 years ago

vi: was written by Bill Joy in 1976 (as extension of `ex' editor)

The debacle's been raging for way longer than 20 years.

----

On the other hand, if you want something more modern: http://man.cat-v.org/plan_9/1/acme

The EMACS package for TECO on ITS isn't an ancestor of modern GNU emacs, which began as a rewrite (based on Gosling's Unix emacs) in 1984. They are both "emacs" in the sense that they are modeless screen editors that share the same default keystrokes.

Really GNU emacs is related to ITS emacs in the same way that vim is to BSD vi: it's a cleaner and much more powerful reimagining of the original that shares some interface details but no implementation.

We had a programming intern a couple years ago, he was doing some Python stuff for us. One day he comes to me all excited about this awesome editor he found that was x-platform and had syntax highlighting for everything and was scriptable. I like editors so I asked him what it was..."It's called Vim!".

The editor I had been using for years. :)

Yeah, I went from Geany to vim for python. And after installing the LaTeX packages, I couldn't go back.

Also, 20 years for now people will still engage in arguments about which is better - it's the ultimate flame war :)

Yes, and the rest of us will still wonder why.

A few years ago I switched to emacs because I needed a cross-platform editor that worked with multiple languages and was available on command-line Linux. vi(m) was (and is) unintuitive.

As you work with emacs and customize it to work with your flow, your hands, and your keyboard, it starts to feel as comfortable as old shoes. Over time, the incremental efficiencies add up, and it becomes clear that a non-customizable editor just isn't as useful.

Contrary to parfe's experience, I've had good experience with Emacs packages, but then again, I don't use very intrusive addons, and keep my emacs pretty up-to-date.

Happened to me, on vim – i used to work with TextMate, and I really wanted a text editor that I could easily use on my servers as well as on my local computer.

I started using vim, and at first, it was kind of hard to get used to all the commands and remember everything... but after a while (1~2 weeks) it felt so fluid and easy – everything makes kind of sense, it's easy to install new plugins (pathogen ftw!), it's easy to hack those plugins, themes (most of the time) just works.

For the fun factor -- emacs page from Section 1 of the plan 9 manual: http://man.cat-v.org/plan_9/1/emacs

Strangely, the vi(1) linked from that page is not for the editor, but for a MIPS emulator http://man.cat-v.org/plan_9/1/vi

I resonate somewhat with the gripes about Emacs' crustiness. But on the other hand, I don't understand the complaints about it being ugly. I haven't heard that for a while. I'd like to think that my Emacs is quite pretty:

http://jlongster.com/s/emacs.png

There are things Emacs can do which VIM will never do. And vice-versa. They are separate editors embracing separate philosophies.

Lastly, keep in mind that this is 40 year old software, and considering that it's done a great job keeping up with the times.

I think most of the "ugly" gripes come from people who either don't know how to change the font or haven't bothered to turn the tool bar off.

That's true. I'm considering making a few screencasts that show how go from nothing to a full Emacs installation/customization on different platforms. I think that would be neat/fun.

Please do. Bonus points if you include something about Vimpulse (http://www.emacswiki.org/cgi-bin/wiki/vimpulse.el) to entice vim users to give it a try.

Cool, I haven't tried that library. I use the built-in vi-mode which does basic stuff.

Please check back with http://jlongster.com/ in a few months, I have plans to start doing this kind of stuff there.

I've added it to my calendar. I'll ping you at the end of July if there's nothing there at that point :).

I'm not trying to be snarky here, but if you change the font and turn the toolbar off what's left of the design?

If only you could configure Eclipse until nothing was left of its design!

I've actually gotten Eclipse into a fairly clean state: http://i.imgur.com/ln2N8.png

Most of the clutter is gone, but all of the nice IDE features (refactoring, immediate error detection, etc.) are still there. It's a nice way to work.

I run VS2010 in a similar way, though it is much easier to strip off the widgets.

Most of my co-workers don't understand how I can work that way. I tell them it's all about learning (or modifying) keybindings.

> what's left of the design?

Exactly.

Then you're talking more usability than design. In that regard emacs doesn't exactly rate well.

Emacs is very usable if you can make a few reasonable assumptions about the user. Obviously it's not perfect (see the discussion of changing fonts in the originally posted blog) but making those assumptions about the user allows for a great deal of capability.

I agree entirely, but capability and usability are unrelated concepts. I don't doubt for a moment that emacs is immensely capable, which is why it has a large following.

Usability is, according to wikipedia "the ease of use and learnability of a human-made object" Ease of use and learnability isn't exactly emacs strong points. As an obvious example you need to learn emacs-lisp to unlock its potential.

Capable: absolutely. Easy to use: definitely not.

Capability and usability aren't entirely unrelated. Applications with limited capability have no need to distinguish between initial usability and advanced usability. Applications with lots of capability must make tradeoffs, as ease of use and learnability aren't merely measures of the initial experience.

Emacs is easy to use and easy to learn, once you learn some of its basic quirks.

It's easy to use:

To start emacs, just type emacs. To open a file, type C-x f, then the path to the file (you can use tab-complete to enter the path). This automatically opens the file in a new buffer. You can open as many files as you like, and switch between the buffers with C-x b. To split the screen and see two buffers at once, you can use C-x 2 or C-x 3 depending on whether you want them aligned vertically or horizontally. Text entry and basic editing use most of the same conventions as the unix command line. C-a to go to the beginning of a line, C-e to go to the end, C-k to kill, C-y to yank. C-s forward-searches for a word. C-s again searches for the next instances.

Emacs is easy to learn:

To get a list of keybindings, such as the ones I mentioned above, type C-h b. This presents a list of hotkeys mapped to functions. The function names are descriptive. To get a more detailed description of any function in the list, simply put the cursor over the function name and hit enter. Press q to go back to your buffer.

Navigating the buffers can get complicated sometimes, and the function names can be archaic and definitely take some getting used to. There's also a lot of information available and it can be challenging to sort through it. But, all that information IS available and usually easy to get. That makes it easier to learn in the long run.

Also, to address your example, you don't need to know emacs-lisp to start appreciating its capability, and once you do start customizing basic configuration it's not too much more difficult than any other configuration language. From my .emacs, for example:

    (global-set-key "\M-[" 'start-kbd-macro)
    (global-set-key "\M-]" 'end-kbd-macro)
    (global-set-key "\C-b" 'switch-to-buffer)

It's very straightforward, once you know what "\M" and "\C" mean. At first, you don't really need to know what the single quote means, just that it's necessary. For something less intuitive:

    (setq inhibit-splash-screen t)

It's still pretty clear what that does.

> the ease of use and learnability of a human-made object

So usability has two separate definitions.

> Capable: absolutely. Easy to use: definitely not.

Actually, using Emacs is quite easy to use once you've learned it. Most operations can be done with much greater economy of motion than its main competitors. (vim excluded) It's the learnability aspect where it fares poorly, at least in the context of users who have been raised in a WIMP paradigm.

Seems like there is a third category lurking in here.

I find it easy to use--i have it on every platform and use it for almost all of my tasks.

But the third category I think you are leading up to here is the difficulty in learning. I admit that is not small.

Design means more than just visual design and graphical interface. For example:

    M-x <function_name>

Executes any interactive function. Any gui-based editor will ultimately be limited by the knobs and switches that can be crammed into various graphical interface elements. Emacs doesn't have that limitation. That's where the learning curve is steeper-- you have to search for function names rather than poke around menus or toolbars, but once you've learned the function name you can map it to a key, put it in your .emacs, or call it from another function.

Much like unix, this is how emacs has managed to stay relevant despite the popularity of the IDE market. It's easy to configure and extend by defining abstractions and composing functions.

But if one insists in staying on the fence, one has viper and vimpulse: http://www.emacswiki.org/emacs-es/Vimpulse

>They are separate editors embracing separate philosophies.

What are the two different philosophies?

From my limited experience with both: Vim is for editing text efficiently, Emacs is an allrounder. This is easily shown when you look at how they do things. In Emacs you have to press ctrl and/or alt for almost every keyboard shortcut. Personally I prefer the Vim way of having different modes, which let me keep my fingers in a comfortable position, while typing at full speed and utilizing all common, easily reached keys for shortcuts.

Lots of professional authors use "advanced" text editors for their stuff. And sadly, that often means old editors, because they often tend to have features that modern word processors lack (or make it easier to accept then). And of course once you get used to something...

There was a Salon article about people still using XyWrite[1]. As mentioned in the post, GRRM is one of the people[2] still using WordStar. I know that Steven Brust is using Emacs[3].

[1]: http://www.salon.com/21st/feature/1998/08/25feature.html/

[2]: http://www.sfwriter.com/wordstar.htm

[3]: from the front matter of http://dreamcafe.com/firefly.html

Steven Brust worked as a programmer before he was a full time novelist, according to his son, who is also a programmer.

Another example: Vernor Vinge (sci fi author, and a former math and CS professor at San Diego State) uses emacs [http://www.norwescon.org/archives/norwescon33/vingeinterview...]

Yet another example would be Neal Stephenson:

"I use emacs, which might be thought of as a thermonuclear word processor."

- In the Beginning was the Command Line http://www.cryptonomicon.com/beginning.html

That was written before his conversion to Mac OS X.

We don't know if it still applies.

There's something fishy about an emacs article that doesn't mention vim at all.

He mentioned being affected by cognitive dissonance when referencing other editors - he was probably thinking of vim :)

A lot of modern IDEs provide features that are pretty close to magic, compared to what emacs sports. The emacs user response to this generally seems to be something like, "Code navigation can't be as good as M-x rgrep", and "How can refactoring ever be as good as C-M-%?"

This reminds me of various people I have worked with in the past who have wondered why I ever bothered with the complexity of searching and replacing with regular expressions, when you can just do a normal search and replace, watch for matches that match the more complicated thing you're actually looking for, then replace them by hand...

> A lot of modern IDEs provide features that are pretty close to magic, compared to what emacs sports.

Which modern IDEs and what features? I have used eclipse for months before deciding I was better off with emacs with eclim-mode anyway to provide the only two features of eclipse I liked: the compiler and the ability to see the members of an object (occasionally).

I work on a 5GB source tree at work with a couple (or more? I haven't looked) thousand Java source files. After my last machine decided it would be a good time to crap out and I started over with a new OS X install, I tried working strictly with vim and emacs and our scripts (written by vim aficionados, it seems) to navigate around the codebase.

It was like a root canal. If I was on fire.

Seriously--I'm not an Eclipse fan by any stretch, but Open Type alone saves me hours of frustration a week. Its code completion isn't nearly as good as Visual Studio's, but is a lot better than ctags. And its source generation (implement getters/setters, override inherited methods, even just basic context-aware renaming) is fantastic, too.

IME--and this is something of a generalization because I know fantastic programmers who use vim and emacs, and I use either where I have to--the folks who tout them are either using languages where IDEs are less effective (although this is still dubious--NetBeans has surprisingly good intellisense for PHP and Ruby, at least) or don't realize what the IDEs can do for them on a regular basis.

> I work on a 5GB source tree at work with a couple (or more? I haven't looked) thousand Java source files.

the linux kernel is 14 million lines of code and the size of its source tree is 500MB, you are working on a source tree that is ten times the size of linux? 140M lines of code? In any case it can't be all 140M LoC in a couple thousand java files so something should be clarified.

> I'm not an Eclipse fan by any stretch, but Open Type alone saves me hours of frustration a week.

ido-mode plus tags file worked well to replace Open Type for me. Before that I used a stupid five line bash script.

> don't realize what the IDEs can do for them on a regular basis.

Or maybe you don't realize what you can do with a good editor. Good, modern IDEs have some good features, better than what you can do with emacs/vim however:

a. they are not good editors (and insist on being one)

b. they are not good window managers (and insist on managing your windows)

c. their usefulness degrades quickly depending on the build system/language you use. If you need to quickly glance at the source of a library you just downloaded they are no help at all.

No, it's not all code, but glorified shell script call-outs from vim, etc. have to walk the entire thing far too often for my liking. (Unless something has recently changed, tags files have to be rebuilt in their entirety after a svn up - Eclipse just reindexes the changes.)

As for "not realizing what a good editor can do"--remind me how I get context-sensitive renaming or method extraction in emacs or vim? These features are critical when you're dealing with sufficiently gigantic amounts of code (especially the crufty kind), and if I really wanted I could get a full set of vim keybindings for Visual Studio (albeit the Eclipse ones aren't quite as accurate).

(And can we lay this holier-than-thou claim about "good editors" to rest already? The idea that editors that don't require six fingers on each hand or a modal personality are "not good editors" is patently silly and I have no interest in stooping to that level. You don't like them. That does not make them "not good," it means you don't like them. I grew out of that sort of thing when I was 15 or so, and am pretty much identically productive, in terms of just writing text, in emacs or a standard editor; I'm close in vim, but I only picked vim up a few months ago. When you stop identifying yourself based on your text editor of all things it stops being a material factor in your ability to get things done.)

> remind me how I get context-sensitive renaming

You don't but I did tell you that IDE do some things better.

> method extraction

After the third time eclipse crashed and deleted code while I was trying to do this I'm not really sure how you can get method extraction working in eclipse either.

> And can we lay this holier-than-thou claim about "good editors" to rest already? The idea that editors that don't require six fingers on each hand or a modal personality are "not good editors" is patently silly

Agree, but it's also silly to think that any editor is a good editor and the ones in IDEs are not.

> I grew out of that sort of thing when I was 15 or so

Talk about holier-than-thou...

C. For Java, at least, Eclipse will automatically display Javadoc for a library you download (in both mouseover hover and a sidebar window) , and will navigate to source if the library has an attached source jar (which maven will usually find from a Repository )

Does it in PHP PDT, too.

Don't use ctags, they're garbage.

--- Emacs user that uses a lot of "IDE esque" features

What do you use instead?

I used to use pymacs and ropemacs with python, but it broke in hard to determine ways, and then on my latest project it was horribly slow, so I stopped.

I still live in emacs

I use pymacs/ropemacs, but for generalized search I use ack-mode.

If I know what I'm looking at, go-to definition is perfectly fast even in huge projects. (My day-to-day project is quite large.)

I know the generalized search sucks/is slow, I've been meaning to fix it myself for some time.

The take-away I got from your post is if I need to deal with "enterprise-size" crapware I'm better off using IDEs. That is certainly an interesting niche, but why would I ever want to work on "enterprise-size" crapware?

I've used JBuilder, Eclipse, NetBeans, and Visual Basic 6. None of them address a fraction of the things I actually need or like to do on a regular basis (edit files remotely, browse directories, use a shell, actually edit text efficiently). At work my Emacs session has files open in four different programming languages. There's nothing stopping people from writing refactoring tools for Emacs (take a look at Xrefactory), it's just that grep and dired and search-replace are universal tools that are good enough for all occasions. If you need something else it's easy enough to use macros or write elisp code to do it (ever try writing an Eclipse plugin? that works with multiple versions of Eclipse?).

You are assuming that your use case is typical. It's not. Eclipse may be better at your use case, but it fails miserably at the things typical Emacs and vim users need.

> That is certainly an interesting niche, but why would I ever want to work on "enterprise-size" crapware?

Because it pays the bills, and pays them quite well.

> it's just that grep and dired and search-replace are universal tools that are good enough for all occasions. omething else it's easy enough to use macros or write elisp code to do it

Extract a superclass or an interface with them. Automatically and contextually build your getters/setters in Java/properties in C#, respecting visibility and implementing proper logic in the case of constant or final fields.

I'm not going to hold my breath waiting for you to do either. Emacs is nice enough, but it's absolutely silly to claim that context-insensitive tools are "good enough for all occasions."

And I would be pretty easily called a user of both emacs and vim. Both are tools for specific use cases. They are not, as the strange culture of text-editor-worshippers would like to claim, inherently superior as editors simply because you know them.

"Because it pays the bills, and pays them quite well."

Why don't you just go into investment banking or law or medicine instead? All those careers pay a lot more than doing copy-paste on millions of lines of crap Java code, which I highly doubt you like doing anyway.

I pay the bills by doing things I'm interested in.

Refactoring. In Visual Studio I can click on any usage of a badly named class, press F2, type in the new name and it will be updated everywhere. Even the name of the file holding the class is updated.

More importantly, it won't be updated for things that aren't it. As in, you can have a class called 'i', used in 50 files, and confidently replace those usages and only those usages with another name. That's something you just plain can't pull off with Regular Expressions.

[waits for somebody to post the 4000 character Regex that actually does this correctly]

Yes, access to the syntax tree generated by an interpreter of the language based, I guess, on the current buffer mode, would be very helpful.

The modern IDEs I am thinking of are Visual Studio (appropriately tarted up with Visual Assist) and Xcode. Yes, unoriginal, I know, but what can I say? Anyway, people always tell me these two are rubbish, so I assume everything else must be at least somewhat better.

Perhaps I was guilty of hyperbole, and "magic" is excessive. But stuff that comes out of the box in the above IDEs, and in its out-of-the-box state is slicker, easier to use and requiring less effort on one's own part than in emacs:

- Symbol browsing with search by substring, so you can leap to a symbol knowing only its name or part thereof;

- Project file browsing with search by substring, so you can open a file by name or part thereof;

- Pretty reliable jump-to-symbol with context sensitivity (so p.xyz, say, will take you to the right xyz), so you can find something given a valid mention of it in the source code;

- Popup code completion without my having to do anything funny or wait for the next build;

- Refactoring - OK, actually my use of refactoring tools could probably be done in emacs without making me want to die, but I know people who like 'lift method' and all that other junk, which would be basically a manual process in emacs.

I tried a couple of things to try and bring this stuff to emacs. M-x imenu, M-x ctags, CEDET and ido-mode are the ones that stick in my mind. None of them were up to much, though I wrote some helper functions to combine ide-mode and imenu, and I was somewhat pleased with the result. Then I upgraded emacs, and they stopped working. I took this as a sign, and didn't bother rewriting them. I don't use emacs for C/C++ any more.

>A lot of modern IDEs provide features that are pretty close to magic, compared to what emacs sports.

This is true, so why did I go with vim?

Well first, I'm primarily using Ruby not Java, so the magic available in IDEs is somewhat diminished. But more to the point, vim is really well optimized for the widest array of types of editing. It also has the advantage of critical mass open source immortality.

So when I hone my vim/emacs skills, it's an investment for the next 50 years, during which time I'll have no problem using my preferred editor on my preferred platform with whatever languages happen to be striking my fancy.

I use Visual Studio to wrangle giant enterprisey C# applications, but I still use find+grep/Emacs for browsing code quickly. Visual Studio is a long way off from matching the simple blazing speed of grep and file buffers in Emacs.

P.S. I'm not sure why I'm being downvoted. It's what I do. There's really no debate about whether grep is faster than VS search.

VS mimics both to an extent by allowing you to search with regular expressions and to choose to search from a file system context instead of project context. My favorite thing about this is I also use viemu, and I can search VS's search results using vi commands.

your argument about code navigation in emacs is inaccurate, though "M-x rgrep" is used heavily. at least there are gtags. and now there is auto-complete. For C/C++/Obj-C, clang+auto-complete stand there.

My typical responses is that replace-* modify+isearch macros are good enough that I don't miss having refactoring tools that parse my code on the fly.

My projects are usually not large enough that it matters. If they were, I suspect my typical response would be that I would simply install the appropriate mode for emacs and use that.

Why should an emacs article mention vim? The author probably isn't qualified to fairly compare them and so doesn't bother trying. The focus is also writing prose rather than coding or basic text-editing.

The differences between vim and emacs are so fundamental that once someone goes down the emacs path it's not uncommon to never turn back.

tl;dr

Use Emacs 23 to create a distraction-free writing environment using org-mode, darkroom-mode & markdown-mode.

I'm not directing this at you personally, even though I am responding to your comment, but do we really need "tl;dr" type comments here on Hacker News?

I am ashamed, but part of the reason I read HN is for the tl;dr comments...

> do we really need "tl;dr" type comments here on Hacker News

Yes we do. They serve to save people time.

They would save more time by simply not coming here. They can save lots and lots of time by not reading anything. Additional knowledge takes time to read and then adds time to your decision making process. Too many choices. These people should just write out a schedule and keep to it perfectly. No distractions, no extras, no discovery. No need for people to read things to understand them. Simply let someone else read them for you and tell you what to think.

I think your criticism would carry more weight if this news site wasn't a firehose linkdump format.

  They serve to save people time.

Or to draw attention to a succinctly formulated essence of an article. They help me in focussing on the articles that may be of interest.

I can't speak for HN, but I appreciate them. It's nice to see what other people get out of the articles. Usually the discussions here are more interesting than the article so it also allows me to understand what everyone is talking about without having to read sometimes lengthy articles.

IMO, "tl;dr" is a misnomer. Or at least, I don't value such a thing as an alternative to reading the post. There's no way that one line captures the whole article, it captures that one person's main takeaway. Rather than assuming that such a thing tells me everything I need to know, or thinking it can help me understand the nuänces of the discussion, I take it as one reader's executive summary which will help me decide whether to read the entire post.

In this case, I read it as "A good read if you want to know how/why/whether to use Emacs-23 as a distraction-free writing environment."

The post has other value, of course, and I wouldn't object if someone else were to write something like:

tl;dr: Emacs continues to evolve, e.g. It's now as good a tool for writers as Scrivener or dedicated distraction-free editors.

That would give me another reason to read the post if I wasn't persuaded by the first. Summaries (including the title, natch) provide some value that a simple upvote score does not capture.

I guess the question is whether it's a misnomer or not.

I find "Too Long Don't Read" to be a dismissive attitude that I don't want here on HN, so I almost always vote down such comments (yes, including the ancestor here). But I appreciate executive summaries, and frequently vote them up to encourage their creation even if I didn't find the article itself compelling.

I realize that "TL;DR" is "just an abbreviation", but parsimony encourages me to conclude that it still connotes the words that it abbreviates and represents an attitude I do not like. Perhaps I'm reading too much into word choice, but in the end, word choice is really what makes the comments here worth reading.

tl;dr: http://raganwald.posterous.com/why-i-downvote-tldr-comments-...

It really depends. evangineer's tl;dr comment was a decently accurate summarization of the content of the article. If you're meaning the typical "tl;dr [witty/sarcastic comment about TFA's author's shortcomings]", sure, those don't belong on hn. evangineer's comment seemed genuinely useful, though.

Thanks. I've been using tl;dr as a shorthand for this is my summary of the article in question. I now appreciate that not everybody sees it like that. In future, I shall refrain from using tl;dr and just summarize without any preamble.

Beginning the comment with "Summary:" would be helpful.

Everyone is already using a filter (HN) to avoid doing some work: reading everything that is posted on the web.

For me, tldr is a favor folks more interested than me in some subject do, and I should do the same when I subject I really care turns up.

tldr is an act of love.

For linux environments, instead of darkroom-mode you can put this in your .emacs file to toggle fullscreen:

  ;;; Fullscreen
  (defun switch-full-screen ()
    (interactive)
    (shell-command "wmctrl -r :ACTIVE: -btoggle,fullscreen"))

  (global-set-key (kbd "<f12>") 'switch-full-screen)

Alternative if you don't have wmctrl installed (not default in Ubuntu for example):

  ;; Fullscreen
  (defun switch-full-screen ()
    (interactive)
    (x-send-client-message nil 0 nil "_NET_WM_STATE" 32
                           '(2 "_NET_WM_STATE_FULLSCREEN" 0)))

  sudo apt-get install emacs23-nox

;-)

Another alternative that, AFAICS, doesn't use anything external to emacs

    ;;; Full-screen mode
   (defun toggle-max-window ()
      (interactive)
      (set-frame-parameter nil 'fullscreen
                       (if (frame-parameter nil 'fullscreen)
                           nil
                         'fullboth)))
   (global-set-key (kbd "<C-M-return>") 'toggle-max-window)

You can also start using xmonad.

I'm pretty excited about this post. I first began using vi in 1983 and Emacs in 1986, and have switched back and forth between the vi/emacs families of editors as my needs have changed and their capabilities have changed. I've been on gvim for the last few years because of it's superior GUI integration, but it is not good for writing prose, which I do more and more of these days. I have not found something I really like for writing, and end up using MS Word by default, which does not make me happy. I had not heard of visual-line-mode, so I'm ready to give emacs a try again. I just installed Aquamacs, and I'm using it to write this comment in full-screen mode. I will also give org-mode a try because I'm always looking for better ways to organize my writing.

Keep in mind that while Aquamacs is better visually integrated in MacOs, some features may not work as well as in the standard (gnu) emacs.

Haven't peeked under the covers in years---this is enough to make me go take a look. Now if someone would write a mode for time-lines then that would pretty much finish up the usual writer (fiction) shopping list.

Org Mode's agenda has something like that: http://orgmode.org/manual/Timeline.html

He's talking about Emacs 23.

I've spent the last month or so head first learning VIM - I forgot about org-mode before deciding on VIM. There are a number of clones but nothing seems complete. Any recommendations?

Well the orgmode.org homepage calls out one[1] in particular:

"2010-11-25 Thu: Maybe the times where Org mode could change hard-core vi users into honorable Emacs users are coming to an end? A Vim clone of Org mode is be written by Herbert Sitz, and judging by the videos it looks promising."

Haven't used it, though.

[1]https://github.com/hsitz/VimOrganizer

I'm the author of that clone. I'm making progress, and it's building up to a fairly nice subset of org-mode, but it's not something that would satisfy any truly hardcore org-mode power user. At least not any time in the near future.

The previous poster complained that none of the Vim plugins that try to mimic or clone org-mode "seem complete". That is definitely the wrong way to look at things. Org-mode is a huge app that's been heavily developed for six or seven years now. In some ways org-mode is probably like Microsoft Word: probably 75% of its users access only about 25% of its features, although many of them access a different 25%.

Why try to develop an org-mode clone in Vim, then? Mostly as a personal project I started for fun. I tried switching to Emacs just so I could use org-mode. Even with Viper and Vimpulse add-ons Emacs felt too clunky to me. I had previously worked on a Vim outliner and I knew that part wouldn't be too hard to replicate in Vim. I decided not to stop there and I've gone on to a lot of other features, although it's a fledgling project. In particular, I need to get some decent documentation done. There are a ton of features in my clone that users have no idea are even there. I think so far most of them (like most org-mode users?) use it mostly for simple outlining.

The Vim clone uses a file format compatible with org-mode and actually calls out to an Emacs server to have org-mode do exports to LaTeX/PDF, HTML, etc. So pure document authoring (as opposed to PIM/task management stuff), is one task that the Vim clone probably can do a decent job of now. Adding footnote support is on the list (there's already a Vim footnote plugin that I plan to modify to work with the org-clone).

As a former Vim user, I use viper-mode with emacs. Org-mode really is a mature, powerful killer app for emacs and there is a whole ecosystem of tools and addons that make it even more valuable.

I would accept no substitutes at this stage.

For those who prefer a language with namespaces (python) sublime editor is a good modern alternative.

I've been using emacs for a few months now (it's surprisingly good), and am starting to run into wanting to do little modifications. Speaking as a non-lisper, I really wish a rewrite existed in a more modern language. I don't wanna start an argument about lisp here but there is a reason people don't use it for major developments, and it's not the performance. But it would be unfair not to point out that you can extend emacs in a variety of languages including python. Its just a bit messier.

First of all, various members of the Lisp family are used for major developments.

Secondly, rewriting Emacs would be a major undertaking and which modern language would it be? My choice would be Common Lisp, for other developers it would be Clojure, Haskell, Python, Ruby, etc. Whatever choice it would be, you'd lose developers who would rather see Emacs rewritten in one of the other languages. Even worse they might spawn forks in their own favourite languages.

I'm a beginner at programming, and am wondering which text editor to use. Emacs or TextMate?

Try out xiki (http://xiki.org) its a wrapper on top of emacs that adds a bunch of shortcuts, and its built using el4r so all the extensions are ruby based.

basically

Emacs beats every other editor. Yes, including Vim both because you have a Vim clone inside Emacs and because once you start pushing the limits of Vim, just like the developer of Slim-Vim, you'll find yourself implementing Emacs. Vim's editing model is great - and that's what I use - but it ain't Emacs.

Emacs has its warts, but it's your best choice if you want a serious editor.

Bashing an editor because its support for programming languages whose programmers have chosen other platforms, is not fair. Comparing Emacs to Eclipse or Netbeans when it comes to Java development is not fair, just like comparing Eclipse or Netbeans to Emacs when it comes to Common Lisp development is not fair either.

Using a general-purpose editor instead of a specialized tools means that everything you learn will serve you in every other editing task.

If you are not serious about editing text, then you will be

But, truth to be told, Emacs isn't even an editor: it is an Emacs Lisp interpreter which by default runs a program to edit text.

Continued:

If you are not serious about editing text, then you will be served by many other editors.

Downvoting without explanation? Fine, I love my competitors using lesser tools.

    * Being needlessly argumentative
    * Borderline trolling. You _know_ how these arguments go.
    * Fallaciously arguing that tools cannot be compared based on how well they get the job done 
        (IDEs vs 'editors') rather than their implementation
    * Getting pissy about downvotes and posting multiple times instead of editing

You've been here a year. You should know better.

Thank you for your clarification. I don't understand why I have been perceived as argumentative.

I've been using Emacs for quite some time now, and before immersing myself into it, and even after, I've compared it to other major editors. Eventually, I realized that no other editor can stack against it, if you are really serious about getting the most out of your editor, and reaping the highest return of investment out of the time you spent learning it.

Maybe some people don't like the idea, but just like there are superior languages, as PG as neatly demonstrated, there are superior tools. Things you can accomplish with Emacs, you really can't with other Blub editors.

Oh, and when I talk about Emacs, I'm not talking about its editing model, which I agree, is somewhat cumbersome. Vim's editing model is way superior, and it's my editing model of choice, but Emacs' implementation is better. Vim enthusiasts are aware of the limits of their editor. For a story, read here: http://bradbeveridge.wordpress.com/2007/06/21/how-a-vim-user...

Reply on news.ycombinator.com