Why Emacs is a better editor – case study for JavaScript developer(blog.binchen.org)
blog.binchen.org
Why Emacs is a better editor – case study for JavaScript developer
http://blog.binchen.org/?p=901
109 comments
> 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.
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.
>When I last checked, the activity on a CEDET and Semantic mailgroup was almost non-existent.
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.
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.
Is the difficulty in accessing AST's in EMACS a valid criticism of EMACS when so few programming language specifications specify such access and few of the communities around languages that don't build such tools into open source implementations? It took Steve Yegge to do it for the ubiquitous JavaScript.
What Yegge's project shows is: that EMACS does not lack the facility to do what is needed [LISP is it's command language after all], and that implementing the task is non-trivial even for skilled programmers.
What Yegge's project shows is: that EMACS does not lack the facility to do what is needed [LISP is it's command language after all], and that implementing the task is non-trivial even for skilled programmers.
It's not that it's non-trivial (though for some languages it may be, due to the nature of the language) or that Emacs lacks the facilities; if anything, LISP is the perfect language for representing, storing and working on ASTs.
It's just that historically it just wasn't done. The rise of IDEs tied closely to the compiler/environment changed that equation and now it's Emacs that's behind the curve.
It's just that historically it just wasn't done. The rise of IDEs tied closely to the compiler/environment changed that equation and now it's Emacs that's behind the curve.
Historically Emacs used to disable even its dumb regex-based syntax highlighting out of the box for performance reasons. The slice of time since a parser-based approach has become feasible is a tiny fraction of the time Emacs has been around.
"Syntax" highlighting is normally done with lexical analysis, not with a parser, and is far, far faster than regex-based syntax highlighting, because it can use a simple tuned state machine, and it only needs to redraw text attributes until it gets to text in the same state (from the state machine) it's trying to repaint. Turbo Pascal was doing syntax highlighting in DOS 20 years ago.
Parsers have been used to do semantic highlighting of symbols, e.g. paint identifiers in different colors depending on whether they're interfaces or classes, etc. But the big win for parsing isn't highlighting, it's completion. You can't do super useful completion without a fairly rich parse tree, and not just for the current file, but also for all the libraries.
Parsers have been used to do semantic highlighting of symbols, e.g. paint identifiers in different colors depending on whether they're interfaces or classes, etc. But the big win for parsing isn't highlighting, it's completion. You can't do super useful completion without a fairly rich parse tree, and not just for the current file, but also for all the libraries.
Well, true, but in fairness, go far enough back and people used Line editors - so yeah, it's certainly rooted in performance issues, but also the independent rise of IDEs and a strong desire by the writers of the IDEs -- who typically wrote the supporting compilers and environments -- to create a greater cohesive environment.
To clarify, I am using dealing with AST's in Lisp as the metric for triviality.
And while it may be trivial against some other metric to deal with AST's in another language, the solution tends to be a one-off, that is dealing with the AST of C++ doesn't offer an advanced starting position for dealing with the AST of JavaScript - most of the work is in the details of a particular language not at the higher level abstractions of languages in general.
And while it may be trivial against some other metric to deal with AST's in another language, the solution tends to be a one-off, that is dealing with the AST of C++ doesn't offer an advanced starting position for dealing with the AST of JavaScript - most of the work is in the details of a particular language not at the higher level abstractions of languages in general.
Have you seen MuMaMo? It does a pretty good job handling mixed language files.
I'd also point to Ensime as an example of a language plugin that uses an external parser to check code.
I'd also point to Ensime as an example of a language plugin that uses an external parser to check code.
I tried using MuMaMo for a while, but found it quirky.
I much prefer the actively maintained web-mode
http://web-mode.org/
http://web-mode.org/
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 , does a lot of things right on the editor API level that popular editors get tragically wrong.)
(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 , does a lot of things right on the editor API level that popular editors get tragically wrong.)
Fellow emacs user/addict. Emacs is, to steal a phrase from the politics, the "least bad form of editor" IMO. Your criticism of elisp, dynamic scoping, and mutable-state everywhere is spot-on. To use emacs is to constantly put up with things in a state of "almost works, kind of broken". Partly the language and design, and partly just the culture of the editor, I think.
(For me personally being able to run in a terminal is a huge feature, which means I'll probably be stuck w/ emacs forever -- no one making new editors seems to care about terminal support.)
(For me personally being able to run in a terminal is a huge feature, which means I'll probably be stuck w/ emacs forever -- no one making new editors seems to care about terminal support.)
Elisp isn't really horrible. It sits on top of a local maximum in the fitness landscape. So often, little tweaks are needed, and dynamic scope lets you tweak more than a more engineering-oriented language would. It gets adapted to the task at hand in a worse-is-better, almost Darwinian way. The ability to redefine and tweak functions called by other functions, eval'd live in a buffer, is key. Without that, it would be a tenth the editor it is.
JS would not be a better language. Guile could be.
I used to think a more semantically aware setup would be better. But the costs of semantic awareness are enormous, because a single mismatch between what your editor understands, and what the underlying language can represent, breaks everything. This makes things fragile; parser error recovery is not an easy thing to get right. Some artfully written regexes can go further, in a practical sense.
JS would not be a better language. Guile could be.
I used to think a more semantically aware setup would be better. But the costs of semantic awareness are enormous, because a single mismatch between what your editor understands, and what the underlying language can represent, breaks everything. This makes things fragile; parser error recovery is not an easy thing to get right. Some artfully written regexes can go further, in a practical sense.
It's stuck in the past because of its architecture and no doubt a lack of people to actually carry out large, wholesale changes.
Part of what Emacs a great editor and Elisp a great tool for mutating -- if one can call it that -- is exactly the same things that make it "bad." Yes, it has dynamic scoping, and yes you can change variables outside your scope -- which is exactly the level of granularity your average Emacs hacker wants. He's not looking to write rock-solid code for the mars rover; he's trying to make M-x compile a bit less crap or a bit more specific to what he's doing.
Say what you want about side effects and advising and all the other "terrible" practices that, in any sane software project, would never pass peer review -- in Emacs it enables you to hot plug, duct tape and jury rig Emacs to get it to do what you want.
The last 2-3 years has seen a massive resurgence in Emacs packages and there's a lot of buzz in the community, I feel, in trying to push things in the right direction. But it takes time. And people. And we need both.
Part of what Emacs a great editor and Elisp a great tool for mutating -- if one can call it that -- is exactly the same things that make it "bad." Yes, it has dynamic scoping, and yes you can change variables outside your scope -- which is exactly the level of granularity your average Emacs hacker wants. He's not looking to write rock-solid code for the mars rover; he's trying to make M-x compile a bit less crap or a bit more specific to what he's doing.
Say what you want about side effects and advising and all the other "terrible" practices that, in any sane software project, would never pass peer review -- in Emacs it enables you to hot plug, duct tape and jury rig Emacs to get it to do what you want.
The last 2-3 years has seen a massive resurgence in Emacs packages and there's a lot of buzz in the community, I feel, in trying to push things in the right direction. But it takes time. And people. And we need both.
I do not believe a tool can only be useful for either getting things done quickly or solid engineering. Even a monster like JavaScript manages to support both modes quite well.
Very true, but I don't think that's the conclusion I was reaching. The very things that make some things easy, like dynamic scoping; advising things left and right; wholesale overriding functions in your init file; aliasing or fsetting things. Each one of these things adds technical debt, but in this case, the technical debt has no real cost as it's not often a shared project and is mostly limited to snippets and bits of code that gets stuck in a file and rarely touched again.
When someone says elisp is a mess, they are holding a high bar. It's not a mess like BASIC. JavaScript is not an improvement.
Writing editor extensions is a totally different set of programming compared to writing applications that will run unattended across terabytes of data for years. A programmer is always sitting in front of a programming environment while your code runs. Therefore, it makes sense to allow things like deep access to the internals (dynamic scope, etc.), because if something goes wrong, it's only because the person currently in front of the computer told it to go wrong. And she's a programmer, so she can fix it.
I guarantee you that if Emacs used a "real" extension language, with lots of OO and state hiding, you'd be yelling obscenities into the computer the first time you wanted to tweak some extension you had. Have you ever seen an Eclipse user tweak one of his extensions? Didn't think so.
I guarantee you that if Emacs used a "real" extension language, with lots of OO and state hiding, you'd be yelling obscenities into the computer the first time you wanted to tweak some extension you had. Have you ever seen an Eclipse user tweak one of his extensions? Didn't think so.
I don't know...I feel like a lot of the emacs stuff is half-broken in weird ways (e.g., iedit mode doesn't work when editing grep results with grep-ed; hl-line-mode doesn't work if you're on the last line of a shell buffer, etc.). If I, as a programmer, tried to fix every broken elisp/emacs edge case I came across, I'd never get anything else done...and still not have a bug-free emacs, ya know? :)
Agreed the ease of modification of emacs is unparalleled (and tricks like dynamic scoping can be handy at times), but I'm not convinced that it wouldn't be possible to get something aprox. as flexible and easy to modify with a more robust culture and langauge. (But not a classic "real OO" language, which I agree would be very annoying -- I'm thinking something with a strong functional flavor and static structural typing...)
Whether this is really possible or not is an open question, though.
Agreed the ease of modification of emacs is unparalleled (and tricks like dynamic scoping can be handy at times), but I'm not convinced that it wouldn't be possible to get something aprox. as flexible and easy to modify with a more robust culture and langauge. (But not a classic "real OO" language, which I agree would be very annoying -- I'm thinking something with a strong functional flavor and static structural typing...)
Whether this is really possible or not is an open question, though.
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/ [2] https://github.com/rogerwang/node-webkit
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/ [2] https://github.com/rogerwang/node-webkit
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
[1]: https://github.com/soliton4/nodeMirror
While I would not say that Elisp is the greatest programming language every created, I would hardly call it horrible, nor would I call it entrenched in the past. The Emacs designers seem to put real effort into improving the language over time, even to the degree of breaking backwards compatibility. That's pretty hard to for an editor that greatly depends on the functionality of user-written extensions. Also, consider the recent addition of lexical scoping. That's a brobdingnagian change to a programming language, editing language or not.
- There are still no structs/objects/whatever, so you're stuck using lists for everything. Real lisps grew out of that long ago.
- The compiler really isn't very effective, so doing expensive things is often tricky and takes a lot of fiddly optimizing to get halfway acceptable performance (this should get better when/if guile becomes the Emacs compiler).
- But the killer is the APIs and conventions that exists around the language. It's neat with how little code you can do some things using direct actions on buffers, and the various hooks make a lot of things sort of possible, but I've found again and again that things just don't compose, scripts trample on each other's toes, and trying to deal with dynamic scope (even with lexical scoping, lots of interfaces depend on dynamically scoped variables and concepts, such as the current buffer) when you're doing something asynchronous is a total nightmare.
- The compiler really isn't very effective, so doing expensive things is often tricky and takes a lot of fiddly optimizing to get halfway acceptable performance (this should get better when/if guile becomes the Emacs compiler).
- But the killer is the APIs and conventions that exists around the language. It's neat with how little code you can do some things using direct actions on buffers, and the various hooks make a lot of things sort of possible, but I've found again and again that things just don't compose, scripts trample on each other's toes, and trying to deal with dynamic scope (even with lexical scoping, lots of interfaces depend on dynamically scoped variables and concepts, such as the current buffer) when you're doing something asynchronous is a total nightmare.
> There are still no structs/objects/whatever, so you're stuck using lists for everything. Real lisps grew out of that long ago.
http://www.gnu.org/software/emacs/manual/html_node/cl/Struct...
http://www.gnu.org/software/emacs/manual/html_mono/eieio.htm...
http://www.gnu.org/software/emacs/manual/html_node/cl/Struct...
http://www.gnu.org/software/emacs/manual/html_mono/eieio.htm...
These are macros on top of vectors, aren't they?
Yup. Not good enough?
My experience is that vector-based structs don't perform as well as 'real' structs do (the compiler isn't able to infer their type or the type of their content, has to do bounds checking for every access, etc), and occasionally make debugging painful, but yes, they are actually a lot better than just using lists throughout.
[deleted]
So is it correct to say that elisp isn't bad (since it has lexical scope now), but the text/gui api that are too imperative in nature ?
I remember nicferrier and others discussing how to write lazy streams for elisp in order to have a more functional text processing ~std lib.
All in all I agree with you that the extensions are weirdly integrated and fragile, maybe it's time to build a side-project emacs with better abstraction layers.
ps: What's make me so sad it that elisp editing api is really not lispy in nature. Language doesn't dictate good design...
I remember nicferrier and others discussing how to write lazy streams for elisp in order to have a more functional text processing ~std lib.
All in all I agree with you that the extensions are weirdly integrated and fragile, maybe it's time to build a side-project emacs with better abstraction layers.
ps: What's make me so sad it that elisp editing api is really not lispy in nature. Language doesn't dictate good design...
If you think elisp is bad, you never tried Mocklisp in Gosling/UniPress emacs.
I disagree. I've written code to modify how emacs runs for me. I've never customised any other editor or IDE with the same ease of emacs - and I say this as an IDE slut - I'll use everything and anything.
That said, an emacs rewrite in Clojure is a wet-dream of mine (emacs like goodness with the ability to use modern GUI libraries, ANTLR parsers etc... and speed!)
That said, an emacs rewrite in Clojure is a wet-dream of mine (emacs like goodness with the ability to use modern GUI libraries, ANTLR parsers etc... and speed!)
Oh man, mine too. Although part of me thinks this is like saying, "you know, Everest would be way better if moved twenty feet west."
There is this project: https://github.com/hraberg/deuce
Although it seems to be stalled. Part of me wonders/hopes LightTable will get to the point that it is a viable replacement for emacs.
Although it seems to be stalled. Part of me wonders/hopes LightTable will get to the point that it is a viable replacement for emacs.
I'm a bit late to the party, but https://github.com/hraberg/deuce
Elisp is bad, but not nearly as bad as vimscript.
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.
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.
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.
For that matter, you can write emacs extensions in python, using Pymacs; given that it's marshalling objects to and from a subprocess over a pipe, it breaks when anything gets asynchronous, but lately when I've gone beyond "customization" to "actual code", pymacs has made it so much easier that after a few decades with emacs, I really want an open source editor with emacs' richness (and bindings) and python as a first-class extension language.
Elisp isn't the problem. It's a fine language.
Edit: it's obviously far from perfect, but it has stood the test of time and it lets you get things done. It's no Scheme or CL, but for what people use it for it's fine.
Edit: it's obviously far from perfect, but it has stood the test of time and it lets you get things done. It's no Scheme or CL, but for what people use it for it's fine.
Vim is just an editor, though. Not an IDE, Javascript interpreter, operating system, and coffee maker.
That is because vimscript is such an awful language. People have written amazing plugins for hooking into compilers and what not, but only a few people on Earth are capable of taming vimscript.
Yes, no contest there.
I'm seeing in-editor browsers more and more lately. I'm not sure why. Given the difficulties with arbitrary key binding, and with filesystem access -- both sine qua non of a programmer's editor -- it seems like any such tool starts out half-broken by design. Don't get me wrong; yours is quite nice, as far as they go. I just don't see how they go far enough to have been getting the consideration they have
lately.
When you host a solid project like CodeMirror on a local Node.js instance, which fortunately has a heavy focus on I/O, you start to get those capabilities back. See something like Lighttable, which is essentially ClojureScript on top of Node.js, but sadly isn't open source (yet?) I think we're still a far cry from it, but maybe that'll be the future of Unix-based text editors, maybe that's what will eventually supersede Emacs (I say that as an avid user.)
That said, I wish I could pin some of my hopes to the upcoming Guilemacs.
That said, I wish I could pin some of my hopes to the upcoming Guilemacs.
As soon as it launches, Light Table will be open source.
"Will it be open source?
I'm a firm believer in open source software and open source technologies. I can guarantee you that Light Table will be built on top of the technologies that are freely available to us today. As such, I believe it only fair that the core of Light Table be open sourced once it is launched. At some level, this is an experiment in how open source and business can mix - it will be educational for us all." - http://www.kickstarter.com/projects/ibdknox/light-table
"Will it be open source?
I'm a firm believer in open source software and open source technologies. I can guarantee you that Light Table will be built on top of the technologies that are freely available to us today. As such, I believe it only fair that the core of Light Table be open sourced once it is launched. At some level, this is an experiment in how open source and business can mix - it will be educational for us all." - http://www.kickstarter.com/projects/ibdknox/light-table
LT is one of the biggest stringalongs in recent memory. It is all about whipping up community goodwill in hopes of flipping a buck one day.
In the meantime, humble projects are progressing along without all the young people JS-dev hype.... CodeMirror, emacs/vim editor plugins, etc
In the meantime, humble projects are progressing along without all the young people JS-dev hype.... CodeMirror, emacs/vim editor plugins, etc
Speaking of Light Table, did you know LT actually uses CodeMirror under the hood?
I won't get into the emacs debate since I am not sure I even know what it is about. But I think browser editors are the wave of the future, for the same reasons web software has been widely successful despite all shortcomings.
I am the founder of a browser based IDE software company, our product uses Codemirror exclusively and extensively..check my profile for the link if you want to check it out.
I am the founder of a browser based IDE software company, our product uses Codemirror exclusively and extensively..check my profile for the link if you want to check it out.
Emacs isn't good enough and there really aren't any radical improvements happening. The problem is the alternatives aren't better.
To put it another way, "Correlation between certain tools and smart people does not imply causality." Or exclusivity, for that matter.
Elisp has its wart, but... all told, for something created in the 1980ies, it's not that bad.
Yeah, but here we are 30 years later and we don't have something better! (And emacs, for all its faults, is still being actively developed and improved. But still...it's easy to imagine something much better. Harder to implement it, tho ;)
A lot of the value in Emacs these days is probably in the positive network externalities. Pick up pretty much any language or markup or whatever, and there will likely be a decent emacs mode.
>Emacs Lisp is such a horrible language
Beats the hell out of javascript.
Beats the hell out of javascript.
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.
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.
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.
>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?
How do you do that?
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
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.
Emacs has swank-js for interacting with a browser engine, but it doesn't appear to capture the functionality of Netbeans' chrome extension.
I kind of feel the hacker spirit in what you did but… what about fixing your JavaScript instead?
Sublime Text: http://imgur.com/p27i5L7
Vim: http://imgur.com/OlVbSdO
Sublime Text: http://imgur.com/p27i5L7
Vim: http://imgur.com/OlVbSdO
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".
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".
>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?
Nope, the tool should choke on hideous constructs, and make you write them properly.
See how I provided just as many arguments as you?
If every tool supports a different subset of the language, all of them become less usable. An editor that can refactor bad code is more useful than one that only works on code you write from scratch within it. This is part of why a good IDE is so hard; it has to cope with the code temporarily being in an invalid state because how else can you finish it?
Have you ever worked with legacy code?
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.
Plenty of times. That's why I wouldn't want an editor to enable programmers to write shitty code.
If that's a huge problem to you, use said editor only for greenfield projects...
If that's a huge problem to you, use said editor only for greenfield projects...
Regex-based or no, most Emacs major modes I've used actually will do this, more or less; if, having configured the mode's indentation and highlighting behavior to your taste, you find that one or the other stops working properly, it is invariably because you just wrote something that'll
choke the language parser. It won't stop you writing lousy code, but it'll stop you writing broken code, which is in itself a great time saver.
The only reliable exceptions I've found are Perl, which is unsurprising if you know anything about how that language parses, and the PHP modes, all of which bear stigmata of having been written by PHP developers, and each of which is broken in its own special way. Yegge's js2-mode is a notable exception of the opposite, and highly laudable, sort; when you screw something up using that mode, it knows what you did wrong, and uses the echo area to tell you about it.
The only reliable exceptions I've found are Perl, which is unsurprising if you know anything about how that language parses, and the PHP modes, all of which bear stigmata of having been written by PHP developers, and each of which is broken in its own special way. Yegge's js2-mode is a notable exception of the opposite, and highly laudable, sort; when you screw something up using that mode, it knows what you did wrong, and uses the echo area to tell you about it.
Yes, but yours had a shitty point.
Which Vim plugin uses `Btag` ?
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/autoload/funct...
https://github.com/romainl/dotvim/blob/master/vimrc#L302
https://github.com/romainl/dotvim/blob/master/autoload/funct...
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.
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.
Because anything you put time into to makes it automatically better for your use case is actually better.
This is quite stupid.
Saying emacs is better but showing that emacs do actually the same sublime text mistake....
Emacs is extensible; ST too.
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.
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.
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.
Your main point stands though: all major editors have the ability to add plugins to achieve this same functionality.
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:
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
*Emacs
*Vim
*Sublime Text
*Brackets (built in to the base editor)>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.
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.
Fwiw, visual studio evaluates your JavaScript similar to this providing you pretty good js intellisense/autocomplete
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.
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.
I wonder why he obfuscated the "validOptusUsername" key in the screenshots
Serious question: Did anyone ever chose an editor because of some "Why X is better than Y" article?
"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. :)
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. :)
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"?
>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.
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.
No, but one could imagine choosing an editor because of some "look what cool thing I can do in X" article.
tl;dr Emacs is extensible.
Kevin Flynn uses vi - 'nuff said:
http://i.imgur.com/rMdKYde.jpg
(this is in jest but no doubt I'll be downvoted...)
http://i.imgur.com/rMdKYde.jpg
(this is in jest but no doubt I'll be downvoted...)
Where is vi? I only see two shell sessions and top.
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)
It's in the history printouts.
[deleted]
[deleted]
[deleted]
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
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.
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
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.
[deleted]
vim.
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?
Don't feed the trolls
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.
Note that for those that prefer vi-style modal editing, emacs has some very good vi/vim-emulation modes.... ^^;
Let's see if this triggers the flame war filter.
and... here... we... go.
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.