Hacker News new | past | comments | ask | show | jobs | submit login
EmacsConf 2022 (emacsconf.org)
178 points by hprotagonist on Dec 3, 2022 | hide | past | favorite | 42 comments



>You can view streams using the watch pages or in a streaming web player such as MPV. If you need to reverse the video for easier viewing (ex: turning dark mode into light mode), try a command like mpv --vf=negate URL.

Love attention to details like these


The videos are pre-recorded, but after the video there is a live Q&A section. Come and join the IRC channel. It's a lot of fun.


Was this an exceptional measure or a planned new kind of organization ? It's interesting.


Fosdem has been doing prerecorded talks ever since the “covid” edition.


This format started in 2018 or 2019, I can’t recall which.


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


Good to know! For as much as I use Emacs I don’t really follow the Emacs community / ecosystem.

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 :)


https://blog.phundrak.com/emacs-29-what-can-we-expect/ has some highlights.

eglot, tree-sitter are both very nice.

the sqlite integration is currently what i'd describe as "cute", but maybe not the most featureful.


I'm shocked that ast based edition is back. Many people were against this, lots of grammar based tools sadly failed (for better or worse reasons). In a way it seems that the mainstream rose above regex level tree manipulation, and that even html/css made people start to think in subtrees rather than linear data. This might reduce efforts a lot, whether it is for edition or analysis.

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.


tangentially related, https://hazel.org/


Thanks a lot :)


yup, here is the previous discussion: https://news.ycombinator.com/item?id=33788208


The best way to set keybindings has been changed, from define-key and global-set-key to keymap-set and keymap-global-set.

Some examples:

  (keymap-global-set "<remap> <upcase-word>" #'upcase-dwim)
  (keymap-set icomplete-minibuffer-map "TAB" #'icomplete-force-complete)
You can also use package.el to install packages from version control now, check the package-vc-selected-packages variable.


Heloo may name thz shunqor


Not to spamming, but https://emacs.zeef.com was a valuable resource for me to find many Emacs packages and communities to my liking.


Right before NeovimConf: https://www.neovimconf.live/


Can you watch it purely in Emacs?


Depends on your definition of "purely". I will watch using an mpv managed by EXWM so it will be showing up as an Emacs buffer. Or you could use the embedded video player in EAF.


Please post a link for setting this up. Thanks.

EDIT: found https://wiki.archlinux.org/title/EXWM I would like to try that on an old Linux laptop


Oh no, I missed half of it already when reading this.

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.


And EdConf tomorrow! Conference season is among us.

exit

quit

bye

/q ...


I heard VimConf was above standard.

ducks


Seriously, this was meant to be a joke / pun, since ed (and not vi) is the standard editor.


Check out HHC, the HP Handheld Conference. It's just like EmacsConf, but the people are older :-)

https://hhuc.us/

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)


Cool, but completely off-topic.


Only partly so, I'm stretching it a bit but HP Calc's RPN is inspired by lisp, and emacs calc is in turn stack based, just like RPN :) It's a big cross pollinization fest.


It's use of RPN wasn't, but RPL was with one meaning for it being "Reverse Polish Lisp".

https://en.wikipedia.org/wiki/RPL_(programming_language)


RPN is forth not lisp, and I seriously doubt HP got their idea from emacs. I think HP's RPN precedes the first release of emacs anyway. Edit: 1st release of emacs was 1976 so I take that last bit back.


Sorry, I mistyped. I was thinking about HP42 and above RPL not the basic RPN. RPL is a blend of lisp idiom on top of good old stack based RPN (list, map, numerical tower). It goes so far that they even added quoted lambda expressions. You could push << a -> + a a >> on your stack.


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


As with the high vote totals for Firefox-related links, the presence of a link on an ancient* text editor at #1 on HN (as I write) reveals that HN voters are a bit ... old school. These tools' relative importance has declined over the last 15 years.

* (I am a graybeard who used Emacs daily for a long time)


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

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


What do you use now and how is it better than Emacs?

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.


you say old school, i say “prefers battle-hardened tools”

it is kind of amusing to use an editor every day that is significantly older than me, i have to admit.


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.


The very fact that Emacs is so ancient makes me feel comfortable investing in it. If I extend and reconfigure it heavily, my setup will probably be usable for the rest of my life. Emacs will always be around.

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.


Emacs might be old school, but it will be still around when the current crop of editors of choice will have been forgotten.


Editor wars are right up there with tabs vs spaces, right? I too was an Emacs devotee once upon a time. On of the CS professors at our school in the late 90's was even more so, known for doing all his work from inside of Emacs. But these days VS Code is really making life easy. It's impressively feature-rich with a minimum of futzing.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: