
Why Emacs is a better editor – case study for JavaScript developer - lelf
http://blog.binchen.org/?p=901
======
mickeyp
Js2-mode is an interesting case of an author (Steve Yegge) going against the
fold of how Emacs is supposed to interact with programming modes -- by writing
his own parser and syntax highlighter and eschewing the built-in way, which is
to use Emacs's font locking, which itself is driven by regular expressions and
the odd lisp function.

It's a shame Emacs lacks the facility to properly capture the more complex
requirements of languages today - especially files with mixed content, such as
HTML, Javascript and templating tools. The few that do support this do it
using a variety of clever hacks to work around this problem; and still, using
regular expressions to capture the nuances and complexities of some languages
make it an error-prone way of writing major modes in Emacs. Not to mention you
lose out on the many advantages of having an AST in memory for code jumping,
refactoring, syntax checking and what have you.

Emacs could do with a shake-up in this space. The proposed solution (Semantic
Mode / CEDET) has never really caught on, even though it adds much of the same
functionality to Emacs; my suspicion is that this is because Semantic/CEDET is
ridiculously complex and lacking in documentation.

~~~
klibertp
> Semantic/CEDET is ridiculously complex and lacking in documentation

So, sooo much this. And it's a real shame, because semantic is quite a usable
tool once you get to know it.

One thing I really wanted to have was a semantic index, a database of semantic
symbols inside a project. I wanted to be able to write "Form" and have it
display all the class names containing "Form". Grepping (even ag) is just much
too slow and building my own index was too much work. I then saw "semanticdb"
module.

A week, I'm not kidding, a _week_ \- instead of half an hour - later I finally
managed to preload a custom tag database and to query it. And that was with
Python code, which has Semantic parser already, which is well integrated into
the rest of CEDET.

Now I'm fighting with CoffeeScript/LiveScript support. They both expose their
parsers - I can get their AST with one line of code. After another week I
still don't have working Semantic plugin for them.

When I last checked, the activity on a CEDET and Semantic mailgroup was almost
non-existent. The home page for CEDET looks like it comes from last century
and even info pages are not a big help.

It's a friggin shame, because when Semantic works, it does work well.

~~~
deng
>When I last checked, the activity on a CEDET and Semantic mailgroup was
almost non-existent.

[http://news.gmane.org/gmane.emacs.cedet](http://news.gmane.org/gmane.emacs.cedet)

Sure, it's not LKML, but still, questions usually get answered.

> Now I'm fighting with CoffeeScript/LiveScript support. They both expose
> their parsers - I can get their AST with one line of code. After another
> week I still don't have working Semantic plugin for them.

I'm afraid an AST is just the beginning for properly supporting a language. If
you need help, don't hesitate to ask on the mailing list.

> The home page for CEDET looks like it comes from last century and even info
> pages are not a big help.

Yes, unfortunately.

------
marijn
Emacs Lisp is such a horrible language, and the Emacs ecosystem is so firmly
stuck in the past (mutable state and magic hidden side effects and
interactions everywhere) that writing extensions for it is much harder than it
should be. It has enough history and a smart enough user base to have a lot of
cool functionality, but the idea that it is somehow exceptionally wonderful
just doesn't hold.

(I use Emacs for all my coding, and Common Lisp is my favorite programming
language, so, if anything, my biases would be in _favor_ of Emacs. Sadly, it
doesn't really deliver -- not that other editors get their interface right.
Don't get me started on vim. ST is somewhat better, but doesn't expose
powerful enough tools. If I may toot my own horn, I believe my own project,
[http://codemirror.net](http://codemirror.net) , does a lot of things right on
the editor API level that popular editors get tragically wrong.)

~~~
freyrs3
Elisp is bad, but not nearly as bad as vimscript.

~~~
SwellJoe
For what it's worth, you can also write Vim extensions in Python. It's got
access to all the same stuff as Vimscript. I would argue that Python is the
better language when compared to elisp (even if one believes CL or other full-
blown Lisp or Scheme variants are superior to Python).

I'm not saying that makes vim a better editor than emacs. Just pointing out
that vim has other options for extending. Also, I use vim and haven't found
emacs to be more productive; in my college days I tried emacs, in earnest, for
a few months. I came back to vim eventually, and haven't felt compelled to
give emacs another go since.

~~~
terhechte
The Emacs/ELisp API, however, is far better. If we assume for a moment that
ELisp and Python are, for the act of writing a editor extension, in similar
good shape. Then it is still easier to write a good plugin with elisp for
emacs than with python for vim, because the API that emacs offers for the
integration of scripts is really, really fantastic. Vim doesn't offer anything
like that.

------
bjourne
The point is that js2-mode _interprets_ javascript which enables it to offer
much more exact syntax highlighting and navigation than purely regexp based
approaches. FWIW, js2-mode is an exception and most of emacs highlighting
comes from regexps via font-lock mode. The author could have made the same
point about Visual Studio vs other editors as the former parses syntax which
most others don't.

~~~
mickeyp
Indeed. But it's still a nice thing to be able to do; this is, after all, the
Emacs way -- for good or ill!

One useful technique to make Emacs appear cleverer than it is vis-a-vis code
searching and navigation is to navigate by syntax highlighting - most of which
is assigned one of several types (constant, keyword, statement, etc.) -- and
simply use that. It's hardly perfect, but it's good enough for 90% of the
basic navigation you need to do.

~~~
S4M
>One useful technique to make Emacs appear cleverer than it is vis-a-vis code
searching and navigation is to navigate by syntax highlighting - most of which
is assigned one of several types (constant, keyword, statement, etc.) -- and
simply use that.

How do you do that?

~~~
mickeyp
I'll have to polish off some of the code I wrote ages ago and share it on my
blog (see my profile.)

~~~
S4M
OK, I'm subscribing to your blog. Thanks for sharing.

------
pjmlp
Sorry, but what set of Emacs plugins are able to offer what Netbeans does for
HTML5 development?

[https://netbeans.org/features/html5/index.html](https://netbeans.org/features/html5/index.html)

~~~
Expez
[https://github.com/skeeto/skewer-mode](https://github.com/skeeto/skewer-mode)

~~~
pjmlp
That is just a subset of what Netbeans offers.

------
johncoltrane
I kind of feel the hacker spirit in what you did but… what about fixing your
JavaScript instead?

Sublime Text: [http://imgur.com/p27i5L7](http://imgur.com/p27i5L7)

Vim: [http://imgur.com/OlVbSdO](http://imgur.com/OlVbSdO)

~~~
klibertp
No.

The tool _should_ support even the most hideous constructs; saying that "but
what you wrote could be written better" is completely orthogonal to "the tool
couldn't handle it".

~~~
coldtea
> _The tool should support even the most hideous constructs_

Nope, the tool should choke on hideous constructs, and make you write them
properly.

See how I provided just as many arguments as you?

~~~
DrJokepu
Have you ever worked with legacy code?

~~~
reverius42
Legacy code, at some point in the past, was somebody's new and beautiful code
(or so they thought -- little did they know it was hideous). If the tools that
existed then didn't allow them to do the hideous things they did, you wouldn't
be calling their code "legacy" today.

------
spullara
If you are going to argue for a tool that understands the semantics of the
language you are editing, you are doing yourself a real disservice not using a
JetBrains editor if they support the language. They do support Javascript and
their support is quite great.

------
Prefinem
An editor with a plugin with code I modified makes this the best editor...

Because anything you put time into to makes it automatically better for your
use case is _actually_ better.

------
h1fra
This is quite stupid. Saying emacs is better but showing that emacs do
actually the same sublime text mistake.... Emacs is extensible; ST too.

~~~
caipre
AFAIK, ST2 doesn't have a plugin for a Javascript interpreter (though I
haven't used ST2 for over a year now). You could extend the
javascript.sublime-language file, but that only supports regexes so you won't
have the same context as with the AST.

Your main point stands though: all major editors have the ability to add
plugins to achieve this same functionality.

~~~
shawndumas
[http://ternjs.net](http://ternjs.net)

Tern is a stand-alone code-analysis engine for JavaScript. It is intended to
be used with a code editor plugin to enhance the editor's support for
intelligent JavaScript editing. Features provided are:

    
    
        *Autocompletion on variables and properties
    
        *Function argument hints
    
        *Querying the type of an expression
    
        *Finding the definition of something
    
        *Automatic refactoring
    

There is currently Tern support for the following editors:

    
    
        *Emacs
    
        *Vim
    
        *Sublime Text
    
        *Brackets (built in to the base editor)

------
platz
Fwiw, visual studio evaluates your JavaScript similar to this providing you
pretty good js intellisense/autocomplete

------
podperson
The key thing is that javascript is built into emacs, which is a good argument
for javascript to be built into any serious programmer's editor (since (a)
chances are good the programmer knows javascript, (b) you can get a good
javascript engine for cheap, (c) many programmers will actually be using your
editor to write javascript as a bonus).

I was playing around with another interesting editor (Chocolat) which actually
uses a Javascript engine to identify symbols in Javascript source files; but
it does this far worse that can be done easily with regex (and in fact makes
terrible errors doing so).

Indeed, better results than that shown in the article are achieved by fancy
new editors (like Espresso) and crufty old editors (like BBEdit) using regex
and brute force. Fundamentally you've got an anonymous function or a function
with a common name, and you want some outer context to further identify it --
regex can do that.

------
watson
I wonder why he obfuscated the "validOptusUsername" key in the screenshots

------
pulmo
Serious question: Did anyone ever chose an editor because of some "Why X is
better than Y" article?

~~~
skylan_q
"Why X is better than Y" would be too clean-cut for my case, but it's not far
off.

I wanted to start learning lisp and was told emacs was the best choice for it.
I read that Richard Stallman made it and Linus Torvalds uses it. That was
enough to get me started and it's now my editor of choice.

But that's not to say that I don't know how to edit, save, search and (force)
quit vi. :)

------
vezzy-fnord
tl;dr Emacs is extensible.

------
csmuk
Kevin Flynn uses vi - 'nuff said:

[http://i.imgur.com/rMdKYde.jpg](http://i.imgur.com/rMdKYde.jpg)

(this is in jest but no doubt I'll be downvoted...)

~~~
pault
Where is vi? I only see two shell sessions and top.

~~~
blueblob
You won't see it in top, it doesn't use enough resources. :p

~~~
csmuk
Well played :)

------
SimHacker
The wrong people have been drunkenly driving Emacs into the ditch for the past
decade or so, and they're really screwed it up in so many ways, usually trying
to be way too clever and solve problems that really aren't worth solving.

They made "line-move-visual" the default, which in the service of making Emacs
behave more like Microsoft Word, it makes ^N and ^P across wrapped lines stay
on the same line and move to the part of the same line that is wrapped above
or below the cursor, totally breaking type-ahead predictability and keyboard
macros. That totally pissed of the late and long time Emacs user Marc Crispin,
and he explains why it's such a terrible idea that breaks keyboard macros:
[http://compgroups.net/comp.emacs/line-move-
visual/274792](http://compgroups.net/comp.emacs/line-move-visual/274792)

It totally breaks keyboard macros, one of the most important things about
Emacs. It definitely should not have been made the default, since keyboard
macros are a way of life for real emacs hackers. I totally agree with Marc's
take on the problem, and I am terribly disappointed that RMS let somebody get
away with changing it that way, and making that horrible mode the default.

They just can't stop trying to make it more like Microsoft Word, while failing
to actually achieve that goal, and only succeeding in inflicting half-assed
solutions with harmful unpredictable side-effects on the users.

Another example is how the region highlighting and the weird pending delete
behavior terrorizes me that sometimes but not all the time according to rules
I just can't figure out or tell by looking at the screen, when I type
something that I intend to insert, a huge chunk of my buffer might just
disappear, but sometimes it doesn't. So now Emacs has become unpredictable and
malicious. I have to do a dance of "insert character, undo" to know that I
have canceled the pending delete mode. You can't tell if you are in pending
delete mode just by looking at the screen and seeing the obnoxious
highlighting, because sometimes it highlights the region and isn't in pending
delete mode, and sometimes it highlights the region and is in pending delete
mode. I just wish it would stop highlighting the region, because any time I
set a mark and move around, it highlights half of the screen at no use to me,
and that just gives me a headache, and I have to insert a character an undo it
to cancel the highlighting, and until I cancel the highlighting I am living in
terror that my next keystroke will delete a huge unseen portion of the buffer.

And the thing that REALLY pisses me off is the lame-assed attempt to make ^A
and ^E ignore the prompt in shell mode. There is an extremely simple reliable
solution to the problem of separating the prompt from your input in shell mode
so you can always get to the beginning of the line with ^A, and that is to
have a newline at the end of your prompt, so every line you type in is on the
whole line and does not have a prompt prefix, therefore no half-assed magic is
necessary.

But the half-asses magic is terribly implemented and has bizarre side-effects
that screw me all the time: I get these fucking invisible force fields
inserted into the line between my characters whenever I yank some text onto
the line that has a prompt or a command line on it, and I can't move past them
with ^A or ^E (but sometimes I can -- they're not predictable which is even
worse)! And I can get any number of these fucking invisible force fields on my
line, so in order to get to the beginning of the line I have to go ^A, look at
the screen to see if I made it, type ^B ^A if I didn't, again and again, until
I drill past all the invisible force fields that are trying to make my day
happier.

And then I have to mark the beginning of the line I want to edit and repeat,
go to the end of line by drilling back some number of opposite facing
invisible force fields (which may be in different places than the ones going
the other direction), and then kill the region, go to the end of the buffer,
then yank the entire line to get a copy of it without any fucking invisible
force fields in it.

But if there is an invisible force field in the line, or I just want to edit a
few characters of the line and that adds some invisible force fields that were
not even there before, and then I hit return in the vain hope of re-entering
the entire line but not the prompt, it just enters the tail of the line after
the last invisible force field, making an error in the shell, or sometimes
even executing a totally different command than I intended and totally fucking
me over.

I would really like somebody to explain what the fuck the idea behind the
invisible force fields are, and give me the address of whoever thought is was
such a brilliant idea, so I can send a robot drone to firebomb their house, or
worse yet send RMS to live with them for a few months. Why did they do
something so terrible, that totally fucks up such common important operations,
to solve a trivial problem that has a much better solution?

Emacs used to be totally predictable. I learned it at 300 baud over the
ARPANET on ITS, and I could type ahead hundreds of characters to do all kinds
of stuff, and then go take a piss or get a drink or take a bong hit, and come
back later, and it would be in exactly the state I meant for it to end up in.
Now, I can't do that even on a local display. And for some fucking reason, it
waits for up to five seconds sometime before updating the display when I'm
running it in a terminal (especially when I start an incremental search or
query replace). What the fuck is that about??! Not only is it totally
unpredictable and forces me to stop what I'm doing and wait for it to catch up
so I can figure out what state it guessed its way into before going on, but it
won't paint the screen for five seconds when running on a modern top-of-the-
line computer!

Emacs has become a shrine to outrageous violations of the principle of least
astonishment. I just can't figure out how they could have come up with so many
ways to corrupt it, when it used to work so well. It's totally unpredictable
now, and I can't type ahead any more, so I have to type a few characters, look
at the screen to see how it misinterpreted my intentions, and then try to work
around the misunderstanding.

------
nichochar
vim.

~~~
Symmetry
Could you elaborate? Have you seen someone intagrate a javascript interpreter
the same way with vim, or are you saying that modal editing is enough of a
productivity boost to make up for it's lack?

~~~
platz
Don't feed the trolls

------
meepmorp
Let's see if this triggers the flame war filter.

------
algorix
and... here... we... go.

