12 ms·

Why Emacs is a better editor – case study for JavaScript developer

139 points by lelf 13y ago

algorix 13y ago
and... here... we... go.
vezzy-fnord 13y ago
tl;dr Emacs is extensible.
nichochar 13y ago
vim.
- Symmetry 13y ago
  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?
  - Sanddancer 13y ago
    http://www.vim.org/scripts/script.php?script_id=2375 http://www.vim.org/scripts/script.php?script_id=2375 this seems to get a good chunk of the way there. Yes, vimscript absolutely sucks, but vim makes up for it by allowing one to write hooks to pull in pretty much any shared library you can think of. One can also embed python, perl, ruby, etc into vim pretty easily to have it available as well.
  - snogglethorpe 13y ago
    Note that for those that prefer vi-style modal editing, emacs has some very good vi/vim-emulation modes.... ^^;
  - platz 13y ago
    Don't feed the trolls
h1fra 13y ago
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 13y ago
  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 13y ago
    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)
  - coldtea 13y ago
    >AFAIK, ST2 doesn't have a plugin for a Javascript interpreter Yes, but the important thing is that it CAN have one, same as Emacs could. For example, it has a Go plugin which uses the Go AST.
- mickeyp 13y ago
  I think you're misunderstanding it. JS2-mode is a few years old and a generic javascript mode with a built-in AST and all the goodness that comes from that. It does not inherently understand require.js. Nor does ST. With Emacs's JS2-mode, thanks to its AST, it is possible to augment the library so that it does understand require.js -- and the author does so without resorting to piles-upon-piles of regexp hacks.
meepmorp 13y ago
Let's see if this triggers the flame war filter.
pulmo 13y ago
Serious question: Did anyone ever chose an editor because of some "Why X is better than Y" article?
- skylan_q 13y ago
  "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. :)
- justinhj 13y ago
  I think the more important question is how many otherwise interesting articles get buried because they don't have a title like "Why X is better than Y"?
- Derbasti 13y ago
  No, but one could imagine choosing an editor because of some "look what cool thing I can do in X" article.
- groups 13y ago
  >Did anyone... Over months I read many articles describing cool things you can do with emacs you can't do with vim, and eventually I switched. So: one article, no. Many, yes.
deleted 13y ago
[deleted]
bjourne 13y ago
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 13y ago
  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 13y ago
    >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 13y ago
      I'll have to polish off some of the code I wrote ages ago and share it on my blog (see my profile.)
      - S4M 13y ago
        OK, I'm subscribing to your blog. Thanks for sharing.
Prefinem 13y ago
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.
pjmlp 13y ago
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
- gcr 13y ago
  This is a great question and I don't really know the answer. Emacs has swank-js for interacting with a browser engine, but it doesn't appear to capture the functionality of Netbeans' chrome extension.
- Expez 13y ago
  https://github.com/skeeto/skewer-mode https://github.com/skeeto/skewer-mode
  - pjmlp 13y ago
    That is just a subset of what Netbeans offers.
mickeyp 13y ago
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 13y ago
  > 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.
  - 13y ago
watson 13y ago
I wonder why he obfuscated the "validOptusUsername" key in the screenshots
platz 13y ago
Fwiw, visual studio evaluates your JavaScript similar to this providing you pretty good js intellisense/autocomplete
podperson 13y ago
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.
csmuk 13y ago
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 13y ago
  Where is vi? I only see two shell sessions and top.
  - theOnliest 13y ago
    It's in the history printouts.
  - pyre 13y ago
    Look at the output of the history command, though it's not his command history, as he's logging in as someone else. (Looks like he's logging in as 'root' or 'backdoor', but I'm also not sure what the `-n` flag on `login` is; I don't see it in the manpages for `login` on OSX or Ubuntu)
  - blueblob 13y ago
    You won't see it in top, it doesn't use enough resources. :p
    - csmuk 13y ago
      Well played :)
deleted 13y ago
[deleted]
johncoltrane 13y ago
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
- imissmyjuno 13y ago
  Which Vim plugin uses `Btag` ?
  - johncoltrane 13y ago
    None that I know of, it's a quick and dirty custom command/function: https://github.com/romainl/dotvim/blob/master/vimrc#L302 https://github.com/romainl/dotvim/blob/master/vimrc#L302 https://github.com/romainl/dotvim/blob/master/autoload/functions.vim#L118-L154 https://github.com/romainl/dotvim/blob/master/autoload/funct...
- klibertp 13y ago
  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 13y ago
    >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?
    - wodenokoto 13y ago
      Yes, but yours had a shitty point.
    - DrJokepu 13y ago
      Have you ever worked with legacy code?
spullara 13y ago
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.
deleted 13y ago
[deleted]
marijn 13y ago
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.)
- javajosh 13y ago
  Hi Marijn! Love your work, especially Eloquent JavaScript[1] which is my goto link for when people ask me "where should i start if I want to learn how to code". And CodeMirror is really an amazing piece of kit, of course. So out of curiosity, how far away do you think CodeMirror is from being usable as a real local editor - and by that I mean how far away would you be from using it instead of Emacs? It seems like it would be straightforward to embed in something like node-webkit[2]. What else then remains? [1] http://eloquentjavascript.net/ http://eloquentjavascript.net/ [2] https://github.com/rogerwang/node-webkit https://github.com/rogerwang/node-webkit
  - marijn 13y ago
    There a whole bunch of stuff that needs to be wrapped around the editor UI component to make it a useful desktop editor. I started working on something like that at some point, but just didn't have the time to get anywhere. You might want to look at node-mirror [1] . I'm not following it very closely, but it did look promising the last time I installed it. [1]: https://github.com/soliton4/nodeMirror https://github.com/soliton4/nodeMirror
- freyrs3 13y ago
  Elisp is bad, but not nearly as bad as vimscript.
deleted 13y ago
[deleted]
SimHacker 13y ago
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.

139 points by lelf 13y ago

algorix 13y ago

and... here... we... go.

vezzy-fnord 13y ago

tl;dr Emacs is extensible.

nichochar 13y ago

vim.

Symmetry 13y ago
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?
- Sanddancer 13y ago
  http://www.vim.org/scripts/script.php?script_id=2375 http://www.vim.org/scripts/script.php?script_id=2375 this seems to get a good chunk of the way there. Yes, vimscript absolutely sucks, but vim makes up for it by allowing one to write hooks to pull in pretty much any shared library you can think of. One can also embed python, perl, ruby, etc into vim pretty easily to have it available as well.
- snogglethorpe 13y ago
  Note that for those that prefer vi-style modal editing, emacs has some very good vi/vim-emulation modes.... ^^;
- platz 13y ago
  Don't feed the trolls

h1fra 13y ago

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 13y ago
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 13y ago
  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)
- coldtea 13y ago
  >AFAIK, ST2 doesn't have a plugin for a Javascript interpreter Yes, but the important thing is that it CAN have one, same as Emacs could. For example, it has a Go plugin which uses the Go AST.
mickeyp 13y ago
I think you're misunderstanding it. JS2-mode is a few years old and a generic javascript mode with a built-in AST and all the goodness that comes from that. It does not inherently understand require.js. Nor does ST. With Emacs's JS2-mode, thanks to its AST, it is possible to augment the library so that it does understand require.js -- and the author does so without resorting to piles-upon-piles of regexp hacks.

meepmorp 13y ago

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

pulmo 13y ago

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

skylan_q 13y ago
"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. :)
justinhj 13y ago
I think the more important question is how many otherwise interesting articles get buried because they don't have a title like "Why X is better than Y"?
Derbasti 13y ago
No, but one could imagine choosing an editor because of some "look what cool thing I can do in X" article.
groups 13y ago
>Did anyone... Over months I read many articles describing cool things you can do with emacs you can't do with vim, and eventually I switched. So: one article, no. Many, yes.

deleted 13y ago

[deleted]

bjourne 13y ago

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 13y ago
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 13y ago
  >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 13y ago
    I'll have to polish off some of the code I wrote ages ago and share it on my blog (see my profile.)
    - S4M 13y ago
      OK, I'm subscribing to your blog. Thanks for sharing.

Prefinem 13y ago

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.

pjmlp 13y ago

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

gcr 13y ago
This is a great question and I don't really know the answer. Emacs has swank-js for interacting with a browser engine, but it doesn't appear to capture the functionality of Netbeans' chrome extension.
Expez 13y ago
https://github.com/skeeto/skewer-mode https://github.com/skeeto/skewer-mode
- pjmlp 13y ago
  That is just a subset of what Netbeans offers.

mickeyp 13y ago

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 13y ago
> 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.
- 13y ago

watson 13y ago

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

platz 13y ago

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

podperson 13y ago

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.

csmuk 13y ago

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 13y ago
Where is vi? I only see two shell sessions and top.
- theOnliest 13y ago
  It's in the history printouts.
- pyre 13y ago
  Look at the output of the history command, though it's not his command history, as he's logging in as someone else. (Looks like he's logging in as 'root' or 'backdoor', but I'm also not sure what the `-n` flag on `login` is; I don't see it in the manpages for `login` on OSX or Ubuntu)
- blueblob 13y ago
  You won't see it in top, it doesn't use enough resources. :p
  - csmuk 13y ago
    Well played :)

deleted 13y ago

[deleted]

johncoltrane 13y ago

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

imissmyjuno 13y ago
Which Vim plugin uses `Btag` ?
- johncoltrane 13y ago
  None that I know of, it's a quick and dirty custom command/function: https://github.com/romainl/dotvim/blob/master/vimrc#L302 https://github.com/romainl/dotvim/blob/master/vimrc#L302 https://github.com/romainl/dotvim/blob/master/autoload/functions.vim#L118-L154 https://github.com/romainl/dotvim/blob/master/autoload/funct...
klibertp 13y ago
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 13y ago
  >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?
  - wodenokoto 13y ago
    Yes, but yours had a shitty point.
  - DrJokepu 13y ago
    Have you ever worked with legacy code?

spullara 13y ago

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.

deleted 13y ago

[deleted]

marijn 13y ago

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.)

javajosh 13y ago
Hi Marijn! Love your work, especially Eloquent JavaScript[1] which is my goto link for when people ask me "where should i start if I want to learn how to code". And CodeMirror is really an amazing piece of kit, of course. So out of curiosity, how far away do you think CodeMirror is from being usable as a real local editor - and by that I mean how far away would you be from using it instead of Emacs? It seems like it would be straightforward to embed in something like node-webkit[2]. What else then remains? [1] http://eloquentjavascript.net/ http://eloquentjavascript.net/ [2] https://github.com/rogerwang/node-webkit https://github.com/rogerwang/node-webkit
- marijn 13y ago
  There a whole bunch of stuff that needs to be wrapped around the editor UI component to make it a useful desktop editor. I started working on something like that at some point, but just didn't have the time to get anywhere. You might want to look at node-mirror [1] . I'm not following it very closely, but it did look promising the last time I installed it. [1]: https://github.com/soliton4/nodeMirror https://github.com/soliton4/nodeMirror
freyrs3 13y ago
Elisp is bad, but not nearly as bad as vimscript.

deleted 13y ago

[deleted]

SimHacker 13y ago

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.