3 ms·

His approach to implementing this feature would have been “if code completion needs data X from the code, we provide an API for that”, and repeat this for all o

His approach to implementing this feature would have been “if code completion needs data X from the code, we provide an API for that”, and repeat this for all other possible use cases. This, to protect the AST. This is of course technically feasible, but a huge amount of effort, and will constantly have to be updated / changed. When people are effectively arguing “it’s a much more forward-compatible and scalable approach to let tools use the AST directly”, he rejects that as changing the discussion, not a concrete example, and/or pressuring. This is super ironic coming from someone who made an editor entirely based on LISP, which is successful precisely because it is completely transparent and anything can be changed / inspected / done. Given the success of LSP in the recent years, it’s super evident that RMS was wrong on this matter. It has created an ecosystem for LSP around clang, and the integration with emacs is great.

varajelle 4y ago
> Given the success of LSP in the recent years, it’s super evident that RMS was wrong on this matter. But the LSP doesn't expose the AST. It just expose what the editor needs. That looks like the kind of interface RMS was asking for.
- mgraczyk 4y ago
  Sometimes the editor needs the AST, and LSP is general enough that language implementations can expose it. For example https://clangd.llvm.org/extensions#ast https://clangd.llvm.org/extensions#ast
  - varajelle 4y ago
    Sure, but the "success of LSP in the recent years" was not because of that extension.
leni536 4y ago
Ironically that's what modern LSPs are, aren't they? An API on the handful of use cases an IDE might want to care about.
- stingraycharles 4y ago
  Yes but I don’t think that could have happened if they were not decoupled from the compiler. But yes it’s a good point that LSPs are actually an API for editors instead of exposing the AST to the editors directly, but from the discussion I’m fairly convinced that RMS lacked the imagination of all the possibilities LSPs could create. And it’s also quite ironic that he resisted opening up the compiler to support these kind of tools, and it ended up being a for-profit corporation that spearheaded this whole open standard / ecosystem of LSPs.
discardable_dan 4y ago
To be more accurate, this to protect an AST parsed into source code that is _readily available_ for anyone who wants it, because... it's open source. Anyone with knowledge of GCC could write a patch in a week or so to dump the AST into JSON and publish it as a patch. You're right, too, though: this exact argument is part of why LSP and clang won. When people showed up (in _2015_!) to try to start on support for this sort of thing in emacs and gcc, the dictator at the top could not be convinced this was worthwhile. And now the world uses Clang and LSP and the GNU counterparts get dustier and dustier.

varajelle 4y ago

> Given the success of LSP in the recent years, it’s super evident that RMS was wrong on this matter. But the LSP doesn't expose the AST. It just expose what the editor needs. That looks like the kind of interface RMS was asking for.

mgraczyk 4y ago
Sometimes the editor needs the AST, and LSP is general enough that language implementations can expose it. For example https://clangd.llvm.org/extensions#ast https://clangd.llvm.org/extensions#ast
- varajelle 4y ago
  Sure, but the "success of LSP in the recent years" was not because of that extension.

leni536 4y ago

Ironically that's what modern LSPs are, aren't they? An API on the handful of use cases an IDE might want to care about.

stingraycharles 4y ago
Yes but I don’t think that could have happened if they were not decoupled from the compiler. But yes it’s a good point that LSPs are actually an API for editors instead of exposing the AST to the editors directly, but from the discussion I’m fairly convinced that RMS lacked the imagination of all the possibilities LSPs could create. And it’s also quite ironic that he resisted opening up the compiler to support these kind of tools, and it ended up being a for-profit corporation that spearheaded this whole open standard / ecosystem of LSPs.

discardable_dan 4y ago

To be more accurate, this to protect an AST parsed into source code that is _readily available_ for anyone who wants it, because... it's open source. Anyone with knowledge of GCC could write a patch in a week or so to dump the AST into JSON and publish it as a patch. You're right, too, though: this exact argument is part of why LSP and clang won. When people showed up (in _2015_!) to try to start on support for this sort of thing in emacs and gcc, the dictator at the top could not be convinced this was worthwhile. And now the world uses Clang and LSP and the GNU counterparts get dustier and dustier.