Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs 29 is nigh

blog.phundrak.com

Post reply on HN
Print view View original

201–210 of 267 posts

Re: Emacs 29 is nigh

#201

Post by torben-friis »

treeblah wrote: post #46
bergheim wrote: post #43

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…

For me its been the questionable stewardship of vscode ( https://github.com/omnisharp/omnisharp-vscode/issues/5276 ) driving me away from vscode and the Emacs from Scratch videos from the System Crafters youtube channel driving me towards Emacs. When I was looking for alternatives I stumbled on those videos and they blew me away. Also Emacs 28/29 has been way more welcoming and easy to get started with than when I fi…

As a vscode user considering the move, how difficult would it be to get to the point of making emacs a daily driver?

Can it be a pick it up as you go thing? Or would I have to spend a few evenings figuring out the basics and configuration? Is lisp knowledge required?

Re: Emacs 29 is nigh

#202

Post by patrick451 »

cmrdporcupine wrote: post #145
bergheim wrote: post #43

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…

Casual emacs user since 1991, and from my POV ... it seems like maybe a confluence of things (lsp, treesitter, etc.) is bringing some people back into the Emacs folds. For years emacs is what I used for C/C++ coding. Then CLion came on the scene, and it would be very hard for me to walk away that from and train my fingers back to meta super land. But it does seem like Emacs is getting competitive as an alternative to…

Yes, I really think LSP has been a game changer. I started using emacs in undergrad and later gradschool mostly for the Latex support. Combined with helm-bibtex it's a killer feature set. I worked mostly with matlab in gradschool and mostly used the matlab editor.

But when I needed python or c I used emacs, though it was always a slog to get to get IDE-like features working. LSP was really a game changer that let me get rid of CDET and ctags and elpy, and has let me continue using emacs now at work. If not for LSP, I almost certainly would be using clion or VScode.

I will say though, the one place emacs doesn't cut it is for jupyter notebooks. VScode really is pretty killer there.

Re: Emacs 29 is nigh

#203

Post by srcreigh »

I’m excited for the possibility of including use-package in emacs 30.

My init.el always fails first time on a new machine due to not having use-package. Can’t install use-package via use-package. so I have to manually install it.

Yeah, there’s probably a way to automate that, but for new people it will always be a weird. I’d love to tell new people “Throw (use-package selectrum :ensure t) select it and M-x eval-region!” Without, yeah, the 4 lines of weird package init elisp.

Re: Emacs 29 is nigh

#204

Post by srcreigh »

modernerd wrote: post #8

Wow, Eglot/Treesitter/better package support in 29 make me want to try Emacs again. > Install packages from source with package.el Emacs users updating to 29: do you plan to use this instead of Straight now? If not, can you help me to understand what more Straight provides? Emacs on macOS users: do you generally compile new versions of Emacs from source, or wait for ports like Mitsuharu Yamamoto's one[1] to update? […

Probably not re packaging. I like use-package and they’re talking about including use-package with emacs 30.

Re: Emacs 29 is nigh

#205

Post by deagle50 »

jpe90 wrote: post #191
hvis wrote: post #179

Earlier quoted context omitted.

Check that you have `libjansson-dev` installed, or whatever is the equivalent on your system.

Looks like I’ve got that on my machine, and I built Emacs —with-json this time. Performance is still better but it’s still stuttery. I guess it’s related to either the json parsing happening on the main thread and/or the LSP servers using company-capf which I think is a synchronous backend? It seems like coc.nvim, lsp bridge, kak-lsp, and other editor solution’s i’ve come across all opt to use sidecar processes that…

This can be spun off into another thread. I haven't tried it yet but the feedback has been excellent.

https://reddit.com/r/emacs/comments/ymrkyn/async_nonblocking...

Re: Emacs 29 is nigh

#206

Post by srcreigh »

truncate wrote: post #131
yewenjie wrote: post #12

Its great to see both eglot and tree-sitter being merged. However, I am unhappy about the state of 'emacs configurations/distributions' right now. I have been using Doom Emacs, but the development is pretty much stalled there [0], and I don't think there is any distribution that is keeping up with these cutting-edge features (compared to the NeoVim ecosystem, let's say). Somehow it feels like I was seeing a lot more…

As a lsp-mode users, why switch to eglot?

Never used LSP. Imo eglot is a test for your knowledge of other good packages. It won’t work nicely without turning on company-mode, flycheck-project-buffer (spelling?) etc. But it’s good to know about those anyway.

LSP to me always seemed like a all-in-one don’t have to think of know what’s going on type of package. Depends what you want.

I’ve found eglot to be hackable too. I had ugly Horizontal Rule in eldoc for rust code due to tamsyn font. Well eglot->eldoc-> some builtin markdown package -> finally discovered a config option for the character used to draw hr’s.

On one hand it’s annoying to go 3 dependencies deep to configure eglot behaviour. But emacs makes that kinda thing accessible (if not easy) and I learned something.

Re: Emacs 29 is nigh

#207

Post by zelphirkalt »

kfajdsl wrote: post #129
zelphirkalt wrote: post #118

Earlier quoted context omitted.

> 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) instal…

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

I am not sure about dedicated extra windows. I've not seen it being done in an ad-hoc started shell, inside a normal VSCode editor instance, at least. If it is a new windows (new process) it is not really the same, as the new instance is then dedicated to being a remote session one. With Emacs one does not have to start multiple instances to get things done, but does everything out of the same instance.

Whenever I see people closing and opening VSCode instances, I feel like: "Why did you close that?! Can't you just do things in your editor without frequently closing and opening it again?" It feels like an inefficient process. "I can't do it in this instance, I need to close it and open a new one from another working directory.". I can only speak from what I have observed people doing when screensharing. Maybe other people do it differently or more efficiently.

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

Emacs has had a server program since ages. You can run Emacs as a server, for example on a remote host, or on your local machine and when you start a GUI or non-GUI Emacs, start in client mode, to connect to the Emacs server. Your Emacs client will benefit from whatever you have set up the Emacs server to do. If your Emacs server has LSP stuff set up, you will be able to use it in your Emacs client.

For merely accessing a remote via SSH and accessing files in it, editing them and saving them, Emacs truly does not need any server. It channels anything one does through the SSH connection and "commits" to the remote's filesystem.

I agree though, sometimes tramp can be a hassle. It could be better and better documented as well.

Re: Emacs 29 is nigh

#209

Post by smsx »

yewenjie wrote: post #26
YetAnotherNick wrote: post #17

Earlier quoted context omitted.

It's definitely not stalled by any metric: https://github.com/doomemacs/doomemacs/commits/master

I would argue very few of those commits are feature commits of late. Once again, I am deeply thankful to Doom Emacs, and in no way 'demanding' anything from the project.

Actually, in the last few months there has been an absolute ton of feature work. A very sophisticated generational profile system was introduced, and the entire framework is being split into separate packages to enable more stable versioning. This is all with the goal of reducing the bus-factor from being just Henrik.

Re: Emacs 29 is nigh

#210

Post by bobbyrullo »

jmmv wrote: post #10
ilovecaching wrote: post #7

I highly recommend modern Emacs over VSCode. If you don't want to tinker, Emacs has multiple levels of preconfigured distributions like Prelude, Nano, and Doom Emacs that give the same out of the box working experience. Modern Emacs includes all of the great features of VSCode, plus much more. You get things like: - LSP support for completion, refactoring, listing. - Tree sitter support for super fast highlighting. -…

Yes, but what about remote support? That’s the single most thing I miss from VSCode. I want to run my editor on the local machine so that it can benefit from graphics support and integrate properly with the local windowing system, but I want all heavy lifting (LSP and the like) done on a remote machine. Yes, I can use Emacs over SSH (which I do now), but it has limitations. Yes, I could forward X11, but it’s pretty t…

I'm at an organization where our dev machines are in the cloud. Most folks are indeed using VSCode remotely, but I'm happy with emacs.

The combo that works for me (on MacOs locally) is daemon mode and X11 forwarding...but using x2Go instead of vanilla "ssh -X". I end up with XQuartz windows that behave (mostly*) like other MacOS windows and pretty good performance.

If I'm at cafe or somewhere with spotty internet, I'll forgo the X stuff and just use mosh and text only emacs, but I pretty much never do that anymore.

(* mostly, meaning that for some reason tools like divvy and other things that manipulate/resize windows just don't work with X Quartz windows)

Post reply on HN