Live data from Hacker News

Emacs 29 is nigh

blog.phundrak.com

121–130 of 267 posts

Re: Emacs 29 is nigh

#121

Earlier quoted context omitted.

> I really don't get how watching a PM-type struggle with emacs for two hours at a spell is compelling or instructive. I can struggle with emacs all by myself. Because it's a lot scarier to struggle alone. Plus as his videos progress and his knowledge progresses he frequently teaches you things that come up and practice a lot as a matter of course. It's kind of like when you start programming you have to build up you…

you convince yourself it won't be like this one day In case you're considering a career in software, no, the feeling of groping around in the dark never disappears.

But it's a feature, not a bug :) and occasionally one gets to imagine multi-dimensional diamonds and then build them.

Re: Emacs 29 is nigh

#122
post #71

Earlier quoted context omitted.

I do think that keyboard optimized workflows are not for everyone; you should use what works best for you! However, Emacs distributions like Doom Emacs or Spacemacs are definitely more approachable and featured OOTB than vanilla Emacs. For me, the benefit of Emacs is that it's a single environment I can do everything in. I also am the type to enjoy messing with my workflow. IMO most of that can be replicated with VS…

> VS Code remote editing blows TRAMP out of the water One place emacs has a huge advantage is it doesn't use hardly any resources in the docker container. The vscode remote server instance uses a constant 15%-30% however. In real world terms this means a compile that takes 1 minute for me takes 2 minutes for my coworkers that use vs code. There are many potential confounding factors that could affect the performance…

This is true; not having that remote server has its pros and cons. VS Code is also just in general slower than Emacs haha.

I'm surprised the difference is that much though!

Re: Emacs 29 is nigh

#123

Earlier quoted context omitted.

Emacs was a great editor just like Nirvana was a great band. It’s influenced every other editor after it. People are always going to love it. But I think all the best ideas from that era have been taken. I like Vim but EMacs won the editor wars

> Emacs was a great editor just like Nirvana was a great band. It’s influenced every other editor after it. Eh.. Which every other editor would that be? There is a mode [0] you can enable just because of how different it is to every other popular editor ever. Still. 0: https://www.emacswiki.org/emacs/CuaMode

Ooo we could go on forever. Let’s start with VS Code.

What we want to do is list features. For example, people prefer the GUI and the mouse, non-modal, batteries included.

It’s not a bad thing. It’s just been a while. Those editors were written for a time that don’t exist anymore.

Re: Emacs 29 is nigh

#124
post #103
post #98

Earlier quoted context omitted.

You can use Emacs for things other than programming :-) Although I mostly use Emacs for my Python work, I still would use other IDEs for C++ work.

Emacs can and should be a good choice for programming though!

Emacs should be a good choice for everything, which is my point :-)

Just because you can't easily get it to be great at one thing (lsp) doesn't mean it needs to be abandoned for everything else.

Re: Emacs 29 is nigh

#125
post #63

I really want to use Emacs but I can't get Company + any LSP to come close to vs code or coc.nvim. When I configure company to trigger instantly on a single keystroke, Emacs completely locks up pretty much every time I hit a key.

> When I configure company to trigger instantly on a single keystroke, Emacs completely locks up pretty much every time I hit a key. Emacs using an elisp JSON parser is about 15x slower (!) than using a native JSON parsing lib. It's borderline criminal (just kidding): I think LSP should simply test if native JSON parsing is avail and refuse to run if it isn't. I'm using LSP-mode and it flies (AMD 3700X / 32 GB of RAM…

I'm also on an AMD 3700X, 32G of RAM, with Emacs native compilation branch. I'm totally unaware of elisp vs native JSON parsing though, I was just using stock Eglot that came bundled with Emacs.

Re: Emacs 29 is nigh

#126
post #103

Earlier quoted context omitted.

Emacs can and should be a good choice for programming though!

Emacs should be a good choice for everything, which is my point :-) Just because you can't easily get it to be great at one thing (lsp) doesn't mean it needs to be abandoned for everything else.

LSP is so much better than alternatives to work with that I feel compelled to make it work and work well. Even for python, running pyright pays dividends for me. But luckily lsp-bridge looks promising so I don't feel like I need to jump ship for VS code quite yet.

Re: Emacs 29 is nigh

#127
Currently on Emacs 28, on my personal machines. I see that there is a Emacs 29 pretest version available, for Windows. Are all Linux users building Emacs 29 from source?

Re: Emacs 29 is nigh

#128
post #126

Earlier quoted context omitted.

Emacs should be a good choice for everything, which is my point :-) Just because you can't easily get it to be great at one thing (lsp) doesn't mean it needs to be abandoned for everything else.

LSP is so much better than alternatives to work with that I feel compelled to make it work and work well. Even for python, running pyright pays dividends for me. But luckily lsp-bridge looks promising so I don't feel like I need to jump ship for VS code quite yet.

To be frank, for Python I still use just elpy - it's good enough. The biggest headache I've had on Emacs with Python is dealing with virtualenvs.

Re: Emacs 29 is nigh

#129
post #71

Earlier quoted context omitted.

I do think that keyboard optimized workflows are not for everyone; you should use what works best for you! However, Emacs distributions like Doom Emacs or Spacemacs are definitely more approachable and featured OOTB than vanilla Emacs. For me, the benefit of Emacs is that it's a single environment I can do everything in. I also am the type to enjoy messing with my workflow. IMO most of that can be replicated with VS…

> VS Code remote editing blows TRAMP out of the water I think it is not that black & white. Recently I've used tramp to dial into a server via SSH and there into a docker container and directly edit files inside. I don't think VSCode can do the same inside a shell it starts. Sure it may be able to open an SSH shell and then from there you might be able to type in some docker exec command. But that is not the same as…

> Want to open files? OK here are your files from your own machine. It does not understand, that it should use the generic action of showing available files in the context of the opened SSH session.

Are you sure? If I launch a remote session window and click open file/folder, it's on the remote (either SSH or docker for my workflows).

VS Code runs a server on the remote with any plugins (including LSP servers) installed with it. This is as opposed to Emacs, which AFAIK does not have a server on the remote and instead interacts with the remote directly using SSH (or `docker exec`, etc). Note, you still need to have any LSP servers installed on the remote if you want that capability.

I would argue that VS Code's remote editing experience feels more integrated than Emacs with TRAMP; I've had issues before where something is more difficult to do over TRAMP than locally, but I've never had that with VS Code.

You're right though, "blows out of the water" is a stretch, I just have fights with TRAMP fresh in my head haha

In terms of making editing on a remote seem just like editing locally, both VS Code and TRAMP are capable, I just find VS Code remote editing to be much more user friendly. It just works with little to no configuration.

Re: Emacs 29 is nigh

#130

I am loving all this emacs love lately (I am an emacsophile), but I do find all this attention it is getting suddenly a bit surprising. Is it just that "long lines, LSP, fast syntax hightlighting" is making new people interested, or is it just us neckbeards coming out of the woods? I mean, many of these things are just a package-install away right now. I seldom see vim put in the same lime-light, for instance. Or may…

vim's stewardship is a lot more conservative but neovim has gotten a fair amount of press with recent releases
Post reply on HN