5 ms·

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

by 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.
- deng 13y ago
  >When I last checked, the activity on a CEDET and Semantic mailgroup was almost non-existent. http://news.gmane.org/gmane.emacs.cedet http://news.gmane.org/gmane.emacs.cedet Sure, it's not LKML, but still, questions usually get answered. > Now I'm fighting with CoffeeScript/LiveScript support. They both expose their parsers - I can get their AST with one line of code. After another week I still don't have working Semantic plugin for them. I'm afraid an AST is just the beginning for properly supporting a language. If you need help, don't hesitate to ask on the mailing list. > The home page for CEDET looks like it comes from last century and even info pages are not a big help. Yes, unfortunately.
brudgers 13y ago
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.
- mickeyp 13y ago
  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.
  - brudgers 13y ago
    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.
  - technomancy 13y ago
    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.
    - mickeyp 13y ago
      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.
rjsen 13y ago
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.
- icedata 13y ago
  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/

by mickeyp 13y ago

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.

deng 13y ago
>When I last checked, the activity on a CEDET and Semantic mailgroup was almost non-existent. http://news.gmane.org/gmane.emacs.cedet http://news.gmane.org/gmane.emacs.cedet Sure, it's not LKML, but still, questions usually get answered. > Now I'm fighting with CoffeeScript/LiveScript support. They both expose their parsers - I can get their AST with one line of code. After another week I still don't have working Semantic plugin for them. I'm afraid an AST is just the beginning for properly supporting a language. If you need help, don't hesitate to ask on the mailing list. > The home page for CEDET looks like it comes from last century and even info pages are not a big help. Yes, unfortunately.

brudgers 13y ago

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.

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

rjsen 13y ago

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.

icedata 13y ago
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/