Emacs 29 is nigh
blog.phundrak.com
blog.phundrak.com
- 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.
That being said there is a bit of a learning curve.
It's great for any application where you use keyboard shortcuts.
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?
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.
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.
And yes you can run the client using the gui emacs not only terminal emacs.
I assume that's what he is talking about.
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?
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’ve recently been getting into Emacs again and have a pretty good setup already, so I’ll have to try TRAMP again.
Try using more "core" libraries like flymake that accounted for (or seem to) tramp from the start.
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.
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)
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.
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!
I use prettier-mode and editorconfig-mode. Everything is formatted on save so works well for me.
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?
> 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:
> Neovim (plugin): https://github.com/akinsho/toggleterm.nvim
> VS Code (built-in): https://code.visualstudio.com/docs/terminal/basics#_managing...
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":
https://www.masteringemacs.org/article/keyboard-macros-are-m...
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:
https://www.masteringemacs.org/book#free-sample
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.
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.
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.
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.
EDIT: try `g` for "refresh"/recompile.
Maybe that's just me though, not sure this is an official method.
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.
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.
vterm is awesome, I recommend using multi-vterm if you want more than one
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 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.
Or maybe I am just more attentive to the coverage now?
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.
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.
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.
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 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...
In case you're considering a career in software, no, the feeling of groping around in the dark never disappears.
Nice one.
http://www.threepanelsoul.com/comic/i-think-so
Also:
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?
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.
Among the big list of features missing in Emacs as of now is remote development that way its done is vscode.
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.
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.
Where is this, if you don't mind my asking?
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)
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.
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...
FINALLYYYYYYY!
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.)
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...
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.
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.
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.
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.
Semaphores are not there, my mistake; I was thinking about: https://www.gnu.org/software/emacs/manual/html_node/elisp/Co...
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 :)
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.
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.
> 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
It's well documented and supported, I highly recommend it!
> 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.
There are plans to split doom-emacs' core and contrib modules in separate modules, but no idea what the progress is on that.
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).
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.
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.
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!
pixel-scroll-precion-mode You can configure a custom refresh rate.
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.
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.
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.
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.
> 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.
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.
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.
Last paragraph though I do not agree with at all.
I haven't made a config change in months. And the last few were all just new convenience shortcuts.
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.
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.
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.
I'm surprised the difference is that much though!
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.
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.
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.
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.
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?
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.
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.
There are several GUIs for Neovim for various platforms [1].
[1]: https://github.com/neovim/neovim/wiki/Related-projects#gui
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.
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?
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.
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...
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-...
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.
https://easyorgmode.com/blog/how-i-use-org-mode-to-keep-trac...
People are always going to love it. But I think all the best ideas from that era have been taken.
I like Vim but EMacs won the editor wars
The real split was whether people wanted an editor to work like an IDE or not. Everyone did. Even Vim.
I think it makes more sense they are there for those of us who know Vim but one day we’ll all die out
Emacs is a platform centered around text.
It's hard to imagine a definition of "win" that goes from roughly 50% popularity to less than 5%.
Eh.. Which every other editor would that be?
There is a mode [0] you can enable just because of how different it is to every other popular editor ever. Still.
What we want to do is list features. For example, people prefer the GUI and the mouse, non-modal, batteries included.
It’s not a bad thing. It’s just been a while. Those editors were written for a time that don’t exist anymore.
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.
Yeah the free software stuff didn’t work but that’s not all the editor wars were about.
I think we’re just missing each other here. The best features of eMacs spread to other editors.
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.
Do I regret learning it? Hell yeah. Lol. But at least I got vim mode to soothe the wound a little
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.
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
I don’t think EMacs or Vim will come back. They have revivals, I came in during one of those. This is definitely one of them.
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.
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!
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'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
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 ;)
That's great news!
I'm excited for this. May there be a nice database CRUD mode in the future.
I'll have to try it.
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...
17 times ftp
74 times http
71 times https
65 time rsync
If downloading a file manually, the download pages also tend to recommend you follow provided instructions for doing this yourself.
> 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!
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.
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.
But seriously, thank you, that is the performance I was looking for.
Although I mostly use Emacs for my Python work, I still would use other IDEs for C++ work.
Just because you can't easily get it to be great at one thing (lsp) doesn't mean it needs to be abandoned for everything else.
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 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.
https://reddit.com/r/emacs/comments/ymrkyn/async_nonblocking...
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.
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.
Maybe some of this information will help!
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.
XEmacs has long been obsolete, so anyone finding old references to it & searching it out is almost certainly helped by being redirected to GNU Emacs.
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.
sudo apt-get install build-essential
sudo apt-get install libgtk-3-dev libtiff5-dev libgif-dev libjpeg-dev libpng-dev libxpm-dev libncurses-dev libgccjit-11-dev libgnutls28-dev texinfo
git clone https://git.savannah.gnu.org/git/emacs.git
cd emacs
./autogen.sh
./configure --with-native-compilation --with-cairo --prefix=$HOME/usr
make -j 4
# testing:
./src/emacs -Q
make install
git pull
make clean
./autogen.sh
./configure --with-native-compilation --with-cairo --prefix=/home/malsburg/usr
make -j 4
# testing:
./src/emacs -Q
make installOn a tangent anyone knows a good LSP setup or LSP server for Javascript?
(use-package web-mode
:ensure t
:mode (("\\.ts\\'" . web-mode)
("\\.js\\'" . web-mode)
("\\.mjs\\'" . web-mode)
("\\.tsx\\'" . web-mode)
("\\.jsx\\'" . web-mode))
:config
(setq web-mode-content-types-alist
'(("jsx" . "\\.js[x]?\\'"))))
(use-package eglot
:ensure t
:hook (web-mode . eglot-ensure))C-h q (translated: Ctrl+h )
Is Emacs a viable Java editor?
wake me up for Emacs 42