EmacsConf 2022
emacsconf.org
emacsconf.org
Love attention to details like these
I saw version 29 was recently cut- is there anywhere I can get a good overview of “best practices in 2022”?
I wouldn’t mind dusting off my init.el and updating it. I haven’t had a good yak shave in five years or so :)
eglot, tree-sitter are both very nice.
the sqlite integration is currently what i'd describe as "cute", but maybe not the most featureful.
And this fine grained source interaction was why I was so enamoured with emacs in the first place. It was such a deep feeling of control compared to anything I tried in the late 90s.
Some examples:
(keymap-global-set "<remap> <upcase-word>" #'upcase-dwim)
(keymap-set icomplete-minibuffer-map "TAB" #'icomplete-force-complete)
EDIT: found https://wiki.archlinux.org/title/EXWM I would like to try that on an old Linux laptop
Well, in theory I could watch a lot of recordings any time later. But in practice I hardly ever do. If I decide to attend a conference, I spend the day there, even if it's at my desk. (Or the night, hello Linuxcon Australia). If I don't register and attend real-time I will never find the time to watch most of it.
exit
quit
bye
/q ...
ducks
The presentations are on YouTube, some I like:
"Don't make me wait" https://www.youtube.com/watch?v=PPJdAvQpsGc
"Book binding 2.0" https://www.youtube.com/watch?v=SAnkiaefcB8
"Know thine enemy (TI)" https://www.youtube.com/watch?v=WIN2y-SnA6c (TI fast mode)
There was a LISP based pocket computer: the Casio AI-1000:
* (I am a graybeard who used Emacs daily for a long time)
it is kind of amusing to use an editor every day that is significantly older than me, i have to admit.
I thought I was behind the times and learned VSCode but I've been underwhelmed so far. You still need to choose, install and configure extensions but these extensions are not of the same quality as Emacs extensions. For example, the Git extensions of VSCode fail as soon as something a bit unexpected happens. With no Magit around, you end up using Git command line which is not known for great ergonomics.
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?
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.
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 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.
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.
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.
Meanwhile, VSCode will be replaced by some new hotness in a few years, and anyone who invests heavily in the perfect VSCode setup will lose all their work.