> These tools' relative importance has declined over the last 15 years.
I would say to the contrary. There has been a flurry of new development on Emacs in the recent years initiated by a new generation of developers. New (and simpler) search and autocompletion frameworks (Ivy, vertico), native compilation of Elisp, the rise of Org and the advent of LSP clients (thx VScode). In the coming years Treesitter might render LSP obsolete some day. Exciting times ahead.
And what does it mean to be an old piece of software anyway?
Software may age but compared to hardware it has the advantage of being able to evolve. I hate it to break to you: Windows and Linux kernels are over 30 years old written in a language that was invented 50 years ago. The whole design principle of state of the art operating systems was invented in the 1970s. MS Office kernels are probably older than 30 years and the leading X86 platform looks back on an over 40 year old history. The first Python version was released back in 1991, that’s 30 years. JS almost has 27 years (1995 afir). Chrome BTW was released back in 2008, that’s already been 14 years. Safari‘s engine comes closer to 20 years.
Does it even make any sense to compare Emacs 29 with versions from the 80s?
> In the coming years Treesitter might render LSP obsolete some day.
While LSP can support semantic highlighting, it's often used for navigation, ala goto-definition. I think there is little overlap between Tree-sitter and LSP.
> It’s often used for navigation, ala goto-definition
Yes, that’s LSP‘s primary use case, either to jump to a definition or show inline documentation from around the definition as well as for autocompletion based on symbols in the execution environment accessible to a static analyser at least. I think that could all be done by a tree-sitter based parser, too, no need for a separate language server process. The LSP server can’t do much beyond static analysis anyway. That’s what makes me think it could be well replaced by a more sophisticated language mode. Check out the tree sitter talk, he demonstrates how easy TS makes querying the source code (using the tree sitter query builder) — similarly how you query the DOM using a selector engine.
There's an Emacs mode for Scala development inspired by SLIME called ENSIME, which antedates the LSP servers for Scala.
There are things ENSIME could do that back when I did Scala development were not supportable via the LSP protocol because it didn't have rich enough metadata to encode certain kinds of contextual information. The contemporary ENSIME maintainer, who was burning out on the project at the time, wrote about this and the growing but, in his view, native excitement around LSP efforts with a lot of frustration. In a few blog posts or tweets he pointed out specific issues the developers of one language server were running into which he'd anticipated and pointed out, to no avail.
I like the multiprocess approach with standard protocols, despite its complexities, because it lets different editors share smarts. It's good when Vim users and Emacs users can participate in development with huge numbers of users of whatever is the trendy editor of the day, and share code in the form of LSP servers to benefit from IDE-like features. But I think it's likely we'll see an evolution beyond what LSP is capable of, and maybe standardization for some languages will be around something other than LSP.
> I like the multiprocess approach with standard protocols, despite its complexities, because it lets different editors share smarts.
Yes, the benefit LSP brings is putting editors/IDEs on equal footing with respect to a specific language. Also the multiplicative effect when the author of a new language provides a language server so nobody needs to switch their IDEs to try it out.
However, seeing how „straight forward“ a tree-sitter specific language grammar looks in practice (1) makes we wonder if by providing a TS grammar for a language would realize (almost) the same benefit. Based on such a grammar and TS’ selector engine figuring out a syntax highlighting scheme, code folder, a docstring or symbol scanner might not be such a huge endeavor any more as you described for ENSIME.
So, yeah, in the end LSP might be dead end at some point, especially because TS promises to be very fast and avoids any IPC. Performance seems to be the biggest problem of LSP clients in Emacs and probably other editors as well.
I would say to the contrary. There has been a flurry of new development on Emacs in the recent years initiated by a new generation of developers. New (and simpler) search and autocompletion frameworks (Ivy, vertico), native compilation of Elisp, the rise of Org and the advent of LSP clients (thx VScode). In the coming years Treesitter might render LSP obsolete some day. Exciting times ahead.
And what does it mean to be an old piece of software anyway?
Software may age but compared to hardware it has the advantage of being able to evolve. I hate it to break to you: Windows and Linux kernels are over 30 years old written in a language that was invented 50 years ago. The whole design principle of state of the art operating systems was invented in the 1970s. MS Office kernels are probably older than 30 years and the leading X86 platform looks back on an over 40 year old history. The first Python version was released back in 1991, that’s 30 years. JS almost has 27 years (1995 afir). Chrome BTW was released back in 2008, that’s already been 14 years. Safari‘s engine comes closer to 20 years.
Does it even make any sense to compare Emacs 29 with versions from the 80s?