>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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Love attention to details like these