EmacsConf 2022

2019, just in time not to be a covid adaptation.

Idk. I started using Emacs at my second internship as a software developer, thanks to the current generation of fancy, IDE-like starter kits (Spacemacs in particular). I was in my 20s, and it was less than a decade ago.

I experienced Emacs in that first encounter as hip and exciting! Setup was extremely easy, and the workflow was such a joy and such a shock that it changed what I want out of computer interfaces forever. The discoverability and in-band documentation blew my mind, and made the incredibly complex bundle of functionality and keybindings in front of me feel shockingly approachable and learnable. The Vim emulation was so good that Emacs is where I learned Vim, and even as a relatively unsophisticated Vimmer, few Vim emulation plugins have ever lived up to what I experienced with Evil.

I don't think Emacs is about to take over the world, but it seems to be doing quite well. It seems a clear and ongoing source of inspiration for the trendiest applications that people use to edit code today, like VSCode. Important Emacs plugins like Magit have inspired the creation of some really nice TUI applications like lazygit and lazydocker, etc., and continue to be excellent.

It may not be for everyone, but Emacs still still has a lot to offer. For a significant minority of developers in current and future generations, I think it will continue to 'click'. For developers of other software development tools, it will continue to be a source of friendly competition and inspiration, and in that way it will continue to anchor and influence the landscape.

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.

RPL is like LISP in that it's all about quoting. ' and eval are primary (unshifted) keys on these calculators.

There was a LISP based pocket computer: the Casio AI-1000:

https://www.youtube.com/watch?v=H-yuZ2pejGU

> 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.

(1) https://github.com/Wilfred/tree-sitter-elisp/blob/main/gramm... — of course, the example being ELISP makes it look easier than said, if you compare it with the grammar of Perl5 that’s not yet finished unsurprisingly.