Get the top HN stories in your inbox every day.
ilovecaching
CJefferson
I'm happy people love Emacs, but it's not remotely close to the same "out of the box experience", and I think it will put people off to claim it does.
I few months ago I spent a week using Doom Emacs (based on a friend's recommendation). It took days to get used to basic functionality (cut/copy/paste/save/etc), and after a week I still couldn't get error highlighting and running tests to work in Rust.
With VSCode, I opened a Rust project and a box popped up saying "hey, want to install the rust plugin", I said yes, it installed (including installing the approriate version of rust-analyzer), and everything worked.
kneebonian
Switched to Doom Emacs about a year or two ago it has been the biggest improvement in my tools as a developer since becoming proficient with the CLI.
That being said there is a bit of a learning curve.
luxcem
The learning curve can be steep especially if you are used to other keybindings. For vim users, I heard only good things about evil-mode (and it's the default in doom). I personally use default emacs bindings (with a switch between Meta and Ctrl as the Ctrl key is usually poorly located on keyboards).
wicked
If you don't use the caps lock, you can easily change it to be another Ctrl key. It's perfectly positioned for regular use, and how often do you really use the caps lock key?
It's great for any application where you use keyboard shortcuts.
undefined
modernerd
This is compelling! But I ended up abandoning Emacs in previous attempts to switch to it. In case anyone can help solve the pain points I remember:
1. Which project management tools do you recommend? (I think I was using Projectile in the past, but from what I recall it left buffers from previous projects open when switching to other projects, which ended up being kind of annoying.)
2. Any advice about automatic whitespace/indentation handling with Emacs?
Ideally I want to have Emacs automatically:
- Use a prettier config if present.
- Fall back to editorconfig if present.
- Infer whitespace from the file if no formatting configs are found.
- Match and auto-format indentation when pasting text.
That's pretty much how it works with VS Code. I really struggled to recreate this in Emacs the last time I tried, and as silly as it sounds it ultimately put me off using Emacs. (I work across a lot of repos with different languages and conventions; with Emacs I had to double-check every commit for whitespace issues, but with VS Code I rarely think about it.)
3. How do you handle long-running processes in Emacs? I struggled to find a way to run multiple build processes in the background and quickly switch between/kill/read output/restart them. (Is M-x compile the right approach, or is there something else?)
4. Is libvterm still the best terminal emulator for Emacs? From VS Code/tmux I'm used to being able to summon multiple terminal instances with different tabs/ splits, and the experience in Emacs felt less good last time I tried to recreate this.
ParetoOptimal
1. project.el and tabspaces
2. I think you'll want to write some elisp for this. I use apheleia though, maybe it does this?
3. async-shell-command or... hmm... there is a emacs binding to a go library for managing async processes I can't recall the name of.
4. vterm is best in the sense of most support for ncurses things. I personally try to use eshell for everything. As far as different tabs/splits emacs should be able to do that. Can you give a specific example of something you had trouble with?
modernerd
Thanks for these tips! I'll explore tabspaces, apheleia, async-shell-command (and the Go lib) — all of those are new to me.
> Can you give a specific example of something you had trouble with?
I hoped to recreate multiple long-running terminal sessions in splits and tabs, similar to functionality I now use from:
Neovim (plugin): https://github.com/akinsho/toggleterm.nvim
VS Code (built-in): https://code.visualstudio.com/docs/terminal/basics#_managing...
I just found “popper”, which didn't exist the last time I looked. It seems like a pretty close substitute:
ziotom78
Thanks for suggesting "vterm", I wasn't aware of its existence. I just installed it, it seems to work perfectly!
NateEag
For #2, I've been pretty happy with dtrt-indent (https://github.com/jscheid/dtrt-indent) for DWIM indentation bouncing between projects.
I have yet to try apheleia, but I wouldn't be surprised if just enabling apheleia, dtrt-indent, electric-indent-mode (a built-in I don't use, but which may cover your indent-on-paste desire), and editorconfig-mode (https://github.com/editorconfig/editorconfig-emacs) in prog-mode-hook just did what you wanted.
Apollo00
>Is libvterm still the best terminal emulator for Emacs? From VS Code/tmux I'm used to being able to summon multiple terminal instances with different tabs/ splits, and the experience in Emacs felt less good last time I tried to recreate this.
vterm is awesome, I recommend using multi-vterm if you want more than one
Kalq
1.projectile-kill-buffers or the built-in project-kill-buffers will do that for the current project. You could run that before switching projects.
2. https://github.com/radian-software/apheleia
3. There might be a way to do this but I'm not sure. Emacs being inherently single threaded probably makes this difficult. But yes, I use M-x (re)compile.
4. libvterm is the best still imo. You can definitely do multiple instances and there's even different tab modes in Emacs now.
sping
> 3. There might be a way to do this but I'm not sure. Emacs being inherently single threaded probably makes this difficult. But yes, I use M-x (re)compile.
Emacs has zero issue with multiple compilations - they're handled asynchronously. If threading was an issue it would kill Emacs with just one active compilation let alone many. The lack of threading in Emacs is a significant issue, but simultaneously nowhere near as restrictive and troublesome as many people seem to believe.
It's irritating that Emacs inhibits simultaneous compilations by default, but that's literally simply down to buffer naming. Emacs uncompromisingly uses a buffer called "*compilation*" for compiliation and will only run one at a time in a buffer.
There are simple hacks floating around to have compilation create a unique buffer name, then it happily runs as many as you like. Also, `projectile` has the setting `projectile-per-project-compilation-buffer` which enables this by putting the project name in the compilation buffer name.
I do echo the sentiment that it is not an easy out-of-the-box experience, and the learning curve is steep, though this is the sort of configuration that I assume the likes of doom set up by default. But even then, starting with doom is a much more significant endeavor than starting with VS Code.
But once you learn and develop your Emacs set up it becomes a delightful, malleable, and extremely powerful environment that's comfortable like an old leather chair, and where it isn't, you make it just how you want it. Some of us were lucky enough to accumulate proficiency over years and decades starting in a time when there weren't easier options with comparable power.
I love to have people join us and appreciate it, but it's not an easy process to get to the payoff.
modernerd
Thank you for the kind reply and pointers!
Apheleia in particular was new to me — I don't think it even existed last time I looked. So good to see the Emacs community continuing to thrive and invent.
Syntonicles
I use projectile and perspective. Everything is integrated into my Ivy/Counsel and I have simple self documenting shortcuts for everything using General keybindings.
Until I set this up correctly the leftover buffers bothered me. Now it's part of my workflow.
I often have code from two projects side-by-side in split windows. Projectile restricts all of my actions to the appropriate project Autocomplete, code navigation, file search, fuzzy greps, everything uses the buffer's project as context.
With just two key presses I can close all buffers for any open project.
MiyamotoAkira
For number 1 I use perspective with projectile.
arc-in-space
projectile does have a command to kill all buffers from the current project that I regularly use fwiw
blep_
For 1, also remember that you can just run multiple copies of emacs for different projects. Nobody says you have to use all the packages that ostensibly solve some problem you have.
jmmv
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 terrible to do so from Windows or macOS.
I tried TRAMP in the past, but it didn’t seem to match VSCode’s power at all in this area. Maybe I configured it wrong though, or maybe it has improved. Any thoughts?
Volundr
> I tried TRAMP in the past, but it didn’t seem to match VSCode’s power at all in this area.
What was missing. I used TRAMP for years and aside from opening the initial file, it was identical to working locally for me. That said I haven't needed to use it in years, and haven't used the remote support in VSCode.
jmmv
I remember running into a lot of trouble trying to get the thing to just work. There were some issues in trying to use Windows as the client and some stuff in my zshrc also got in the way. I think I was able to me it run more or less, but I gave up at the time.
I’ve recently been getting into Emacs again and have a pretty good setup already, so I’ll have to try TRAMP again.
ilovecaching
You can try using emacsserver remotely. I would recommend using SSH proxying instead of messing with emacs over tcp.
Personally I use emacs on a large dev machine running in a container in a terminal emulator. I can work from my iPad Pro, iPhone, MacBook Pro, Windows Desktop, Linux Desktop, or any guest machine by just adding one public key. Terminal Emulators are still just GUI apps and fit into the GUI ecosystem. Modern emulators also have true color support, GPU based rendering, full unicode support, support for custom fonts that add additional graphics, etc. You can make a terminal editor look like something incredibly modern if you want to. I personally don't find any value in that, for me the basic appearance of a terminal editor is less distracting.
hollerith
The only time I've seen anyone use "emacs server" or "emacsserver" is to refer to the Emacs Lisp needed to make the command emacsclient (the analog to VS Code's "code" command or TextMate's "mate" command) work.
Correct me if I am wrong, but I believe you are using it to refer to running Emacs remotely without a GUI (i.e., with only a terminal emulator as the UI) even though the person you are replying to specifically stated, "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."
I am writing this to prevent readers of your comment from ending up more confused than they were before they started reading this thread.
wara23arish
do you any tips on how to set this up? or maybe point me in the right direction?
ananthakumaran
I tried to use tramp based setup, but ran into many edge cases. Even popular libraries like flycheck doesn't support tramp very well. Eventually I found mosh and that settled the problem. Mosh + iterm2 + terminal emacs[1] combination works very well. Except a few missing features (fringe, variable font size/multiple fonts), nearly everything else works well.
ParetoOptimal
> I tried to use tramp based setup, but ran into many edge cases. Even popular libraries like flycheck doesn't support tramp very well.
Try using more "core" libraries like flymake that accounted for (or seem to) tramp from the start.
gpderetta
X forwarding is always an option.
bobbyrullo
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)
bergheim
> Yes, I can use Emacs over SSH (which I do now), but it has limitations. Yes, I could forward X11, but it’s pretty terrible to do so from Windows or macOS.
Which limitations (that matter)? Maybe I was just too used to vim - everybody is saying use the graphical edition of emacs, but I don't really care. mosh + emacs works great for me.
One thing that helped a lot is making the tmux clipboard transfer to your local computer.
ParetoOptimal
I use tramp on a devcontainer daily FWIW.
scruple
What languages? I've struggled to get it working with Ruby (specifically with robe) and it's the one thing that keeps me in VSCode for work.
Blackthorn
I've been using emacs for many years but honestly I can't recommend it for new users.
Ignore all the features and look at the speed. It's slow, especially when using all those nice features. Big buffers are laggy. LSP in particular is slow.
Honestly it's bad enough that I think I'm gonna start looking into neovim. I'll miss the macro support but it's getting harder and harder to excuse the overall slowness.
bergheim
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 maybe I am just more attentive to the coverage now?
avar
This is probably borderline flamebait, but my impression as an outsider looking in is that Richard Stallman not being as involved as he once was in setting policy for FSF projects held it back quite a bit.
Most notably, he had a long-time prohibition of any sort of FFI for both GCC and Emacs.
Yes, the reversal of that policy was more than 12 years ago at this point[1], but note how the first Emacs release with an FFI came out in late 2016[2]. Arguably it's only in the last couple of years that we've seen the floodgates open on the potential of that. E.g. TreeSitter & the SQLite interface in this upcoming Emacs 29 release is only there because of FFI.
I really respect what Stallman's done for the free software movement at large, but I think in this and a few other cases he was fighting yesterday's battles for around two decades too long.
1. https://lists.gnu.org/archive/html/emacs-devel/2010-03/msg00...
modernerd
Emacs deserves the love! (I say this as a former Emacs user who switched to VS Code; I'm now frustrated enough with VSC to be reconsidering Emacs after the 29 announcements.)
It's encouraging to see the big quality of life additions in 29, if only because one person's “just a package-install away” is another's “should be bundled by default”.
And it's not just the headline features. There are many little things from the 29 notes[1] that solve minor niggles or replace chunks of my old “retired” config:
- New command to change the font size globally. To increase the font size, type 'C-x C-M-+' or 'C-x C-M-='; to decrease it, type 'C-x C-M--'; to restore the font size, type 'C-x C-M-0'.
- New command 'restart-emacs'. This is like 'save-buffers-kill-emacs', but instead of just killing the current Emacs process at the end, it starts a new Emacs process (using the same command line arguments as the running Emacs process).
- New command 'rename-visited-file'. This command renames the file visited by the current buffer by moving it to a new location, and also makes the buffer visit this new file.
[1]: https://github.com/emacs-mirror/emacs/blob/master/etc/NEWS.2...
anyfoo
> New command 'rename-visited-file'. This command renames the file visited by the current buffer by moving it to a new location, and also makes the buffer visit this new file.
FINALLYYYYYYY!
medstrom
For those still on 28, `crux-rename-file-and-buffer` does the same thing (https://github.com/bbatsov/crux). I've been using it for half a decade at this point.
a1369209993
> because one person's "just a package-install away" is another's "should be bundled by default".
FWIW, it's also another's "has transitive dependencies that try to brick my computer". Claims like "just a package-install away" would be significantly more convincing if they could fix that (ie, fix (remove) the ability of packages to have transitive dependencies).
(This isn't anything specific to EMACS, to be clear; I've never seen a mainstream package system that bothered to enforce a meaningful limit on the depth of dependency graphs.)
treeblah
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 first tried 8 or so years ago.
bergheim
How people expect anything else from a huge corporation is mind-boggling to me. They open source something and people think they are being alturistic. Just like android. You start with open source, then move more and more things behind the corpwall.
Emacs is free and is free for life.
Also Davids channel is most excellent. There's a discord channel where people are very friendly and helpful as well.
asdajksah2123
It's kind of funny seeing how every few years we'll have a new hot editor, and all the people who convert to those editors will wonder why anyone would still use Emacs or Vim, only to find out a few years later why people continue to use these 30+ year old editors.
In the meanwhile, both Vim and Emacs will incorporate the functionality that originally made the new editors popular, so the long time Emacs and Vim users lose almost nothing, did not have to go out of their way to use a new editor, and continued to benefit from the existing advantages of these editors.
xypage
I don't necessarily think that anyone was expecting anything else, it's just that VS Code is a great free tool, so even if you know it's probably going to go downhill over time it's hard to deny its effectiveness currently.
I mean it's free, it comes with it's own compilers and toolchains, it's a lot easier to pick up than vim or emacs or even IntelliJ (that's just got a much more dense UI), so it's become the standard IDE for students. Then, once you've gotten your degree or your training or whatever, you'll probably want to stick with the tool you know.
ews
People like David from System Crafters and Prot are definitely doing a lot to bringing Emacs backs to the masses. They are a visible manifestation of the technical (and media) quality of part of the community. I do not think they get enough credit.
Apo1lom
I started using doom emacs cause of distrotube. Switched to vanilla emacs with the help of David
kace91
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?
tmtvl
Depends on what you're gonna be doing with it. If you're mainly working with HTML, CSS, maybe some Bash scripts, you can just open it up, work your way through the (IMO excellent) tutorial and you're off to the races.
That said, if Emacs gets its claws in you you may, like me, lose a fair few evenings and weekends just playing around with various packages and customization options because it's just so fun to tweak.
coutego
If you install Doom Emacs [1] after installing Emacs itself, I think it would be a couple of days. At least if you can live with the things Doom comes with. It's just a matter of following the instructions, uncommenting the relevant modules in .doom.d/init.el, syncing the changes and off you go.
kamaal
>>As a vscode user considering the move, how difficult would it be to get to the point of making emacs a daily driver?
Among the big list of features missing in Emacs as of now is remote development that way its done is vscode.
ParetoOptimal
I'd say give using it for weekend projects or a day or 1/2 day a week at work a try.
scombridae
System Crafters youtube channel driving me towards Emacs
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.
ParetoOptimal
> 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 your endurance for feeling like you're always in a dark room feeling around... and you convince yourself that it won't be like this one day.
A decade or two later you realize you've become accustomed the darkness...
aeonik
For me, I just changed my note taking system to Logseq last summer which supports org formatted notes. I had heard about org mode, but it seemed like too much trouble to learn Emacs for note taking.
Cue Distrotube on YouTube creating a series that makes it really easy to get started with Doom Emacs, and cue me wanting to learn Clojure combined with it being to hard to modify VSCode's Calva and Cursive... and I finally had enough arrows pointing toward Emacs.
Best decision I've ever made. Emacs is slowly consuming all of my workflows. I finally feel like I have the editor of my dreams, it's just a little rough around the edges still.
I hope to contribute to it once I get better.
cmrdporcupine
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 IDEs.
My new job is all in Julia, and I suspect emacs will provide a better experience for that than a Jetbrains IDE. I'll give it a whirl.
heintje_ghulam
Hi! Happy to see someone interested in using Emacs for Julia work.
I recommend the following packages for your setup:
julia-vterm (https://melpa.org/#/julia-vterm) (https://github.com/shg/julia-vterm.el)
ob-julia-vterm (https://melpa.org/#/ob-julia-vterm) (https://github.com/shg/ob-julia-vterm.el)
FYI, julia-vterm depends on:
julia-mode (https://elpa.nongnu.org/nongnu/julia-mode.html) (https://github.com/JuliaEditorSupport/julia-emacs)
vterm (https://melpa.org/#/julia-vterm) (https://github.com/akermu/emacs-libvterm)
patrick451
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.
karthink
> My new job is all in Julia
Where is this, if you don't mind my asking?
cranium
I switched from Vim to Spacemacs years ago and I was generally willing to roll up my sleeves to configure it in exchange for the additional power and freedom. But now, with the maturity of these pre-configured distributions and the nice things like LSP, you don't even need to fiddle much with elisp to have a solid environment working for you. I can now imagine introducing Emacs as a first text-editor / IDE to a novice (OK, maybe not with the Vim layer enabled).
fifanut
The Emacs ecosystem has a larger contributor pool, and contributing is easier.
A bunch of factors off the top of my head:
* MELPA making contributing and reaching users easier.
* The growth of Emacs packages on GitHub. * The ease of concurrent programming, e.g. emacs-aio.
* The learning curve being reduced with spacemacs and Doom.
* The continued development of Emacs upstream by its great contributors.
* The increase in upstream development, with emphasis on bug tracker hygiene. See Lars blog posts.
* LSP/Treesitter being developed, though this doesn't explain why Emacs seems to get more HN visibility than other editors.
If I put my Emacs hat on, perhaps the promise of Emacs is being fulfilled: an ever growing set of interopable, extensible, introspective functionality being useful to a wider set of active users.
klibertp
> * The ease of concurrent programming, e.g. emacs-aio.
There's no such thing. emacs-aio is an extension bolted on top of generators and promises, which is how it was bolted on in Python too - so not bad by itself - but the problem is that nothing in Emacs core supports it. Async in Emacs is still, in 2022, a callback hell, and it's not even supported in newer APIs, like completion-at-point (which is awful - I understand that the origin of this is minibuffer completions and that it might be justified to do everything synchronously, but in-buffer completions should not freeze the editor!)
Now we have threads, but seemingly nobody uses them - not surprising, given that last time I tried I got a segfault pretty quickly (fixed since then). Still, threads? With locks and semaphores? Didn't we all agree that these are not the greatest primitives for concurrency? What about channels or async streams? Not to mention, the threads normally should be preemptively scheduled, while currently they are "mostly cooperative" in Emacs. IOW you can still run code in a thread that will not return control to any other thread, as long as it doesn't do IO. Which would be fine with coroutines, but these are supposedly threads! So you pay in memory for threads but get coroutines, but with pretty fuzzy notion of what's atomic. It's a cosmic horror story.
I'm trying to write a "guide to modern Elisp programming" - there were definitely very interesting and good developments in Emacs Lisp over the last 5 years, and generally the language, coupled with convenience libraries like cl, seq, s, f, and so on, became a very productive environment. EIEIO (and cl-structs) and multimethods (true multimethods, which landed at some point in cl-lib without much fanfare, though they really deserve more attention) are incredibly expressive if you don't mind a bit of syntactic overhead (clojure-style . and .. would be appreciated). cl-loop is incredibly versatile tool that lets you declaratively state almost any kind of iteration and reduction. There's object inspector, there's a package supporting many kinds of refactorings, and of course helpful for rendering information about commands, functions, and variables. It's overall great and productive environment... until you try doing async, unfortunately.
ywei3410
Regarding threads, they are definitely more co-operative co-routines than threads.
However, if I recall there are only a few calls which can switch the context; the usual culprits, such as `thread-yield`, `sleep-for`, `accept-process-output` and atomicity is guaranteed apart from when you use these calls. So you'd never be in a problem state of `setq` failing halfway, for example.
Personally, I think this model works much better with the current code in Emacs. It would be good if we could spin up domains like in Racket for true parallelization (which uses channels for communication) as well, but threads are pretty useful already if hard to code with.
I don't believe there are any locks or semaphores at all, but I'm happy to be educated.
EDIT: caveat ofc, that non-Elisp code can be parallel but the filters and sentinels will only run if they can grab the context.
tikhonj
Seems like Emacs has always had a presence in the cultural background of online programming—most people might not use it, but they're aware of it and maybe vaguely curious—so it takes a relatively small push to generate discussion. The substantial new features in the last couple of releases is enough of a push, especially after a prolonged (perceived?) slowdown in changes.
modernerd
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?
[1] https://bitbucket.org/mituharu/emacs-mac/src/master/, used by https://github.com/railwaycat/homebrew-emacsmacport
fayten
My preferred distribution for emacs on macos is: https://github.com/d12frosted/homebrew-emacs-plus
It's well documented and supported, I highly recommend it!
xenodium
+1 I’ve been using native comp (and other goodies) on M1 via emacs plus https://xenodium.com/emacs-plus-with-native-comp/
mark_l_watson
Thanks!! I hadn’t seen this, will try it today.
letmeinhere
yeah, options for native compilations on/off, nice custom icons, comes with a `brew service`; very solid
Kalq
Just an fyi for people using straight or interested in it, its maintainer is working on an alternative called elpaca.
ashton314
I've been driving elpaca for some weeks now and it is fairly usable. Very fast installs. Occasional jankiness (as is to be expected from alpha software)
mark_l_watson
I just started using Straight a few months ago, best improvement that I have experienced in 40 years of Emacs use. I will definitely try switching to built in support for package.el, as well as switch to eglot and other new built-in features. I prefer shorter Emacs config files.
wrongotron
I always grab dmg's from here: https://emacsformacosx.com/
e40
This has been a reliable source, over the years. I love it.
kickingvegas
I use the MacPorts build of Mitsuharu Yamamoto's port https://ports.macports.org/port/emacs-app/
kickingvegas
Posted the wrong link. Here's the correct one. https://ports.macports.org/port/emacs-mac-app/details/
hanche
I’ve been using Mitsuharu’s port for years, always compiling it myself from his bitbucket repo. I am no longer sure how different it is from the vanilla GNU distribution. When I first started using emacs, long before the Mac port, the current version was 18.57, I think. It was a long wait for version 19 to appear, being the first version with proper X11 support. It amazes me to think of how much has happened since, and that emacs is as useful and relevant now as then.
lanstin
I have been compiling from git head since they added jit compilation, as it is much faster. (On Linux and Mac). Sometimes I run into weirdness and repull and recompile. My version says 30 now, but if homebrew packages 29 I might switch back.
catern
Just as one data point, I have never used straight.el, package.el as it exists in even Emacs 26 is sufficient for me for all my packages. I think this is true for the majority of Emacs users that use packages.
yewenjie
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 activity about Emacs configurations two-three years ago.
> Compile EmacsLisp files ahead of time
Ooh, this is interesting. Hoping to see a derivation in https://github.com/nix-community/emacs-overlay soon.
[0] I am not complaining though as Doom was the main author's personal config from the get-go. I am just pointing out a void.
jacobsenscott
I don't know if doom or other sort of meta-emacs distributions are as useful as they were a few years ago. Good package management is baked in to vanilla emacs now, and most any package can be configured without writing a line of elisp with the M-x customize-group.
I recently went from a whole subdirectory of configuration files to the single default init.el and have been very happy with it. I am still using `use-package` for some packages, but I don't really find it any better than just M-x package-install and M-x customize group.
In fact I would encourage new emacs users not to use some any meta-distribution or third party package management - none of them will live as long as emacs (which will live forever).
tikhonj
I've been using Emacs overlay to compile packages ahead of time for a while. Unless I've misunderstood how it works, that's what the variations on emacsWithPackages do.
I use the version of emacsWithPackages that parses use-package declarations from my .emacs file and uses Nix to compile and install the corresponding Emacs packages. The upside is that this also pulls in native dependencies (pdf-tools/etc) but the downside is that adding a new package requires rebuilding at the Nix level and restarting Emacs. It has not been a major problem for me—I don't install new Emacs packages very often at this point—but I can definitely see how it could get annoying for anyone who does!
tadfisher
While not in line with the Lisp philosophy, it's far more hygienic to restart Emacs after a configuration change rather than reloading the init file. There's really no way to bring Emacs back to a pre-init state in order to recreate the initialization process. Not to mention that compiling the init file runs different code than loading the init file, and Lisp expressions are far from idempotent, so you can't really be sure your changes work until you restart Emacs anyway.
theCodeStig
This echos my set up, and it's quite stable, particularly if the overlay is pinned.
YetAnotherNick
It's definitely not stalled by any metric: https://github.com/doomemacs/doomemacs/commits/master
e3bc54b2
It is not stalled, but as it currently stands, Henrik is bottleneck. He used to work like a fiend, but obviously its not sustainable for one guy to keep carrying on for something with as large scope as an Emacs distribution.
There are plans to split doom-emacs' core and contrib modules in separate modules, but no idea what the progress is on that.
yewenjie
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.
smsx
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.
bigpeopleareold
I tried Prelude and Doom. After some time with Doom, I switched back to Prelude. Doom was too buggy for me. While it is not really a problem with Doom (in that I can configure it myself), the idea of using Doom ended when the default selections for Python-LSP were awful (wanted to just use Jedi, but it only had the Microsoft one, which at the time, had a horrible memory leak.) My old Prelude setup covered exactly what I needed.
truncate
As a lsp-mode users, why switch to eglot?
NoGravitas
If you're happy with lsp-mode, there's not much reason to switch. The main thing about eglot is that it's less-intrusive. It doesn't make any UI changes (unlike lsp-ui), and doesn't even install a keymap by default. But it hooks into Emacs' existing facilities (like xref and completion-at-point) and lets them use an lsp-powered backend. There are functions for things that don't already have an equivalent (like refactorings or code actions), but they're not bound.
anyfoo
> like xref and completion-at-point
Where does that persistence myth come from that lsp does not hook into that? Maybe it once did not, but I've been using lsp for at least a couple of years now and I do not remember it not using xref. Not so sure about completion-at-point, haven't checked because my completions work as they should using company.
srcreigh
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.
ParetoOptimal
Using lsp within devcontainers/docker containers via tramp.
deagle50
pixel-scroll-precion-mode kcbanner
Check out good-scroll: https://github.com/io12/good-scroll.el
You can configure a custom refresh rate.
LanternLight83
This, pure GTK on Wayland, and background-alpha are all game-changers for specific folks c:
teucris
Watching the Emacs community, I’m always just blown away by the love and adoration it gets. It’s clear to me that there’s something magical in it, but I can’t seem to tap that magic for myself. I’ve tried - really tried, including relearning lisp - to adopt Emacs roughly four times over my career; it never stuck. I understand the basic benefits, eg keyboard-optimized workflows, deep customization/malleability, etc. But despite my attempts, it just isn’t… accessible to me. What the heck am I missing? Should I just recognize that it’s just not for me?
tmalsburg2
You say "it just isn't accessible to [you]". If I'd install vanilla Emacs today or one of those distros, I'd probably feel the same, i.e. that Emacs is not for me. However, what makes Emacs great is that I can make myself at home in Emacs and design everything the way that works best for me personally, even if that is perhaps highly idiosyncratic. So my advice would be: Install Emacs and if there is something that you don't like, don't ask what you're missing, but simply change it. One thing I hated about Emacs were the RSI-inducing keybindings. And this is how I became one of the first 5 users of evil-mode (which provides vim keybindings). Over the last 15 years my Emacs config has grown to 4k+ lines and that seems bizarre, but the result is an editor that works really well with my personal way of thinking. It almost feels like an extension of my body, which means that I use it without thinking about it. It gets out of my way cognitively and doesn't add extra friction to my work which is already complicated enough. That's worth a lot to me.
teucris
So for you, Emacs is more like a library or editor engine than an application? That makes sense and may explain why I didn’t connect with it, in that I’m used to adapting to my tools rather than building them. I need to change contexts frequently so I’ve made myself malleable rather than my tools.
medstrom
That's a great explanation, you have quite the way with words!
I'd add that it isn't only about preferences. Obviously if it works equally well either way, you save time and energy by just adapting yourself to your tools and appliances and moving on with your life. But doing so sort of sets a ceiling on what you'll ever imagine any tool can do... This touches on what I'm getting at: https://djrobstep.com/posts/programs-are-a-prison
G3rn0ti
Maybe you just haven’t found a killer feature for you yet that blew you away. Personally, I also can’t give you THE one use case that sold me on Emacs. It’s more the integration of a diverse set of tools together with its robustness that really makes it shine.
I have used vanilla Emacs for a long time with only a couple of packages installed (basically flyspell and web-mode) and everything worked for me although it was quite boring. That’s because I managed most of my dev workflow outside of Emacs. The JS dev server took care of reloading and transpiling, the linter ran as a test step and I used git on the command line for version management.
These days I do a lot of backend work, most importantly REST APIs. So have to tweak server code, restart the server (not always written in JS), test out new end points. So I am using the built-in „compile mode“ running a bash script automatically deploying my code changes using ssh upon two key strokes (C-c C-r). Emacs returns syntax errors including file names and lines, so I can jump straight into the code to fix the issue. Once running I switch over to a „restclient.el“ session to try my code. With another two key strokes (C-c C-c) I execute a request (however complicated) and receive the JSON response in a temporary side buffer which I can filter using „jq“ with another key stroke thanks to restclient-jq.el. I can inspect runtime errors on the server by opening the remote log file using TRAMP mode (alternatively, I open a „term“ session and invoke „tail -f“). Once the code works I press „C-x g“ to switch over to „magit“ to stage or commit my changes. If I have to work on two or three things in parallel I use „perspective.el“ to maintain something akin to virtual desktops, so I don’t have to re-order my buffers all the time. I also do teaching on REST APIs which I do using „org-mode“ together with „org-babel“ and „org-tree-slide“ allowing to inline actual restclient.el sessions among text or graphical slides. I also use org-mode for technical documentation including executable code and for explorational SQL development. You see, in Emacs many packages just glue together seamlessly thanks to its brilliant API that stood the test of times.
I didn’t start using all of this on a single day but Emacs sucked me into its eco system very slowly until I just couldn’t imagine using anything else anymore. It just takes time to get to know these things and getting comfortable with Emacs‘ configuration system.
marai2
Please do a YouTube video demo-ing the above workflow! It would be really valuable in showing how all of these integrations work together.
I am a long time emacs user but I'm not aware of some of the modes you mentioned above and it would be awesome to see a video tutorial!
bombcar
Emacs is a lifestyle and it takes time to get into it. The jokes are pretty spot on - it's a wonderful operating system; it only needs a decent text editor.
You'd probably have to "dedicate" yourself to it for a month or more (and having a "mentor" or support group that can answer questions and telling you there's an easier way to do it would help).
It was MUCH more powerful (relative) when we didn't have much beyond a terminal emulator.
bergheim
What I tell my programming friends is that if you can see yourself molding your computer user-interface as sort of a hobby, then emacs is most definately for you.
If you don't see that as a fun past-time activity, then I would not recommend emacs.
For instance, (in my emacs email client) I just made a change where if I want to search the subject I am looking at, and it has a #XXX in it, then the subject search is just that number. Makes me able to quickly load up all emails related to that ticket. This makes me happy.
Also: same keyboard interface to everything.
ParetoOptimal
> Makes me able to quickly load up all emails related to that ticket. This makes me happy.
Yes, I love this.
Relatedly emacs is good if you find small annoyances or imperfections hard to "just deal with" and have the time and skill to customize or "craft" your emacs.
psychphysic
> Also: same keyboard interface to everything.
I still have to look up how to add hooks (decades into using Emacs as my primary editor).
But using the same shortcuts in every readline prompt is just so comforting.
St_Alfonzo
> [...] if you can see yourself molding your computer user-interface as sort of a hobby, then emacs is most definately for you.
> If you don't see that as a fun past-time activity, then I would not recommend emacs.
If you don't see that as a fun past-time activity and still want to use emacs, then I would recommend spacemacs.
ParetoOptimal
And if you find yourself between the two extremes, perhaps https://github.com/SystemCrafters/crafted-emacs
bergheim
As a guy that has used both spacemacs and doom emacs (which I would recommend over spacemacs), I disagree - you still will be mucking around with things. Emacs out-of-the-box 2022 leaves a lot to be desired, configurations makes it easier, but it is still not the vscode experience, even though it helps you a LOT on the way.
wara23arish
which email client do you use?
bergheim
I use mu4e. As an example, the code for the subject thing is here https://github.com/bergheim/dotfiles/blob/025b8e6c9730f09fe1...
kfajdsl
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 Code in a much more user friendly manner (VS Code remote editing blows TRAMP out of the water), with the caveat that multiple projects means multiple windows, it's difficult to have an entirely mouseless workflow, and in general it's less customizable than Emacs.
I personally never bothered to learn Emacs keybindings and instead use Vim keybindings in every editor I touch; VS Code and Emacs both have excellent Vim plugins.
Honorable mention: Neovim. It is lighter weight than either Emacs or VS Code but can still have pretty much all the bells and whistles. Definitely cool if you prefer to live in a terminal.
ParetoOptimal
> 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 discrepancy of course, but I think it's still useful given I can't think of many other plaform differences and that it's consistent amongst my coworkers.
kfajdsl
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!
zelphirkalt
> 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 tramp into docker container on a remote host via SSH for the following reasons:
When I use keyboard shortcuts from inside that tramp shell, Emacs understands, that it happens inside the tramp context and for example will only show me files inside that docker container, when I do a find-file. Should I decide to run an rgrep from that context, it will show me results in that context. If I click the findings of that rgrep, it will probably open the findings, which are on the remote host inside the docker container. If I open dired from the tramp context, I will see files from that context, not files on my own machine. Context is the magic here.
This level of integration is missing from VSCode. VSCode replicates part of these things, but things are not integrated. Want to ssh into a server? OK can do. 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. This might be a consequence of things being less coupled with keyboard workflow. When I use a mouse to click some menu items, it is not clear to VSCode in which opened tab/buffer that action should be performed. When I press a keyboard shortcut in Emacs, there will be a buffer (or mini buffer, or whatever) which has the focus and does not have to lose the focus, because I am not using the mouse to click outside of it. Things which are taken for granted in Emacs (all that integration and generic actions, which work anywhere) do not seem to exist in VSCode. Maybe most people are not even aware of how generic actions like opening a file could be integrated, because they have never seen it like it is in Emacs.
On the other hand, VSCode might have a more fluent experience for when you do not want to do anything more complex than SSH into a server and might be speedier at those simpler workflows. There are probably well paid engineers at MS, who try to make things run smoothly when the shell is an SSH session on a remote server. I have not benchmarked this. Just a guess.
kfajdsl
> 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.
sokoloff
> VS Code remote editing blows TRAMP out of the water
I’ll have to try VSCode in this area, but Tramp seems pretty awesome to me so I’m trying to think how it could be blown out of the water.
kfajdsl
In the "just works" department mainly, especially in regards to other packages playing nice with tramp.
alwillis
Neovim. It is lighter weight than either Emacs or VS Code but can still have pretty much all the bells and whistles. Definitely cool if you prefer to live in a terminal.
There are several GUIs for Neovim for various platforms [1].
[1]: https://github.com/neovim/neovim/wiki/Related-projects#gui
jcpst
For me it was org-mode. Emacs is basically my org mode interface.
luxcem
I've used emacs for ~15 years now and never really get into org-mode, I have a directory of org files that I use for writing and keeping some kind of personal wiki but it's just a bunch of org files. I never successfully build a workflow around it.
I see that I'm missing something but I don't know where to start. Org-roam seems interesting.
Do you have any recommendation for how to use org-mode productively?
ParetoOptimal
> Do you have any recommendation for how to use org-mode productively?
I have a treat for you!
Free video course:
https://m.youtube.com/playlist?list=PLVtKhBrRV_ZkPnBtt_TD1Cs...
Paid udemy course (improved?) version:
https://www.udemy.com/course/getting-yourself-organized-with...
Something different blending org-mode and org-roam:
https://d12frosted.io/posts/2020-06-23-task-management-with-...
zelphirkalt
You don't necessarily have to build your own workflow around org-mode. If it works fine for you as it is, then that's OK. It is a fine markup format in itself. Finer than some others. Emacs has exceptional support for org-mode of course, which allows for good navigation within a document and things like folding headings and showing an overview.
If you want to go further, you can use things like including other org-mode documents at specific heading levels or even write thesis in it, falling back to latex when needed. There is also a citation format now in org-mode.
Another thing you could explore is org-babel. Try out the ideas of literate programming. A bit of "write once, export to other formats" like HTML make a blog post or similar.
I also use org-mode for some spreadsheet capabilities. Not really huge spreadsheets, but usable. For example I have working hours time tracking in org-mode using a table with formulas (a spreadsheet). Or I have a repository with recipes, where I can let it calculate amounts of ingredients, depending on the number of people who want to eat.
bergheim
For me:
1. Learn org-agenda. And I do mean really learn it. I use a few of alphapapas amazing packages (org-super-agenda and org-ql). Learn the difference between just a TODO, scheduling, deadlining and tags. Don't overdo it on tags. Set up groups in the agenda for different things (STATE or TAGS, or something else)
2. Set up capture templates that fit you so you can instantly note things down in the right place
3. Learn org-attach so that you can have everything in your second brain
4. Do not fret to much about one large file or many small ones - use whatever you want. If you feel you want to change it, just change it. It is just plain text. This applies to everything in org-mode.
5. Learn org-store-link, which makes references to things like emails (even if they are moved/archived after the fact) or git or whatever to keep references.
I spent a lot of time getting this together myself. I empathise. But if I could not use org-agenda and the searches I have in the way I do, I would probably feel not get into org-mode either. Recall is key.
donio
Maybe you don't need an org workflow. "Just a bunch of org files" is a totally fine way to use it. It's what I do too with some custom keybindings and bookmarks. I looked at some of the fancier stuff but they are not for me.
taude
Like yourself, I don't do anything fancy. Just plain org files. However,
I do use org-journal [1], though, so I can ctrl-c ctrl-j to add a new entry, and have it automatically wired up for rotating the file monthly. I use this for adding new items and having speedy access. But that's it. I don't use Agenda or any of that fancy stuff, so don't feel guilty that you're missing out.
easyorgmode
Here is one way explained. It's written with EasyOrg as Agenda/Calendar in mind, but should work equally well with Emacs.
https://easyorgmode.com/blog/how-i-use-org-mode-to-keep-trac...
jcpst
Probably going through Rainer König‘s org-mode tutorial series on youtube. I like that it’s all with vanilla org-mode. That way you can dig deeper into anything he’s doing in the org-mode docs or on worg.
I don’t have a very rigid workflow with it. Typically one org file will be a project I’m working on. I use custom “TODO” tags to show the state of items. I also love the table functionality. It basically replaces spreadsheets for me and it lives with the rest of the text.
https://m.youtube.com/playlist?list=PLVtKhBrRV_ZkPnBtt_TD1Cs...
okprod
I find people who like working with plain text tend to love Emacs or similar editor ecosystems. I really enjoy having almost all my workflows in one place, and once you get a handle on some keybindings you can manipulate text so fast and so cleanly it can be satisfying. I also know people who love things like shared editing of tasks, reminders with color highlights, etc. and they tend to not like Emacs. PS: I don't listen to music or plain text browse the Web in Emacs but I know people who do :D
sokoloff
I find the consistency and configurability great, but for me the killer features were being able to write elisp and kbd-macros to accomplish tasks that (most?) other editors can’t.
Modern conveniences include magit (the best git [porcelain] I’ve ever used) and cider, but I’ve been using emacs for 30+ years now and feel like for all but the first 6 months, it’s been an increasing time-saver and powerful lever for me to use.
chungus
>For all three HaikuOS users out there, good news, you now have access to Emacs! (In all seriousness, I should check out HaikuOS one day)
That's great news!
hanafudafan
Worked in the terminal before, but this is a great improvement.
Tomte
> Native access to SQLite databases
I'm excited for this. May there be a nice database CRUD mode in the future.
geospeck
I am not quite sure how this particular feature will look but Emacs can be already used as a SQL client. Here is a short demo https://www.youtube.com/watch?v=D97vDu_BhwA
Here is an introduction blog[1] and the related mode[2]
[1] https://emacsredux.com/blog/2013/06/13/using-emacs-as-a-data...
[2] https://github.com/emacs-mirror/emacs/blob/master/lisp/progm...
matthews2
There's sqlite-mode, try it with M-x sqlite-mode-open-file :)
Tomte
That's only for display, or am I mistaken? Can I change entries?
ParetoOptimal
IIRC i use sql-sqlite for opening sqlite emacsy database shells.
buescher
Emacs-cess!!!
tgv
One unrelated thing: the other day, I wanted to download emacs for windows. I got redirected to an http site. When I go through the list of GNU mirrors, I see this:
17 times ftp
74 times http
71 times https
65 time rsync
medstrom
This sort of thing is not as much an issue as you'd think, because at least in Linux world, most automated downloads will compare the SHA256 sum with a reference sum retrieved from a HTTPS site (there you go!), if not the GPG signature.
If downloading a file manually, the download pages also tend to recommend you follow provided instructions for doing this yourself.
tgv
The download page randomly picks a mirror, so chances are you get an insecure connection. And the signature won't do much good if it's http or ftp too. For Linux it may work, but for Windows it doesn't.
medstrom
The signature works fine over HTTP/FTP because it needs to be combined with a public key you already have (e.g. a distro package manager will already have the public key for all the packages), or a public key you will go get from a different source, e.g. https://sks-keyservers.net, and it's hard for a middle-man to compromise both.
BeetleB
I would recommend emax64 for Windows, not the standard Windows version.
jimbokun
This sounds interesting:
> This comes with a new sqlite-mode which allows you to explore SQLite databases within Emacs and to interact with them. Check out the sqlite-mode-open-file function!
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.
znpy
I’ve seen various opinions about eglot vs lsp-mode… anybody care to explain if eglot is better and in general why it was chosen for inclusion in emacs?
G3rn0ti
Eglot does not have as many dependencies as lsp-mode and was designed to work closer with Emacs built-ins. Lsp-mode comes with many non-standard gui extensions — with some of them being quite cool, honestly — but they make the setup more complicated. Eglot supposedly just works out of the box.
znpy
Thanks!
Get the top HN stories in your inbox every day.
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.
- File supporter just like VSCodes.
- Project management tools.
- Fuzzing finding for everything, including files, commands, and buffers.
- Probably the best git client out there (magit). It's seriously magical.
- Terminals (can pipe terminal contents directly into other buffers).
- DAP mode for debugging, ctags, cscope.
It's all FOSS, worked on by a non-profit foundation and volunteers, it can be used as a GUI or in the terminal, and it's insanely extensible thanks to it being a small C core running a lisp environment. Lisp is easy to learn and fun, and if you don't like lisp there's still a bazillion more packages you can install for extra features.