The future of Emacs, Guile, and Emacs Lisp

Posted Oct 14, 2014 2:05 UTC (Tue) by lsl (subscriber, #86508)
In reply to: The future of Emacs, Guile, and Emacs Lisp by mtk
Parent article: The future of Emacs, Guile, and Emacs Lisp

> it seems like the more fundamental question about the future of emacs isn't the choice of implementation/extension languages but instead whether or not emacs will ever parse/analyze source code like eclipse/intellij/visual studio.

Plugins for Emacs or Vim doing exactly that are no longer a question for the future. They exist for several years now, using e.g. libclang for C/C++/ObjC or the mentioned gocode for the Go language. There's no reason all this code needs to be part of the text editor.

Those editor plugins mostly tend to work by either being glue around some library, by querying some code oracle server over some IPC mechanism or by just shelling out to some external program. The latter is more than adequate for a big number of cases (e.g. code reformatting) and has the advantage of being nice, simple and general.

Using frontends of actual production compilers also avoids the issue of your IDE disagreeing with the compiler, which seems to be a common problem among IDE users. I think QtCreator is moving in the same direction for exactly this reason.

Useful tools for working with code don't need to be part of an editor or IDE and IMHO they shouldn't be. Build them so they're useful on their own. Those who want to interact with them through their favorite text editor can write the necessary integration code.

The future of Emacs, Guile, and Emacs Lisp

Posted Oct 14, 2014 2:16 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

Well, try something like InteliJ IDEA (or its derivatives like PyCharm). It's a completely different experience when you work with an editor that actually understands the semantics of the text you're editing.

The future of Emacs, Guile, and Emacs Lisp

Posted Oct 15, 2014 16:58 UTC (Wed) by nix (subscriber, #2304) [Link] (5 responses)

Yeah. Emacs has supported this for *years* via CEDET and the semantic bovinator. It's still slow, but for C, C++, and Lisp it is perfectly usable (other languages suffer from a lack of grammars).

The future of Emacs, Guile, and Emacs Lisp

Posted Oct 15, 2014 18:04 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

CEDET is nice, but it fails to deliver.

It's mostly used for simple completions and nothing else. IntelliJ products can use their semantic model for smart code refactoring and inspection.

Oh, and CEDET's parser is pitifully inadequate even for plain C, it has no hope of ever understanding C++ completely.

The future of Emacs, Guile, and Emacs Lisp

Posted Oct 21, 2014 16:30 UTC (Tue) by nix (subscriber, #2304) [Link] (3 responses)

It's sufficient for what I want to do with it for C.

Obviously getting it right for C++ is impossible -- but you need a C++ compiler to understand C++ properly. Actually you need something *better*, because you want to be able to parse incomplete, partially written, and syntactically invalid code as much as possible. That sort of error recovery is *hard*.

The future of Emacs, Guile, and Emacs Lisp

Posted Oct 21, 2014 16:36 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Clang mostly gets error recovery right. Aside from them, people at IntelliJ are working on Nitra ( https://github.com/JetBrains/Nitra ) are trying to make it easier for complicated languages and they are tackling C++ now.

Pure C is also not that easy, because lots of C++'s syntactic ambiguity actually comes from C.

The future of Emacs, Guile, and Emacs Lisp

Posted Oct 23, 2014 1:34 UTC (Thu) by cmccabe (guest, #60281) [Link] (1 responses)

C is "very close to having a context-free grammar."
Details here: http://eli.thegreenplace.net/2007/11/24/the-context-sensi...

C++ has an undecidable grammar.

I can parse C with yacc. I could never hope to parse C++ with anything but a hand-written parser.

The future of Emacs, Guile, and Emacs Lisp

Posted Oct 23, 2014 11:41 UTC (Thu) by jwakely (subscriber, #60262) [Link]

Yeah, C doesn't have to parse anything remotely like:

int Foo (int i = T<1, int>::i);

(See http://open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#325 for other examples like that)