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.
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.
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).
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.
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.
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?
The example in that vscode link can be replicated in emacs by:
1. having a single buffer open
2. C-x 2 (split-window-below)
3. C-x o (other-buffer)
4. C-x 3 (split-window-right)
5. C-x 3 (split-window-right)
6. C-x + (balance windows)
If that seems unwieldy you can also make a macro to automate such a thing or anything your imagination can come up with. Then any function you make (such as saving that macro to a name) can be bound to a keybinding of your choice.
If that's interesting to you, also see "Keyboard Macros are Misunderstood":
In fact, if you really want to understand Emacs in addition to replicating your current vscode workflow or even to augment your current workflows you should check out his book that was recently updated for Emacs 28:
He typically updates the book pretty quickly, so you'll get any future updates he may make. I still highly recommend the current version after having ready 5 or 6 chapters recently and feeling like I leveled up my own understanding.
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.
>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
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.
> 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.
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.
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.
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.
I started with Doom to discover what features were available/useful to me. Then I built my own config from scratch recreating/borrowing only those features.
I got pretty close apart from the above sticking points. I only moved on when I realised how much time I was spending writing Emacs Lisp to solve my remaining pain points. I miss it, though!
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?
> 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.
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.
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.
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.
You can run an emacs daemon[0] and connect to it from clients both local and remote, including having multiple clients connected to the same daemon and editing the same file with total synchronization built in, you see not only the changes in realntime but the other client's cursors making the changes, for the masochists that enjoy pair programming.
And yes you can run the client using the gui emacs not only terminal emacs.
Your comment is confusing in the same way as the the other guy's is. In fact it is worse.
None of the machinery you describe can be used for anything except specifying files (and line numbers and column numbers) to be visited. An emacs user still needs some way of interacting with the visited file, e.g., a terminal emulator or an X server. This "Emacs server" does not help with that. It's another example of Emacs using unusual terminology!
Have you actually used Emacs or do you just enjoy making pendantic confusing replies?
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.
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)
> 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.
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.
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?
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.
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.
> 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.
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.
> 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.)
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.
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.
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.
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.
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.
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.
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.
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.
> 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...
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.
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.
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.
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).
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.
> * 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.
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.
That's basically what every other threading library provides in most languages... and it's also what was shown time and again to be very hard to work with directly. Higher-order abstractions are necessary to make parallelism safe and concurrency convenient.
> 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.
That's true - it looks like Emacs uses a global lock to ensure the atomicity, similarly to what Python does. Also like in Python, you can release that lock from native code (module or core). You cannot touch any interpreter state from other threads, so you need a bit of plumbing to get the results back, but it's possible. I found this: https://github.com/emacs-lsp/emacs/blob/json-rpc/src/json.c very interesting: it's a fork that moves JSONRPC from Lisp to C and out of the main thread. See for example line 1109 and related.
> but threads are pretty useful already if hard to code with.
That's the point: the capabilities are there (mostly), but abstractions are not. Coding with threads, even in the presence of the global lock, is hard, and ensuring correctness is nontrivial. At the very least we should get channels for communication (share by communicating, don't communicate by sharing) between threads and thread pools for executing tasks (like futures in Java or Python, or Task in Elixir). Threads and locks are way too low-level for normal coding. I suspect that's the reason why they're not used more widely, even though they're there for the third(?) release now.
Aside: Racket is actually a nice example of concurrency and parallelism being treated as completely separate concerns. IIRC threads in Racket are call/cc-based green threads, while places are separate instances of the VM that execute in OS-level thread or separate process. Threads provide concurrency and places provide parallelism. It's actually a good thing, I think. Mixing the two is often a major source of errors. Racket also has futures, which are parallel-if-possible primitives that can benefit from parallelism if they don't touch external state - a sort of a middle ground.
In any case: yes, Elisp threads are a good addition to the language, but they alone are not enough to bring concurrency to the masses, so to speak. As a concurrency primitives, and compared to callbacks, they have few advantages and some serious downsides. Emacs still needs a lot of work on the concurrency front. And don't even mention parallelism, that's another can of worms that we don't really need to open :)
Thanks for the link; not sure how I missed that completely while going through the thread documentation.
I completely forgot about native modules completely...
I don't think I disagree with anything you've said; though I would add that the fact that not many things use threads means that it's self-fulfilling (for example I have a package in the works and it was _super_ unclear to me about what the semantics of how threads interacted with the existing processes and when you could guarantee certain things ran before others).
Yes, Racket's model is broadly as you've described (and soon ocaml will have a similar model I think?), and imo it works really well.
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.
Yes—Neovim has gotten a lot of press the last couple of years on HN and elsewhere.
Native LSP and Treesitter support for Neovim shipped nearly 18 months ago.
Someone asked if the uptick in interest in the venerable (Neo)Vim and Emacs editors was due to the neckbeards awakening from their hibernation… something to that affect.
What’s interesting about the Neovim community is how young most of the core contributors and those new-to-Vim are. Lots of vs code refugees.
I think there has been quite a few very fundamental enhancements to Emacs recently. The JIT which was added to 28 and now a pure GTk Emacs. This fixes some very long standing infrastructure issues and enables further exciting developments. A faster Elisp not only makes the editor feel snappier - it also opens up application development in Emacs. It becomes feasible and nice to develop much larger packages or even complete software on top of Emacs.
The pure GTk Emacs cleans up the UI handling and I hope this also means for more widgets becoming available to Elisp. This would enable quite a lot of interesting additions.
When I started using emacs 15 years ago, most people did not use a text editor as such. They used specialised IDEs, an email app, a text editor, a note taking app etc. I soon realised that using a single text editor for everything that was text was great, and that also, most things are probably text. Like almost everything i do with a computer is editing text.
I think editors like VS Code and I guess Atom etc. to a lesser extend have made a lot more people aware of this and it's caused people to take a new look at emacs since it was doing the same thing decades before and arguably does it better.
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)
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.
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.
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.
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.
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.
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).
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!
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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
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.
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.
I don't know. I used emacs for a solid year (in evil mode admittedly), and my configuration kept breaking with new updates. I spent more time fiddling with my config files than being productive. I love lisp and the idea of emacs. But when I started using vscode, my productivity immediately jumped. Emacs also suffers from latency spikes, even worse than vscode does. I want Emacs, but with the speed of Rust, and the polish of vscode.
I don't think that's what he is saying. He is saying that Emacs once ruled supreme because it was the only option. Now that IDE's have caught up, it's in the lead by only a little.
I'd say still by a lot, but yeah, IDEs have advanced in the last 20+ years (and one of the main advantages of something like VScode or IntelliJ is that it does a lot "out of the box" and it's pretty discoverable).
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.
> 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.
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.
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.
> 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.
> 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.
> 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.
> 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.
> 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.
I know about that, but AFAIK running Emacs server and client on different machines isn't really supported? Like all Emacs client is doing is executing some Elisp on the Emacs server to tell it to spawn a new frame the same way you can from a regular Emacs instance (that is, the frame spawns on the remote, not locally).
Regardless IMO just using TRAMP and just installing an LSP server on the remote is the simpler and lighter weight solution. The big thing is, I don't want to have to set anything up on the remote. An LSP server that can be easily installed by the system package manager with no further configuration is okay, I deal with that. Anything more, nah.
> With Emacs one does not have to start multiple instances to get things done, but does everything out of the same instance.
Yes, this is a tradeoff, and me being more comfortable with that workflow is one of the reasons I use Emacs. In fact, if so desired, you can still launch multiple instances for different things; me being able to fine tune my workflows instead of my tools dictating them is the big draw of Emacs for me.
>>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.
This is one more thing which emacs/vi people don't get. Most people don't care for things like start up time, or restarting their editor/ide a few times. Because time spent writing code far exceeds a few minutes/seconds of this sort of stuff. When you optimise for things like these, at the expense of features like full remote integration you are optimising for things that majority don't care for things that are irrelevant in the context of modern day development.
>>You can run Emacs as a server, for example on a remote host
vscode is all about doing work the user should be doing. Nobody should be spending lots of times, in case of emacs that's often weeks to months of effort configuring and tweaking things that should come and work right out of the box.
> This is one more thing which emacs/vi people don't get. Most people don't care for things like start up time, or restarting their editor/ide a few times. Because time spent writing code far exceeds a few minutes/seconds of this sort of stuff. t care for things that are irrelevant in the context of modern day development.
It is not, that they/we do not get it in general. You are painting with a very broad brush there. Not all Emacs or VI users are the same. Not all of them/us are endlessly optimizing startup time. Often the opposite is true. We do not optimize it, because we start Emacs when the day begins and close it, when the day ends. Because why would we ever close it at other times? No need to.
It is probably more, that many see it as inappropriate functionality, when one has to close the application and re-open it to do something so simple, that comes out of the box with Emacs. We are used to have this functionality without restarting and we wonder how one could accept this kind of shennanigans.
With VIM or its variants I can tolerate it a bit more, as it is more minimalistic than Emacs in its approach. It is often used as a quick command to open a file on a server, safely (model editing) edit the file and exit (no jokes now!). A one-off operation, not a long session of developing. There are people doing long sessions of development in VI variants as well of course. I have done that in the past, with a heavily configured NeoVIM, using some plugins and it worked quite well.
I would guess, that many people see it as an improper way of doing things, when one cannot accomplish a task directly in ones main editor, but needs to close it or open additional instances of it. The question automatically arises, what the problem is and why it cannot be done in the instance you already had opened. Was the previous instance somehow bad? Does an instance have a half-life period or something, so that it needs to be refreshed?
> Because time spent writing code far exceeds a few minutes/seconds of this sort of stuff.
If I configure for myself in my free time the "optimal tool" and then just copy its configuration into my on-the-job tool, it is my time to spend and does not take anything away from the time writing code on the job. In fact, it even increases my productivity, compared to what some people do with VSCode instances being closed and opened and all that. No one else has to worry about how I personally spend my time. Even if I wanted to spend a few hours a day optimizing my own tooling in my free time, I should be allowed to do so.
If others want to work with less optimized tools or do not want to invest time into making their tool work as well, that is their choice. Doesn't make it less painful to watch in screensharing sessions though.
>>You can run Emacs as a server, for example on a remote host
> vscode is all about doing work the user should be doing. Nobody should be spending lots of times, in case of emacs that's often weeks to months of effort configuring and tweaking things that should come and work right out of the box.
Now you are just setting up a gigantic strawman. What kind of configuring around have you done, that took weeks or even months? Who would even be willing to do that, without looking for help from other people, who already have configured something similar? No single thing would take that long to configure. What you may be confused with it incremental improvement. Over the life of an Emacs setup, perhaps over a time-span of 10 years or so, it may well happen, that one spends weeks configuring things. Obviously not necessarily in one long marathon, but over time tweaking things. Half an hour here and there, to make life more pleasant and move beyond lowest common denominator functionality.
I agree, that one should not spend a lot of time configuring things before getting anything done, unless one has the time. However, default Emacs already is quite capable and I could easily work with that.
It would also only take me a minute to install a theme I like and perhaps magit. The return of time investment for magit is enormous, since I already know it, so I would install it right away. Hitting some M-x package-install RET magit RET takes less than a minute and makes every git interaction I am likely to need much faster.
The thing is, that with Emacs one gets things which one does not get in VSCode at all, no matter how long you configure VSCode. I personally expect more from my tooling and that is my choice. Who are you to decide what functionality I am to expect out of the box and what I am to not expect at all?
Honestly speaking the only real use case of vim/emacs style keyboard heavy editors I can see(having been a user for years) over vscode is use of keyboard macros. Which in modern context is rare enough to make a one off sacrifice.
But otherwise the only real use case for vi(m) is I see is server side editing, and its still the best tool out there for such tasks.
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].
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?
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.
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.
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.
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.
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.
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
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.
That is an excellent observation. There is something special about living inside the same, consistent environment. You can reach productivity peaks that are impossible to achieve with an heterogeneous collection of tools.
It would help if you explain more what "accessible" means. What about it was a problem or left you dissatisfied.
BTW, the System Crafters Youtube channel has pretty good Emacs stuff - including for those with little experience. Although I've used Emacs for over a decade, I learned about fairly helpful packages via that channel.
I was an avid user and it's amazing how it's able to port abstractions between its various modes. For example, you can use an auto complete plugin that replaces text with regexes to rename a batch of files.
But nowadays I tend to prefer technologies that work reasonably well with a set of sane defaults. Emacs works really well when you are working on really hard problems and programming fringe things from scratch, but it pales in comparison to the productivity of simple no code tools that's been flourishing recently.
That's the experience for the kind of work I've been doing recently, which are mostly CRUD apps to support a business. It might not be true in other domains.
The key with Emacs is that it's an editor that grows: the close mapping between the editor and its code makes it more fluid and natural to extend than any other popular tool I've tried. It's a fuzzy distinction—not something you can put on a feature checklist—but it's made working with Emacs qualitatively different from working with other tools. While Emacs has certainly influenced other editors, none of the ones I'm familiar with have carried over this core philosophy.
That's my point. How did emacs influence this? Emacs is nothing like that. If anything, emacs has failed. Everything else is either proprietary or company/plugin based. And mouse based.
Imagine spending 8 hours a day for the rest of your life and you still want a cursor based popup telling you what you might or might not want to do instead of having muscle memory of what you do.
> Emacs had a GUI and mouse support forever on Windows.
Emacs did not invent the mouse cursor interface.
> It was “bloated and slow”.
This comes from not understanding how emacs works. Yes, it has games, no, it is not loaded until you load it. It means nothing, it does not mean bloat.
> I think we’re just missing each other here. The best features of eMacs spread to other editors.
I think we might - it's Emacs not eMacs.
> As for the scenario, I don’t see that as a hellish situation. I’ve been using vim for a while. Im actually ok at it.
Great! I love vim. In fact I used it for 15 years before switching. I would not be using emacs as my everything if evil-mode was not a thing.
> Do I regret learning it? Hell yeah. Lol. But at least I got vim mode to soothe the wound a little
Sometimes I think the same thing.. Everytime there is no vi mode I get annoyed. I try to be open to new software, but cua-mode (or default emacs keys) is not it for me.
I get your first point. I’m saying it was the most popular so that’s why it’s ideas spread. I’m only thinking of eMacs and Vim cus the editor wars were so big.
In the 2nd point, I’m just saying what the popular complaints were. I wasn’t trying to prove them either way. Just what the battles were about. I wasn’t there so I’m thinking like an archeologist here.
I know about the misspelling of eMacs but I’m on my phone. I don’t mean anything with it. Just too lazy to fix it.
There’s good stuff in Vim and I like it but yeah not gonna die and say “well! Glad I learned vim!”.
Live and learn. I’m still thinking what band Vim would be
This is a tough question to try to answer! I guess I'll cheat by asking one of my own: Can you characterize what about Emacs has put you off?
It took me a few tries too, back in the late noughties, before I finally found it "clicking" with me. I have a pretty good sense of what made that possible, but no idea if your experience is at all similar, so I hesitate to suggest anything in advance of getting a better sense of what I'm suggesting about.
I think it's the single tool for many uses thing. It's somehow more satisfying for some chef's to use, love, and care for a single knife to do everything in the kitchen than to buy 100 different chopping products. Emacs is the same way for people who love to build their tool and use it for everything. If you don't feel that way you probably won't see the point which is fine.
> It’s clear to me that there’s something magical in it, but I can’t seem to tap that magic for myself.
I love Emacs for some of its really nice features that I just cannot find anywhere else (and no Elisp knowledge is required). I'm not one for tech monocultures and try to diversify my tooling as much as I can, but Emacs is seriously good when it comes to so many things:
- Magit in Emacs is arguably the best Git interface in the planet. You can run simple operations and complex workflows with just a few keypresses.
- Note-taking with org-roam (https://www.orgroam.com/). This is the best Free note-taking system that I know of — it's like Roam Research, where you can have your own zettlekasten with backlinks etc. and it scales really well with a very large number of notes (it uses a SQLite database in the background). Notes, articles with images, I use this for so many things every day.
- Encrypted notes. Emacs handles encryption elegantly out of the box. You can encrypt entire documents transparently (by adding a .gpg extension, for instance) using symmetric or asymmetric encryption, and Emacs will get your keys from gpg all automatically. You can also encrypt small sections inside a larger document.
- Spreadsheets. I do all my personal spreadsheets in Emacs' Org Mode. It never ceases to amaze me how text formats can be so powerful. Works even on my oldest computer running Emacs from a decade ago.
- Emacs Calculator. This is like a mini-WolframAlpha inside Emacs. I can solve equations, perform operations on dates, convert units, track returns on investments, simple and compound interest, the list goes on. And it integrates really well with the rest of Emacs as well.
- Org Mode. This is possibly the best designed markup language. I take all my notes in this. You can have inline images, spreadsheets, code blocks with inline execution etc. Its support for literate programming is really awesome: it's like Jupyter Notebooks but for any language. (Emacs' Markdown support is really awesome and powerful, as well, with its previews and table handling etc)
- Gorgeous typography. I run Emacs as a GUI app at all times, and it renders all my typography (proportional or monospaced) gorgeously which makes it a delight to look at and use (Ideal Sans + Verlag for notes (org, markdown, reST etc), Cascadia Code for coding with programming ligatures enabled). This is all in the raw text, not just in the preview like other editors.
- Powerful macro support.
A few other miscellaneous things that come to mind:
- Powerful window management. I can split panes vertically, horizontally, and undo and redo my window layout, all out of the box. This makes working with multiple files a breeze, especially when you have to look at some of them at the same time, and/or move to different layouts on the fly.
- Navigation and text-editing at a higher level of abstraction. With Emacs, I can navigate not just in the normal ways (by lines, characters, words etc.), but in various other context-dependent ways: e.g. Emacs understands sentences, functions etc. and I can navigate, delete, select, and manipulate text at a much higher level, allowing me to work with Emacs in ways that traditional editors cannot match.
- Calendar. I use this for various things, like quickly finding out when sunset is. It can also tell you phases of the moon etc. if you need that, all out of the box.
- Email using mu4e. Emacs can work as a beautiful mail client. I used to use this several years ago with mbsync (isync). It's surprising how offline email can let you search through all your emails literally instantly.
And there's so much more depending on what you're looking for :)
Emacs is like this retro piece of software that is paradoxically highly modern at the same time and actually better than the status quo. (It's snowing outside now. Let me go ahead and run M-x fireplace in my Emacs ;)
I feel you and you are not the only one. For me it was the time sink every time I wanted emacs to do something different, it was fun for a while (3 years) but now I want to spend my time elsewhere. Also Elisp kinda sucks.
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
and
65 time rsync
The majority (when using a browser) is "not secure". That seems unnecessary, and in this day and age, unwise.
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.
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.
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.
> 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!
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.
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?
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.
I love that eglot is being incorporated into emacs, though I myself use lsp-mode. Does anybody know how advanced eglot is? As far as I hear, it doesn't support multiple language servers which seems like a showstopper for web dev these days, e.g. I usually have ts lang server + tailwind lang server running at the same time when doing web dev.
As far as out-of-the-box support, I think it works great. Much easier to configure than lsp-mode.
However, for my uses with a Ruby/React+TSX setup the performance was lacking on a large codebase. I swapped back to lsp-mode and the experience felt smoother.
IIRC the author's stance on previous discussions around multiple language servers was to rely on flymake instead, since the previous discussion centered around ESLint + TypeScript. Tailwind is a bit of an issue in the ecosystem right now, but you may want to try https://github.com/merrickluo/lsp-tailwindcss.
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 / Emacs native compilation branch / native JSON parsing).
Apparently LSP-bridge is even faster so I may try it but if "Emacs completely locks up" when you hit a key due to lsp-mode, there's an issue (and a solution).
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.
Oh I see, I build from source but I’ve been using the same configure options forever (just native comp and rename the ctags binary). I’ll look them over again.
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 manage lsp. Perhaps Elisp isn’t the right tool for that backend processing.
This is a bit strange. I have Company setup to do the same thing and use it with Rust Analyzer and I have not experienced any stuttering at all!
I read down a bit and it seems like someone has mentioned building with "--with json", and this should be what makes the biggest difference here I think! The only thing I can think is that, maybe you didn't have libjansson installed while building Emacs, or it can't find it for some reason. It also needs to be available at runtime!
You can test to see if libjannson parsing is available by running '(json-available-p)' inside Emacs, in IELM for example.
Do you even get no stuttering with company-minimum-prefix-length set to 1 and company-idle-delay 0? I tried building --with-json, and `(json-available-p)` returns `t`, but it's still super stuttery.
I have the exact same settings on those specific variables. I do not experience any stuttering at all.
I am on a pretty powerful system though, I have a Ryzen 3900x and 32GB RAM which may be why I am not effected by this. I also have the garbage collection settings tweaked a bit. I am on version 29 for comparison.
In my experience it depends a bit on the LSP server itself (as well as it just being horribly slow in Emacs 27 and older). Omnisharp is for instance way slower than clangd and rust-analyzer. Also helps to make sure all the various mingw dependencies are there if you use Windows (json and native compile in particular). If you used LSP-mode it would be worth checking out if you can disable some of the information it renders to improve performance in general.
Other than that, Company can be a bit slow compared to Corfu, which is a bit more lightweight completion framework, built more around the emacs internals.
When I wrote that comment, in the depths of my soul, I knew someone would give a solution that needs me to invest more time in figuring out how to incorporate it into my oversized configuration.
But seriously, thank you, that is the performance I was looking for.
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.
If you are familiar with python I totally believe that. I find LSP to be the most useful in languages that I rarely use, of which Python is one. That way I can constantly, immediately and instantly see that I am doing it wrong.
For example I use https://github.com/ergoemacs/ergoemacs-mode, with some commands that I have acquired as muscle memory from using Emacs/mg for long. And still I use nano when I need to do small edits to a file. I also do it almost without thinking about it, especially when doing "sudo nano whatever". Mg should be better for me, but nano is engraved into my palms for some reason.
Unrelated, but to anyone from Google. When I search for "emacs" and your product pops up a line saying "Did you mean Vi?" it really makes me want to quit using your search product. Your search is not best in breed anymore, so cute gimmicks like this are a flat turnoff.
It all makes sense. Google is playing the editor factions against each other so they won't contest the Chrome-based Electron editors that prop up their monopoly.
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?
I'm building from source because I want the latest features and bug fixes. It's really not that complicated. On Ubuntu, the following builds and installs Emacs into your home directory:
Building from source. I have a bunch of patches in the lread.c to make Clojure-style #f(+ % 1) lambdas work, so I don't have much of a choice. Recently (this year), the reader was rewritten to be non-recursive, so I had to modify my patches too. Other than that, dnf builddep emacs && ./configure && make generally work well. It's worth looking at config options, some interesting things are still disabled by default (last I checked, modules, threads, and xwidgets; though it might have changed in 29).
I'm on Windows but use WSL exclusively. It opens the frame seamlessly. I'm about to build 29 from source because my Ubuntu ppa doesn't have a prepackaged 29 build.
I personally believe it's a good thing for a developer to have an intimate relationship with the construction of their primary tooling. It feels right to me, even if it hurts adoption.
Mostly, probably. There's a ppa for Ubuntu and a copr for Fedora; I wouldn't be surprised if other distributions had 3rd party emacs-snapshot repositories, too.
I use web-mode + typescript-language-server for React+TSX. Whether or not you choose to use eglot or lsp-mode, I'd still recommend following the lsp-mode performance guide: https://emacs-lsp.github.io/lsp-mode/page/performance/. Those tips are useful for all setups.
I'd like to try it, but I'm worried it won't have the same quality of code completion suggestions, and I'm also concerned that some huge files might be slow to work with.
- 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.