Emacs for Professionals | Hacker News Reader

Emacs for Professionals

tilde.town

241 pointssigna11109 comments

A bit off-topic, but probably interesting to folks reading these threads: A quarter-century ago I worked at a little company that made networking ASICs. The guy who did "floorplanning" and layout had his own tool flow based on a set of scripts he had written over the years. Those scripts were written in Emacs Lisp.

I don't know why he picked this approach, although I suspect that he started out with a manual process on much smaller chips and then started automating it. Anyway, I had to compile a 64-bit version of Emacs to run on his 64-bit SPARC machine (back when its 6GB was enormous) so that it would work with our designs. (back then Emacs only used MSBs for its tagged pointers, so 32-bit Emacs could only address half a GB)

I've seen Emacs used for some pretty weird things, but so far this one takes the prize.

Haha Emacs is truly an OS, lacking only a decent text editor /jk

It has viper-mode

evil replaced viper many years ago

These days a lot of us essentially use vi in emacs so this is just not true anymore.

I used "Dired" to view text files and move around directories all the time in emacs. Replaced "mc" (midnight commander) for me. Partly because were I'm at MC takes about 30 seconds to start. you can M-x shell and get a shell in emacs, but that's overkill... but it would be searchable....

emacs even has games.. M-x tetris.

I'm starting to think you might be right about it being an OS.

Emacs has have more than 300 games, I believe. You can find a large deal of them on https://emacs.zeef.com/

I like German air-traffic-control story better (probably because the author added the linguistic spice in it :)):

https://teddit.net/r/emacs/comments/lly7po/do_you_use_emacs_...

Using emacs AND vim isn't some mutually exclusive impossible thing.

There's lots of nice features in emacs. Look at it as a suite of tools (applications) that has an editor-like interface; debugging, email, even spreadsheet calculations - you can totally still edit files with vim and find emacs really useful.

For instance, you want a really powerful calculator? https://www.gnu.org/software/emacs/manual/html_mono/calc.htm... try that out

Try giving the "Grand Unified Debugger" a spin as well. The ease of Visual studio debugging is one of the only things I miss from Windows dev and GUD really comes close. I use vim as my daily editor but fire up GUD frequently for stepping through code.

Don't view the tools as mutually exclusive.

I used vim for over 25 years before switching to Emacs, so I'm perfectly capable of using both, and do use both.. but for me Emacs does virtually every that vim does and more, while vim only does a couple of things that I need that Emacs can't, and I find myself needing vim pretty rarely.

Do you use some sort of extension or plugin to get Emacs to use modal editing and the home row like vim? Or did you switch over to the Emacs key bindings?

I use Evil to get modal editing, and have spent countless hours configuring Emacs to be as vim-like as possible. As a result I can easily switch between vim and Emacs and feel completely comfortable editing in both.

I'd love to switch, but have spent a significant portion of the last four months moving all my personal infra to NixOS. Will need to take a break and spend more time with the kids before diving into something like this again haha

When and if you do, be sure to check out the emacs-overlay! It makes it super easy to build/install development versions of emacs, to compile with native-comp, and so on

Professor Moriarty, a couple of questions:

Is this switch because you've moved on to LISPs?

Doesn't startup time and lag of emacs (compared to vim) bother you?

The startup time of Emacs is not an issue because I only start the Emacs server once and keep it running for a long time, connecting the Emacs client to it as needed. Once the Emacs server is running then connecting to it is as fast or faster than starting vim from scratch. Even restarting Emacs from scratch can be effectively instant, if you don't have a giant config like I do. Vim startup time can be slow too, by the way, if you have a lot of plugins. So, effectively, vim and Emacs don't differ on startup time these days like they used to.

As to your question about Lisp, it definitely was a huge draw to Emacs because I fell in love with Lisp and almost the entire ecosystem of Emacs is written in Lisp... and I'd certainly much rather program in Lisp than vimscript, or even Python (or any of the other more mainstream languages).

I remember coming across various things I wanted to do in vim that were pretty awkward to do because of how clunky vim and vimscript were. Lisp and Emacs just made doing what I needed much easier overall (though some things were still easier in vim.. for example, vim has some powerful features in its regex engine that don't exist in Emacs, even when using Evil). This was before neovim, so maybe it's better there, though since both vim and neovim lack Emacs' Lisp ecosystem, I doubt they'll ever be able to match Emacs in this respect.

There were a lot of other reasons for the switch to Emacs, like having deep web browser and shell integration, being able to read my email from within Emacs, and do a ton of other things from it.. org-mode was another draw.

While you were using vim, did you use tilling window managers? Did you use a dmenu-driven workflow that calls bash scripts and unix utilities?

When people talk about "composability" and "integration" of EMACS, it strikes to me that, vim+i3+unix setup is essentially the same. Just instead of LISP, bash/python is the glue language.

But why use so many monolithic tools that don’t want to talk to each other? Why ‘glue’ stuff together? Shouldn’t the underlying system take care of that? That is the appeal of emacs, to me. I don’t have to work hard for uniformity. I implement something once (a theme change, for instance) and it’s reflected everywhere. I want to change the font in emacs? Easy, one line in my config. I want to change the font for all of my programs on my Unix system… far out.

Yeah, but when everything lives inside the same Lisp environment, there is no need for glue. You have variables and functions, all with built in documentation, that are easily composed.

Vim, on the other hand, appears to conspire against the user's attempts to build reusable configurations. One plugin may require Neovim. Another may require the Python runtime to be configured and installed. Vanishingly few of them have built in keybinds, and those that do are not guaranteed to be harmonious with other plugins. And besides, should I write my config in vimscript or Lua?

It might sound like I'm picking nits, but I don't find it coincidental that the best configurations that people have managed to build have been upon the strong bones that Emacs provides. Doom Emacs (https://github.com/doomemacs/doomemacs) is best-in-class, providing harmony between all of the built in modules and their bindings. I uncomment a line in a config file and get full Python support, with refactoring and formatting and such, ootb. This ends up being true for a shockingly long list of languages and tools.

On the Vim side you have https://github.com/NvChad/NvChad which appears to no longer be accepting new plugins and https://github.com/LunarVim/LunarVim which appears to provide a really good programming experience but is limited in scope to a handful of core plugins and whichever LSP servers they can get their hands on.

I used to use Neovim and compose everything together by hand as well. I don't see why I should bother today when Doom Emacs provides the same experience I would have built for myself, out of the box.

The start up time of emacs isn't slow if you know what you're doing. I have a 14,000 line init.el and about 355,000 lines of code across ~150 installed packages. Emacs starts in 0.2-0.3 seconds. Not instant but practically there's no difference.

The downside of autoloading (lazy loading) all libraries is that there's a hitch when I first open a "heavy" elisp library. A PDF, an org mode document or something that launches an LSP server, say. But if I launch emacs to edit a bash script or a config file the speed is indistinguishable from vim.

Agreed, and use-package is a big reason for this. New users, take heed and use-package from the start. Regarding the topic of using both Vim and Emacs, I do, but switching from one to the other can really mess me up. I would prefer to just use one, generally, and use TRAMP instead of Vim when possible for editing server configs and such. I have considered using EVIL mode, but I am wary of losing touch with default Emacs, as it's something that comes up from time to time as well.

Worth noting that you can replace evil-mode's insert-state with its emacs-state, thereby getting conventional Emacs keybindings when you're typing.

That's how I have it configured.

"I have considered using EVIL mode, but I am wary of losing touch with default Emacs, as it's something that comes up from time to time as well"

You're basically giving up almost everything that makes Emacs great: its ecosystem. Bare-bones, default, vanilla Emacs, without any packages or configuration is woefully underpowered compared to Emacs or vim with lots of packages and configuration. I hate to use either in their default states, and would have never switched to Emacs if I wasn't able to use Evil.

Oh, I'm not at all saying I use default Emacs, I'm just saying that I'm concerned that Evil would change it so drastically that I would forget how to use default Emacs. Default in this case meaning "not evil".

In those rare situations where I need to edit a file on a machine that doesn't have Emacs+Evil, I just use vim or vi... which even when unconfigured are good enough to make small edits without much pain.

So I get the best of both worlds: Emacs+Evil 99% of the time, and vim/vi 1% of the time when Emacs+Evil is not available.

Try Doom Emacs (either to use it long term or to steal its approach).

Starts in under one second for me.

Professor, is it true that Holmes is a Notepad++ user?

More of a hardware user. Hard drugs, hard thought.

It's funny Arthur Conan Doyle says Sherlock Holmes is based on I think two guys, but there's a third guy he's also based on Conan Doyle didn't talk about, and that was the guy who cracked cases the hardest, just never talked about because of he was the one the whole coke-injection trances was based on (which was legal at the time). Protected his privacy, you understand.

Kind of like Paul Erdos.

I'm one of those weird users who works in both, and I've also never really understood the need to pick a side. I initially used emacs for years, and now I've used both for years. I also don't pick a side in the tea and coffee debate, sometimes I want rooibos and others espresso.

Admittedly, my emacs usage at this point is largely to treat it as a collection of distinct apps; fire up in nov-mode¹ mode to read books, fire up in magit-status² to mangle git repository, etc. It really feels like there are a collection of best of breed apps that just happen to built on emacs as a toolkit, most of which are fully functional without buying in to emacs for life(not that I'm saying there is anything wrong with that).

The only time I really use emacs as an actual editing tool is when I'm working on documentation, and that is largely because I like being able to see inline screenshots in that instance. That could equally flip again should I see some feature I want.

¹ https://github.com/wasamasa/nov.el

² https://magit.vc/

I reget I have but one upvote to give you.

I use different editors for different things and I could not agree with this sentiment more. I use Emacs almost exclusively for note taking and for writing software. But I use vim for editing config files, or for smallish files in /etc/. I really like Emacs for writing software, but I have used vim for this as well.

Over the years I've used many different editors and I expect I will use many different editors in the future.

I use both, a lot, too. They both have their places.

I'm using vi/vim whenever I shell onto a machine; I typically use ripgrep to search a huge codebase for the file I'm looking for and then typically open that single file in VIM. (I read more code than I write these days).

I use Emacs (Doom) more for Org-Mode and note taking, and sometimes as client for accessing APIs (through verb package). I'd like to get my SQL for the various types of databases I connect to to go through emacs. But once the connection history is in my bash history, and how easy it is to press ctrl-x ctrl-e to edit the command (in VIM), it hasn't been painful enough to put the time in.

And ironically, I use neither for my main code editor.

I think emacs is among the first "app" environments.

I'm more productive building a little tool in emacs than just in the shell, or something web, desktop or mobile based.

There's a few reasons, the amount of useful things instantly available (and discoverable) is incredible, being the main one.

If I specifically want to make something for others... Unless they're emacs users I'm going to use another platform, obviously.

I've spent a little time wondering if it is acceptable to push emacs as a runtime lately. For example, I've convinced a few co-workers to use magit, and they're comfortable with it when using a shell wrapper to start emacs and call magit-status.

Honestly, I'm kinda convinced that if there was a more locked down "kiosk mode" that didn't let you use the other functionality it could be a good runtime for generic apps.

I use vim for quick and fast terminal editing: little shell scripts, config files, commit messages. Emacs for anything serious.

Agreed, anyone who brings up the culture war between Emacs and Vim users is acting as an agent of discord. I love and appreciate Vim users and love and appreciate Emacs users. I "use" both thanks to evil, an Emacs package that brings vim emulation to Emacs.

Evil Emacs is a better Vi them Vim IMO.

Although NeoVim is pretty special.

I crack open Emacs for Steel Bank Common Lisp. But Neovim for everything else. They are pushing the boundaries of Vim like no other with Treesitter, LSP etc.

Saw this posted on emacs-news [1] asking for some feedback.

A thought I had about using dired as front-end to everything is that once you get more than 20 buffers open its unwieldy to find things. Working on several projects at once using the standard C-x b navigation or even Helm bindings seems to take too long.

That's why I still use a window manager that has workspaces with their own key (rebound alt-gr) and several copies of emacs and term emulators open.

Does anybody have positive things to say about something like "buffer groups" for emacs? Projectile or iBuffer. They're mentioned here [2] but alas I never had much joy with them.

[1] https://sachachua.com/

[2] https://stackoverflow.com/questions/9972523/emacs-buffer-gro...

I have the buffer listing mapped to a key, and next/previous buffer to alt tab/alt+shift+tab, I’m happy with this setup personally, and I regularly have multiple projects open.

I use Projectile extensively, to the point where it serves as the entire foundation for my workflow. I really enjoy having a set project I'm working on when I open Emacs, and when I need to multi-task I use persp-mode.

Thanks Kaze, I'll take a closer look at it again.

Another point for projectile - 3 main features:

1. Open project. Projectile uses source control files eg. .git to establish the project root, and remembers it. It's very smart about it, in my experience. No configuration required.

2. Open file in project. With the project root established, open any file that's part of the project. Notably this excludes files that are eg. ignored by .gitignore. Again, very smart behavior. If you know generally what you are looking for, you should be able to find it in a few keystrokes.

3. Grep in project. If I'm working in something that doesn't play too nice with looking up references, or generally just can't find it, this is the next best thing. It's just grep, but within the scope of your project, and a nice interactive list of files to be searched or perused at your leisure.

I also use ibuffer, but I guess you would probably have the same issues with it as with dired. Both are just emacs buffers and can be searched, etc. just as any other buffer. Mostly I use iBuffer to make sure buffers are saved and close them en masse.

Others have mentioned the awesome projectile, but I think it should be said that Emacs now has built in project.el which has come in leaps and bounds (though probably still lacks some projectile features).

I use project.el alongside consult[1] which has many convenient wrapper functions over built-in ones, like an enhanced `switch-to-buffer` with project support. I am actually using an even tighter integration called consult-project-extra[2].

The most advanced and overkill solution would probably be to use bufler.el[3] which basically allows you to define your custom logic for buffer grouping.

[1] https://github.com/minad/consult

[2] https://github.com/Qkessler/consult-project-extra

[3] https://github.com/alphapapa/bufler.el

I'd recommend checking the package "perspective", works like virtual desktops for emacs. Very good for working with multiple projects.

After years using vim and variations (vis), I decided to give Emacs another try, this time using Spacemacs.

I'm a bit surprised nobody mentioned Spacemacs (https://www.spacemacs.org) as a very good alternative for vim users that want to learn Emacs. I'm very satisfied with it, although it is slow to start, but I'm going to try Emacs server/client that I just heard about in this discussion.

Have anybody tried Spacemacs?

I think the tide has turned in favour of doom emacs, which was heavily inspired by spacemacs.

I think that's basically true, but there are still many of us using and contributing to Spacemacs. It comes with a bit more out of the box than does Doom.

I tried it, but Doom Emacs is the better alternative. Spacemacs ways too bloat and configuring it is a big pain. I think it still does everything Spacemacs capable of

> Spacemacs ways too bloat and configuring it is a big pain.

Doom is just as bloated and a pain to config.

I tried Spacemacs and was fairly happy other than the performance. Scrolling and even auto-indent were visibility slowing down my typing. It depended on the language but Rust, which is probably my most common language, was distinctly bad.

The performance lag of Spacemacs was addressed by Doom Emacs ( https://github.com/hlissner/doom-emacs ). Have you tried Doom Emacs by any chance. After syncing everything, the performance is stellar in my opinion.

3.0 has been in the works for years but doesn't look like it will ever see the light of day.

Everyone just runs develop, rolling release style. They finally switched the default branch a little while back.

Spacemacs is bloated and changes too many things (keymaps, etc) wrt to the original configuration (at least a couple years ago when I tried it). Doom emacs is the way to go if you don't want to spend time rolling your own configuration from scratch.

I tried once, but there seems to be something wrong with their download. It is just a bunch of config files without an executable. Gave up and went back to vim. People joke about not being able to exit vim, but I couldn't even start spacemacs.

> It is just a bunch of config files without an executable.

Exactly right. It's assumed that you have emacs installed separately. From the spacemacs repo...

> Spacemacs is an extension of a popular text editor called Emacs. Thus you need to first install base Emacs and then download the Spacemacs extension files with Git.

Give it another try! You might like it.

> Have anybody tried Spacemacs?

Yes.

Spacemacs is awesome. It was what allowed me to switch 100% to using Emacs.

The amount of time necessary to devote to being proficient in Emacs is significant. When you have to figure out how to re-wire Emacs and all the various extensions you want to use to use Evil (with consistent bindings) is even more.

Spacemacs allowed me to benefit from the work that others have done in these regards significantly.

However I recently switch over to Doom-Emacs. Which is very much like Spacemacs, but faster and easier to customize.

I strongly recommend that people trying out Emacs that do NOT want to give up Vi/Vim/NeoVim bindings to check out Doom-Emacs. It is the shit. It is very very good. Not nearly as quick as NeoVim, but it's worlds better then it used to be. And pretty attractive as far as text-oriented applications go.

Native Comp + Doom-Emacs + Native Wayland GTK + Nerd Fonts = Best damn operating system ever invented. So far. And it comes with a really good editor, too.

> When you have to figure out how to re-wire Emacs and all the various extensions you want to use to use Evil (with consistent bindings) is even more.

evil-collection actually makes this quite easy now. So if you want to roll your own Emacs config from scratch with vim keybindings, it's about as easy doing it with Emacs keybindings. It wasn't a thing when Spacemacs or Doom got started, though.

I wanted to use org mode hence started using eMacs. I tried the ‘vanilla emacs’ which didn’t click for me (spent time in the tutorial etc.) Then I found spacemacs (and evil mode!) and that helped (as I have some vi experience!)

I have been spending a lot of time with Dawes Wilsons ‘SystemCrafters’ YT live sessions and other vlogs - that’s an awesome source for emacs (and more) knowledge, highly recommended!!!)

So now I’m finally crawling in emacs (org for note-taking and being the main driver, and magit soon to come…)

"I eventually made a decision to learn Emacs because I knew that it follows the principles of functional programming better than ordinary shell scripting. In functional programming you have two key ingredients: functions, and a means to compose functions together to build larger functions that solve a particular problem. Without using Emacs, your functions are the Linux CLI tools, and you can compose these tools with shell pipes to solve problems. But Emacs provides better ways of composing CLI tools because it is programmed in Lisp, which is a functional programming language."

Lisp is a multi-paradigm language, which lets you program in a functional style, but doesn't force you to do so.

and the elisp code you see around does not particularly follow a functional style either.

Arguably shell pipelines feel more functional.

I think one of Emacs' design decisions was deliberately not going fully functional, but having global state and different scoping (Was it "dynamically scoped"? I always forget, which one is which.), because threading everything through all the functions would be quite complicated.

However, it may be possible to interact with Emacs using Elisp in a quite functional way.

Many early lisps had dynamic scoping only. It meant that this code would return 5

  (defvar x 1)    ; new global var 

  (defun foo () x)  ; function returns x

  (+ (let ((x 4)) (foo)) (foo)) ; => 5

It also meant that anonymous functions weren’t closures. Later on, scheme used lexical scoping and Common Lisp used lexical scoping normally with dynamic scoping for special (typically global) variables like standard-input. At the time, implementers were worried that they wouldn’t be able to do lexical scoping efficiently.

Emacs lisp only had dynamic scoping for a long time. Furthermore it had buffer-local-variables where the editor has a notion of the current buffer, buffers can have definitions of variables, and the value you get for a variable depends on what it is bound to within that buffer as well as dynamically. Over time elisp got true closures/lexical scope, first via a library and later as a language feature (if a certain buffer-local variable is set when you compile/evaluate a file, you get lexical scoping; the easy way to set it is by writing a specially formatted line in the file which allows emacs to set ‘safe’ buffer local variables on opening the file.

I knew, that Elisp got lexical scoping at some point, but do you know, whether package authors now use it often or maybe even more than dynamic scoping?

Also thanks for the practical example of when it makes a difference!

> lexical scoping [...] do you know, whether package authors now use it often or maybe even more than dynamic scoping?

All non-ancient packages use lexical scope. Most ancient packages anyone cared about were converted.

Would love to use emacs but for my use case everytime I open a relatively big json file it takes couple of sends until emacs is usable while lsp and other plugins run on it. I keep hitting these annoying lags when I can't use the tool for 1-2 seconds while something runs.

Is this something I could avoid or it's unavoidable since Emacs is single threaded?

Using Doom Emacs at the moment.

Have you tried the eglot package for LSP instead of lsp-mode?

Can toggle it on with +eglot flag for lsp module in your doom config

I was having the same issues and that solved it for me

What is your hardware? How fast is your Emacs? Ryzen 3700K here:

    time emacs -nw -Q -eval '(kill-emacs)'     <- no GUI, no config file at all

0.086s in my case (86 milliseconds) and I think that's relatively slow compare to machines others have here (5900X / 12th gen Intel / M1 macs etc.).

Then:

    time emacs -eval '(kill-emacs)'

1.4s (loading a very big custom Emacs setup).

Are you using the native-comp branch of Emacs?

Are you using a native JSON parsing lib? (not sure if it helps to open JSON files themselves but it speeds up LSP greatly, for LSP uses JSON files).

> Is this something I could avoid or it's unavoidable since Emacs is single threaded?

I don't know about gigantic JSON files but that's very weird to me: I can start working on my Clojure files while LSP is starting. And LSP is definitely starting in another process that is not blocking the Emacs thread.

Emacs may use a single kernel thread but there are lots of things that are done by external processes.

I'm not saying there aren't things that can block Emacs but, in my case, although LSP is still slow to start up, it's definitely not blocking my Emacs (top, for example, shows clojure-lsp running as its own process).

I'm using Emacs since decades and it has never felt faster than nowadays: newer hardware, NVMe SSD, native-compilation branch, integration of ripgrep and fzf (two amazing helper tools that are insanely fast) through ivy/counsel (counsel-rg / counsel-fzf)...

Cherry on top: I now get the LSP servers and although it's not IntelliJ yet, it's much better than any "Emacs" I used in the past.

I do have a relatively old processor, i5-4460, but it's not THAT old, fast SSD.

I'm only using the nativecomp branch and doom-emacs starts in 1.4 seconds here too.

Someone suggested eglot instead of lsp-mode, will give that a try.

You could not load some modes if the file you're loading is large, in the somewhat extreme case fundamental-mode usually performs fine.

Large files are an eternal issue with emacs, typically I open them with 'find-file-literally' to disable the more expensive modes.

Disable lsp if you don't need it? That said, big slowdowns are also usually down to syntax highlighting. You can either disable that, or better yet switch from the old font-lock method to new tree-sitter based one. Here is a recent thread you might find useful:

https://old.reddit.com/r/emacs/comments/u4q2wl/treesitter_hi...

Reading the replies to this is very humorous when you contrast it with the usual hacker news replies whenever someone mentions VSCode, complaining about how electron is slow and buggy, when comparitvely VSCode is lightning fast compared to emacs and doesn't require intimate knowledge about emacs internals to simply open a large json file.

I always felt much more aligned with the Emacs philosophy, but it was a wrist destroyer for me (although I adopted the Caps-as-Ctrl very early too).

Nowadays I mostly stick with VSCode, with a few of packages that even remind me of Emacs for selecting and transforming text.

And for the rare case of text refactoring that doesn't fit the multicursor model, there is even a fast "Open in Vim" extension/command.

(If I still wanted to use Emacs I'd probably have spent a full-month salary on a Kinesis)

You can just use evil mode. It's pretty much feature parity with vim, if not better in many ways (elisp for extension).

> it was a wrist destroyer for me (although I adopted the Caps-as-Ctrl very early too)

Admittedly not an option for many people, but in college I switched to Dvorak. Professionally, I spent a lot of years at companies with very weak lab computer authentication (basically just one account, shared, but it was air gapped!) and didn't want to change the keyboard settings so I became good at QWERTY again. Having used emacs on both, as a consequence, I've come to the conclusion that the emacs default bindings are better on Dvorak than QWERTY. Just the placement of the keys tends to involve fewer finger and wrist contortions, IME.

What vscode packages are those? Always interested in being more efficient in transforming text.

Sure, some I use all the time, they mostly work on multiple cursors so I end up doing Vim/Emacs level stuff in (my opinion) simpler/faster ways:

- https://marketplace.visualstudio.com/items?itemName=chunsen.... (I bind to M-k M-a)

(This one enables me select, cut and type the new text - this is much faster than backspacing/selecting for me. I feel like this is a "vim pattern" that I'm reusing here)

I also have Alfred (MacOS) installed, and it saves your clipboard history. This ends up giving me sort of an Emacs-like kill ring, system wide.

- https://marketplace.visualstudio.com/items?itemName=rsbondi.... (I bind to M-k M-k)

- https://marketplace.visualstudio.com/items?itemName=janjoerk...

- https://marketplace.visualstudio.com/items?itemName=Asuka.in...

- https://marketplace.visualstudio.com/items?itemName=earshino...

- https://marketplace.visualstudio.com/items?itemName=jonsmith...

There is also https://marketplace.visualstudio.com/items?itemName=hajdaini... and https://marketplace.visualstudio.com/items?itemName=rduvql.v... that I have installed but never got to use.

I would love to record a video showing the kinds of text changes I do all the time, but the really useful happens on real life situations that one cannot record publicly.

> since all the information you need to know is in a single place, it is much easier to use than a web search engine like Google. So step #1 is learn how to use the manual page browser and search engine.

Concerning the author doesn't see the irony asserting a tool is easier to use than google search immediately before listing a dozen keyboard shortcuts to know to use it.

I think Emacs is built upon a golden idea: The programmable text buffer as the user interface for the OS.

A lot of data manipulation can be expressed as text manipulation, especially if it only has to be correct in a single instance.

However, Emacs is really starting to show its age. The keybindings are arcane and pre-standardization. There is no built-in support for multi-cursors, which are often much more direct than macro recording. Configurations are time consuming and perpetually broken. I think it's time for a replacement.

Am I the only one who doesn't get the multi-cursor hype? Having said that I never used it, so maybe I'm missing out.

You are not. Perhaps people who use it can elaborate, but it seems to be an interactive search-and-replace with highlighting. Is it anything more?

In vscode if my cursor is in a word, i Ctrl+D to select that, then Ctrl+D to select further matches, then begin typing over them. There's other modes too where you can just add more cursors to a line below/above but i find less use for that.

But in vim it's not much slower to do:

    /<search term>
    cgn  " change this this i just matched
    .    " find next occurance AND execute the change here too, i don't have to say "n ." because i used cgn above instead of something like cw

But i still end up relying on

    qq  " stick a macro in q register
    <complex edit sequence>
    @q / @@

For more gnarly stuff

presuming you did a `/<search>` for the results you want, you can follow it up with:

  :%s//<replacement>/gc

It is more like interactive editor macros where you can see the intermediate results on the fly.

The advantage over search-and-replace is that you get to work with a nice, familiar language (the interactive commands you send to your editor) rather than using regex.

Yep, to me it's not far superior to find-replace: https://nullprogram.com/blog/2017/09/07/

With the right controls it might be a better (more flexible) version of Vim's block selection mode. Which I use almost daily, it's super useful but depends on lines being vertically aligned, which multiple cursors don't need to care about.

But I don't see another purpose for them; find-replace with regex support and macros only fail in rare cases where actual syntax parsing is needed.

I used to think "surely this is just fancy find and replace".

But actually it's more like defining a keyboard macro. It's very powerful and quicker and easier than a macro for a lot of tasks.

I think the utility is proportional to the degree of repetition in your files.

Emacs is essentially perfect. The core of sketchy C is a bit of a liability but mostly works fine. The layers of lisp on top have been evolving for decades.

I don't know what standardisation you're referring to, but feel free to change the key bindings to whatever standard you prefer.

Built-in? There will be multicursor things on melpa, install whatever sounds plausible. The distinction between ships with emacs and added post-install is minimal.

I find emacs to be very transparent compared to other editors. Also, it's exactly as complicated as I want/need it to be. I love the buffer abstraction, it fits very nicely with how I think in general. And I love that it generally "just works" with my pretty bare bones config.

I don't try to do everything inside emacs, probably to a fault. I don't even bother with, say, autocomplete, or on-the-fly syntax checking (I do use syntax highlighting!), I just run linters/formatters/unit tests externally regularly while working on code. I'm happy to defer terminal interaction to a real terminal emulator, although sometimes I use vterm from emacs. Oh, I will use magit though. Magit is awesome!

Don't get me wrong, I like VSCode in some ways, and I think it's a great tool. It's far more accessible in a lot of ways. But it's not really for me. I don't find it to be transparent. Things break often, probably because it's a less mature tool, but understanding why things break when they do tends to be frustrating and fraught by comparison. And it lacks anything remotely comparable to emacs buffers (at least last I checked: if you know of anything that does this in VSCode, I'd be happy to check it out!).

And to be clear, I know these arguments for emacs aren't super compelling. They're more expressions of taste and aesthetic preferences than anything else. Which is fine, we can all have different tastes and aesthetic preferences :)

I don't really understand how to use VSCode efficiently. IntelliJ IDEA has the best editor I've tried so far. I'm not suggesting it could be a replacement for Emacs, however.

I'm OK with giving up emacs for a powerful IDE in the right setting. I've used Visual Studio with ReSharper while editing C#, and that is a pretty phenomenal experience. But for whatever reason I don't feel like I need it when working on Python, bash, Golang, SQL, JS/TS, or any of the other languages I tend to work with

> Emacs is really starting to show its age.

I disagree. I came to Emacs from a combination of VSCode/Pycharms and Jupyter notebook. I think the latter are still held in highest regard in the IDE space. To this day there is nothing in another editor or IDE that I miss. I find that Emacs allows me to invest as much as I want into my tools: editor, notebook, document generator, and shell. If you are looking for a maximal out-of-the-box product, then sure Emacs will come up short. However if you are looking for a product that you can develop and use for a lifetime then personally I don't think any one piece of software comes close

NOTE: Emacs ecosystem has had support for multiple cursors for over a decade. Emacs (like Python) should not be valued in terms of built-in features, but in terms of its community and ecosystem

what's wrong with the multiple-cursors package? I have been using it successfully for many years.

I suspect that emacs will outlast any replacements like it has done for the last few decades.

Someone posted a link in the comments pointing out that Emacs's internal representation of a buffer is not really designed to support multiple cursors efficiently. For batch changes in a large file, macros would be more suitable. I haven't really seen this be a problem in my workflow.

I use multiple-cursors and don't have a problem with it. Who cares whether it's efficient? I will prefer lsp-rename where possible, but if I'm replacing some strings or whatever it's very quick to just select the string, and then add a few cursors and change them all at once (I use s-d for that). It's not like I'm using thousands of cursors at once.

> However, Emacs is really starting to show its age. The keybindings are arcane and pre-standardization. There is no built-in support for multi-cursors, which are often much more direct than macro recording.

Why is it that I always see these complaints about Emacs and not vim? It's as true for the latter.

Anyone knows the state of GuileEmacs ? I am learning Guile and thought it would be fun to switch from Vim to an editor uses Guile under the hood but I am not sure of how usable it is

well there's a working Emacs-like in Common Lisp! https://github.com/lem-project/lem/

I believe the Nyxt project[1] is also interested in adding editing at some point[2]. If they do it will almost certainly converge to another flavor of emacs.

[1] https://nyxt.atlas.engineer/

[2] https://nyxt.atlas.engineer/article/why-building-nyxt-instea...

Any good suggetions for resources to learn Guile besides the manual?

Dired is an abomination filling up your buffer list as you traverse directories.

I use tabbar and confine dired buffers to their own group, which makes it actually useful that they stick around.

From Emacs 28 onward, set 'dired-kill-when-opening-new-dired-buffer' to 't'. It will kill the previous buffer when opening a new directory.

Abomination is not the word I would use. I also find it to be indispensable, whatever it does to my buffer list.

https://github.com/emacs-mirror/emacs/commit/5afe27624f7

This is the patch that added the feature you wanted to dired. 30 lines of diff, 20 of which is documentation.

Calling a piece of exceptional software an "abomination" because of one specific behavior that you find annoying is the wrong attitude to have, especially for an emacs user.

It is emacs. You can make it do whatever you want within a few lines of lisp.

Ok, perhaps "abomination" was excessive but, seriously, why is opening a new buffer each time you traverse a directory a sane default?

Your assumption is that the state of a dired buffer is trivial to recreate so should be thrown away. While that is the case in the simplest use case of using dired as a replacement of a bog-standard file browser, it is possible for the state of the dired buffer to be more complicated. For example, the buffer could contain marks and flags for some batch operation the user was working on before they decided to visit a subdirectory. The dired buffer may not even correspond to just one directory but may be a result of a complex find operation or may contain some arbitrary set of directories the user manually curated. It would certainly not be nice to the user to lose all this state accidentally.

This is why emacs takes the conservative approach and chooses not to throw away dired buffers by default and gives the users the option of choosing to do discard the current buffer consciously by using the "find-find-alternate" command (bound to "a" by default in dired-mode-map).

Reply on news.ycombinator.com