Hacker News Reader

Comment by commandlinefan | Hacker News Reader

I've been a hardcore vi user pretty much my entire life, but I decided to force myself to spend a year using emacs a while back just to see what all the fuss was about. When the year was over and I "allowed" myself to return to vi, it was like a huge weight lifted off my shoulders... to this day I still don't see what the hype was about. On the plus side, though, I memorized the emacs cursor movement commands, which are (for some reason) the default cursor movement commands in most command line environments like the Postgres CLI.

View on HN

I had a similar experience, but came to the opposite conclusion. I walked away replacing vim with emacs as my daily driver. Elisp is far more extensible than vimscript and evil-mode is pretty much at 1-1 feature parity with the real vim. I don't care much for the emacs movement keybindings except for the readline movement commands.

> to this day I still don't see what the hype was about.

Most of vim is written in C with some interfaces exposed for scripting. Emacs is mostly written in elisp with some C code where necessary. The latter lends itself better to 'hackability' imo

For my own machines, I build emacs and import my saved init.el

On other machines, there is usually a standard vi/vim install that I can use if I am ssh'd in somewhere where I don't have my personalized copy of emacs. If I remember, I'll try to put these five lines[1] in the .vimrc for some saner defaults

[1] https://news.ycombinator.com/item?id=25410390

Why don't you SSH _from_ Emacs?

If you are editing a remote file there's usually no need to SSH and then invoke an editor.

https://willschenk.com/howto/2020/tramp_tricks/

I used to, and I probably would if I had to work with remote files more often. But in my experience I found it faster to just build emacs on the remote server and run it as a daemon there, since all the machines I was working on remotely had /home on an NFS mount. TRAMP took just a little too long to load remote directories for my liking.

But in case I am plopped in front of an unknown terminal/have to do something on someone else's machine ... at least I can rely on using the default vim to do basic editing.

Does that mean you have a nice setup for running emacs as a server on a remote machine and connecting via a local client? I've tried this a couple of times but it seems to be prohibitively awkward and I'm stuck with the idiosyncrasies of Tramp or even just saying in a vterm. I'd be very grateful if you (or anyone else) can explain how to do this.

I just run emacs on the remote server (inside tmux), emacs works great on the terminal, in fact, I don't use GUI emacs. code, orgmode, magit are just text.

Yeah, this is how I do it. If it's a reasonably modern remote image you even get color highlighting. And in a way, it lets me segregate, "on this host, I'm working on this project, on this host I'm on this project, all the state/context is there when I re-activate my tmux ready to see what's up.

If I'm writing a lot of code or doing a refactor needing more thought, I'll do it locally, to be sure.

I even started baking emacs into docker images we use for running debugging tools in kubernetes environments. Can quickly edit and run little scripts to do admin and operations and debugging tasks.

You can also use docker-tramp to enter locally running containers and do quick edits without worrying about installing an editor. It can be suprisingly useful.

Remember when there was an embedded web browser in emacs? https://www.emacswiki.org/emacs?action=browse;oldid=EmacsWeb...

Is there a preferred way to do the equivalent of xref_find_definitions when using tramp?

Vimscript is a pain but these days you can use Neovim which supports Lua as a replacement. I’d recommend checking out what Neovim has to offer. ThePrimeagen has a great video on setting up Neovim as an IDE from scratch.

https://m.youtube.com/watch?v=w7i4amO_zaE

I mean it's a matter of preference, I personally find vimscript a lot more readable for vim configuration. Maybe not for more advanced stuff, I don't know, but how is the following:

vim.keymap.set("n", "K", vim.lsp.buf.hover, { buffer = buffnr, desc = "vim.lsp.buf.hover" })

vim.api.nvim_buf_set_keymap(bufnr, "n", "K", "<cmd>lua vim.lsp.buf.hover()<CR>")

better than

nmap K :lua vim.lsp.buf.hover()<CR>

It's like the javafication of vim configuration.

While I wholeheartedly agree, you don't have to sprinkle Lua everywhere, you can use both. As a matter of fact, I do[0]. And when I want to enable a setting on the fly in the editor, I still use the vimscript version. But Lua is way nicer to work with the moment you do something non trivial. For example, I've never been able to make sense out of vimscript string interpolation.

0: https://github.com/RMPR/dotfiles/blob/master/.config/nvim/in...

Thank you. Been a vi (not vim, vi) user for decades for editing files in /etc.

Tried using vim, neovim, Emacs, mg, etc a month ago and quickly went back to pycharm which hogs resources on my ancient computer.

Have been looking for a "how-to" on various editors. This video seems to be it for neovim.

Offtopic: I'll pay you in blood for configs for fvwm

Neovim supports Lua and Fennel (a Lisp atop Lua) https://fennel-lang.org/ https://github.com/Olical/aniseed

When I was at the university and started programming on UNIX, the professor said we should try both emacs and vi and see which we like better, and provided links to some tutorials.

I tried them both and liked vi. Emacs seemed slower. In my undergraduate wisdom, I deemed emacs to be "stupid" and went on with my life using vi.

After I had been programming professionally for about ten years, I decided that my harsh judgement as an undergraduate was often incorrect. (I had also deemed Voltaire, Spanish, sociology, microeconomics and many other things as "stupid", and came to understand as an adult that they weren't.) So, I decided to give emacs another chance.

My conclusion was this: vi is better for touch typists. Your fingers are almost always on the home row. Emacs wants you to hit the meta/alt key a lot, which is difficult for a touch typist. It's much harder than hitting shift. Vi makes you hit escape, but that only happens when you switch modes and it's not that hard to hit.

I noticed that lots of skilled and professional engineers never learned to touch type. That discovery itself was odd to me: why would a professional programmer not want to invest the time to learn to type properly: typing fast boosts your productivity significantly. But they do. And my conclusion was that emacs was for them, because hitting the control/alt key isn't as much of a penalty when you're a hunt-and-peck typist.

> My conclusion was this: vi is better for touch typists. Your fingers are almost on the home row. Emacs wants you to hit the meta/alt key a lot, which is difficult for a touch typist. It's much harder than hitting shift. Vi makes you hit escape, but that only happens when you switch modes and it's not that hard to hit.

I had been playing rogue and nethack for a bit when I started programming. The keys hjkl for doing movement was a natural transition to a vt-100 terminal for writing code in vi.

I had also been coding in LPMuds for a bit and the ed command set was firmly engrained in my mind. With vi being both "move using rogue keys" and "do the fancy stuff with the ed commands" there wasn't even a second thought spent on considering emacs.

Many people who use Emacs a lot make CapsLock an additional Ctrl. Using your left-hand little finger makes it trivial to use C-p, C-n, C-f, C-b as cursor keys.

I've always just used the palm of my hand. You can work a keyboard with more surfaces than just your fingertips.

Lots of vim users do that too, in fact the ADM-3A terminal vi was written on had ctrl where caps-lock is now and escape where tab is.

I never thought of making tab be alt/escape. Hmm.

ADM-3A also has

- the : key to the right of the 0 on the number row, no Shift needed.

- the Enter key to the right of the P.

I've made both changes to my keyboard layout and, not surprisingly, it's quite convenient.

Downside is, you'll have to move the original keys somewhere else. But since I already intended to totally reshuffle all the non-alpha keys for RSI reasons, it wasn't an issue for me.

I'm in the process of rearranging my keyboard due to occasional mild pain. Mind if I ask what layout you ended up with for the other keys? Any experience with the more esoteric arrangements like triggering modifiers when holding down the home row keys?

Here is my current keyd configuration (on US QWERTY hardware): https://dpaste.org/aGp3o/slim (I'm not entirely happy with it, though.)

The one thing I wanted the most was to avoid any long presses. Everything that requires holding a modifier, even if I do it touch-typing style, with the opposite hand, is unpleasant (to me). So, besides moving most of the punctuation characters to lowercase positions, I also switched to sticky modifiers. (keyd might have some flaws wrt sticky modifiers, and they... get stuck. Not when I want them to be. I might try to go back to XKB.)

Regarding the home-row modifiers, I've only tried moving Control there. I always ended up triggering it by mistake when typing, because when you are typing fast, there is an almost unavoidable overlap in certain sequences, you press the next key before fully releasing the previous key. Some people advice practicing, other software provides various options with timeouts, it's a rabbit hole of work-arounds. So I settled with sticky modifiers.

"My conclusion was this: vi is better for touch typists. Your fingers are almost on the home row. Emacs wants you to hit the meta/alt key a lot, which is difficult for a touch typist. It's much harder than hitting shift. Vi makes you hit escape, but that only happens when you switch modes and it's not that hard to hit."

In emacs you can type exactly the same as in vi/vim if you use something like evil, doom, or spacemacs.

Unless you use a keyboard like a Dactyl Manuform that provides your thumbs with better access to such modifier keys https://github.com/abstracthat/dactyl-manuform

> why would a professional programmer not want to invest the time to learn to type properly: typing fast boosts your productivity significantly.

I have not found typing speed to correlate well with productivity. I spend quite a lot of time thinking while coding.

This is true, but from what I've seen, not being able to touch type may also be a serious impediment to written communication. Maybe not so much for email, but very much so for anything ~real time like slack/chat.

I once worked (mostly remotely) with a guy who I'm pretty sure couldn't touch type. He wrote pretty dense code and used very abbreviated class/variable/method names. But the real clue came from communicating with him via slack. It often felt like talking to someone much less intelligent than I knew him to be. His messages were so terse that I was constantly having to make a lot of guesses about what he was trying to say. Needless to say, it was not a great working relationship.

wait a second, is this why i typically send 10 messages per 1 coherent thought? i learned how to type too well?

It certainly helps to reduce latency of being able to test out your thoughts, which can be very useful for staying in a good flow state.

Of course it doesn’t help at all if you have a long build or deploy process before you can see the outcome of your changes.

That's weird, I'm a Dvorak touch typist and I find the Alt keys to be much easier to reach than Escape. To reach Escape I basically have to leave the home row, while to reach one of the Alts I simply have to bend my ring finger.

> Emacs wants you to hit the meta/alt key a lot, which is difficult for a touch typist.

hmm.... I wonder if this is the reason Mac OS uses the option key for things like 'kill word' (ctrl+backspace on other OSes or ctrl+w in vi). I have a hard time typing quickly using option/command instead of ctrl.

I also prefer vi-like keybindings.

Original Macs didn’t have a control key.

I simply rebound the keys.

> In my undergraduate wisdom, I deemed emacs to be "stupid" and went on with my life using vi.

That’s what we do when we’re younger. Judge things on the wrong basis. Or come up with weird theories on how people who prefer different things do so because they’re deficient in some way—

> Emacs wants you to hit the meta/alt key a lot, which is difficult for a touch typist.

wait what…

> And my conclusion was that emacs was for them, because hitting the control/alt key isn't as much of a penalty when you're a hunt-and-peck typist.

You see that the there are Alt and Control keys on both sides of the (American[1]) keyboard. Right? Touch typing is no harder with Control and Alt than it is with Shift.

> And my conclusion was that emacs was for them, because hitting the control/alt key isn't as much of a penalty when you're a hunt-and-peck typist.

One Year of Experience Ten Times Over: The Comment.

[1] The keyboard (ish) that these silly programs were kind of made for. The “European” keyboard has AltGr on the right side.

> I noticed that lots of skilled and professional engineers never learned to touch type. That discovery itself was odd to me: why would a professional programmer not want to invest the time to learn to type properly: typing fast boosts your productivity significantly. But they do.

This is a false dilemma. Plenty of us type quickly without hunting and pecking, or looking at the keyboard, without home-row touch typing. This comment was typed as such.

There isn't anything "proper" about home row style touch typing, it is merely one of multiple ways to type fast.

I’m a touch typist and don’t find that argument valid either for vi or emacs. And I’ve used emacs for over 30 years now and still do use vi occasionally on production servers where I’m not going to load my full emacs config just for sys admin work.

After years of vim, I started using emacs with an ergonomic keyboard on my tower. Then I tried emacs with my mbp, and it was so much worse (ergonomically) than vim. I think emacs without ergonomic keyboard is just really painful.

Not saying your choice is wrong for you, but I always map caps lock to control and that makes Emacs far more ergonomic.

Just a comment on the last point and purely opinion. Touch typing is fast and worth it if your typing like a word document. I've tried to get into touch typing, and it can be worth it, but for everyday programming, it doesn't really help me type faster. I type a few lines, stop and think about the code I've written. Programming also makes you hit a series of weird symbols most people don't. Think turbofish operator. The, probably, milliseconds touch typing saves me between writing a few lines to then contemplate just isn't a big enough speed benefit.

With that being said, I consider how I type a combination. I sort of touch type, but Im not completely glued to it. I don't worry if my hands cross as times. However, at the end of the day, if people enjoy touch typing and feel it helps them, they should! No one should swear it off just because I don't feel its that much of a performance boast for me personally.

in the same way vi users swap escape with capslock, some emacs users swap left alt with capslock

That's an interesting guess but I wouldn't necessarily agree.

I've been a touch typist as long as I can remember and have been an avid emacs user for the last 15 years. I used vim for about 2 years before switching. I do have my caps lock bound to CTRL and have ALT+(jkl;) as movement keys in emacs so that might be a sign that there is some truth to what you say.

I would guess the reason that I used vim instead of emacs at the start was the learning curve - I simply couldn't bother to learn all the emacs combinations and program in elisp whereas in vim, I could be somewhat productive without much to learn.

Once I learned emacs, it was hard to go back to anything else but I still use vim on other machines when emacs isn't available.

What all the hype is about depends on how you use emacs, what you add to it and how you configure it.

I used vi and vim for 25 years before switching to emacs, and I spent a ton of time making it very vim like.

Now my emacs can do way more than vim ever did. Things like:

- browse the web through emacs - read my email through emacs - use org-mode to take notes in outline format, with hyperlinks, tables, executable source blocks, etc - use magit, which is a great interface to git

All of these things and more are tightly integrated, so moving text/data between them and editing that data is seamless.

It's all programmed and configured in elisp, and is part of a gigantic elisp ecosystem. Though I much prefer Scheme to elisp, I like elisp far more than vimscript, python, lua, or pretty much any other non-lisp language.

Emacs has some shortcomings (like handling long lines and large files, and certain types of regex handling that vim can do better), and while I do occasionally still fire up vim, I've felt no yearning to go back to it permanently.

For me emacs does everything vim did and far, far more.

magit and org-mode are the two items that made me try emacs a few times now. Never been able to make it stick though.

> and certain types of regex handling that vim can do better

Hi, emacs user here, can you elaborate please.

See the \zs and \ze patterns in vim.

I've asked for them to be implemented in evil, but have been told it's not possible because evil just uses emacs' regex engine, which can't do this.

I think these are lookahead's in some parlance, Emacs doesn't support them. On the rare occasions I need something like that I just use capture brackets. Suppose I want to delete a contiguous string of 'a' but only if it's followed by the letter 'b', then

   a+\(b\) → \1

   aaaab
   aa

gets you

   b
   aa        <-- unchanged cos no trailing b

So it works with a simple case. I guess it could get messy if you're doing anything really complex but TBH the above is about as far as I have ever needed to go.

Good luck vimming!

A need I've had on multiple occasions is to, for example, search for the next occurance of "abcdef" but have my cursor land on the "d".

In vim that's a simple abc\zsdef

It also highlights just the "def", which is nice.

To highlight just the "de", you could use abc\zsde\zef

Yes, you could probably use some lisp magic to do the same in emacs, but it's not nearly as easy or convenient.

I guess in the next eight hours somebody will post you a snippet of elisp which will do what you want. Emacs people are very accommodating. Let's see anyway

What browser do you use? I used to use w3 but it is unsatisfactory now.

emacs-w3m

I've also tried eww, but don't like it as much.

thx i will try it

Emacs is an operating system, not an editor; I'm really not sure why Stallman constantly promoted the "emacs vs. vi" meme.

You might as well try to switch from Notepad to Linux. It's just a type error, and you'll have a bad time.

> Emacs is an operating system

Reminds me of an old joke: "Emacs would be a great OS, if only it came with a decent text editor..."

> Emacs is an operating system, not an editor

what does it take for this tired and false meme to die?

Ok, it doesnt have a kernel full of hardware drivers or an implementation that runs on bare metal. That said, it covers a lot of userland and things otherwise covered by a Desktop Environment (which are often conflated with OSes). In terms of application hosting, window management, low-level system control, etc. and the fact that some brave souls have had success with running emacs as PID 1 means that it's not a million miles away from being an OS.

(And that's without the inevitable implementation of some basic OS functions in elisp by various wizards)

> or an implementation that runs on bare metal

There's https://github.com/whily/yalo apparently

    (global-set-key (kbd "M-<tab>") #'completion-at-point-using-chatgpt)

Making a new account to post a pithy pedantic negative reply is usually a indicator of irl issues that need to be addressed. The parent is not wrong in his point that comparing vi to emacs is the proverbial apples to oranges. They are different types of tools

Why do you think it's false?

Emacs is an interactive lisp environment with at text-oriented interface. Text editing is simply another lisp program that manipulates the interface to work well for this specific task.

Emacs also has a built in email client, RSS reader, IRC client, calculator, file browser, web browser, markup language, regex DSL, Vim emulator, terminal emulator, custom elisp based shell, interactive REPL that works for several programming languages, and probably at least 200 more things that I don't even realize exist yet.

I think this makes it much more than just a text editor for sure. I don't know what you want to call it but operating system doesn't seem too far off the mark even if it's a little hyperbolic.

> Emacs also has a built in email client, RSS reader, IRC client, calculator, file browser, web browser, markup language, regex DSL, Vim emulator, terminal emulator, custom elisp based shell, interactive REPL that works for several programming languages, and probably at least 200 more things that I don't even realize exist yet.

Chrome and Firefox also have all this stuff, but I don't see people trying to conflate a web browser with an OS. See the difference between ChromeOS[0] and Chrome[1].

[0]: https://en.m.wikipedia.org/wiki/ChromeOS

[1]: https://en.m.wikipedia.org/wiki/Google_Chrome

Chrome has an elisp interpreter? Details?

Sure here's one https://www.programiz.com/python-programming/online-compiler... and I'm sure you could find hundreds of others :)

That's not In chrome friend.

Then most of these things are not in "emacs" since most of them are packages and not builtin. That was my point. Emacs is insanely customizable through packages, and can essentially run anything. Chrome and Firefox and any other web browser are also insanely customizable through "packages" which you just so happen to download as soon as you enter the URL to the "package" you want, which we really refer to as a web app. But, that doesn't make the browser an OS, and it doesn't make emacs an OS either.

One you run in emacs, the other you run on someone else's computer, I guess my expectations were mismatched.

Emacs is neither an OS nor an editor, but it’s closer to the former than the latter. It’s probably most accurate to describe it as a framework (and bundled programming language) for building custom IDEs.

I am an emacs user, but sometimes I do feel like it isn't a meme. If you could give me a linux kernel that just boots and interfaces with emacs, I am pretty sure it would cover 90-95% of my computer usage cases. Essentially emacs is an OS that just lacks a kernel. And in a way it is a compliment, Emacs is so much more capable than just as a text editor.

Not an operating system, more like a desktop environment.

A single threaded OS. I remember that sometimes I launched a slow process in emacs, and then can do nothing but wait.

I am surprised you didn’t use evil-mode to emulate the vim keybindings. Or was this a an attempt to use “pure” Emacs without packages and customization?

It sounds like they're not even aware that it was an option.

Many people don't realize that emacs' default keybindings can be changed to be modal in exactly the same as vim, by using evil.

Sorry for the naive question, but if you're changing all your bindings to vim, then why use emacs at all? Is there any extra functional difference?

Emacs is more like an ecosystem around text, so switching keybinding does not matter much. And most people's system is installed on a single computer, very much like Photoshop or Visual Studio. Vim is all about editing text and the keybinding are like a DSL for this purpose, so changing things will make you awkward everywhere.

There's a ton more to both editors than just keybindings.

See this post[1] where I talk about some of the things I've done with emacs -- none of which have anything to do with bindings.

You can do millions of other things too, as I'm not using emacs nearly to its full capacity. Same with vim.

Bindings in editors are like symbols in math. Yes, they're necessary, and you can do a lot with them, but symbols are not nearly all there is to math.

[1] - https://news.ycombinator.com/item?id=35560107

The clue lies in the fact that you can customize the editing experience to function like Vim. Because that’s one out of a thousand different ways you can customize that app to function like a one-off editor, a Git client, an email reader, and so on.

Vi is like an standard for moving around and editing text files. I use Vi-style commands in all my editors: Emacs, IntelliJ, and VSCode. For me, any application that supports Vi keybindings and has some sort of command palette will feel like home.

Regarding why edit files in Emacs instead of vim: I simply work on Emacs. I don't use a CLI or a file manager to navigate to my files, I already have projects set up in Emacs and can quickly open files in any such projects. Emacs also holds my note taking system. And when I'm dealing with git, nothing comes close to magit. Also, I've been using the Spacemacs framework for years, which makes it really easy to create such a customized and efficient configuration without much hassle.

The reason people like emacs has nothing to do with the default key bindings, which are basically arbitrary. Emacs is a framework and programming environment for building custom IDEs.

You get the vi bindings and modal behaviour which I find better _plus_ all emacs functions and most of the emacs bindings. I’m often mixing the 2 modes while editing.

> they're not even aware that it was an option

Actually in this case I was - but my goal was to use "vanilla" emacs just like I use "vanilla" vi(m). After all, if I'm using vi key bindings... why not just use vi?

Both vanilla emacs and vanilla vim are only a tiny fraction as powerful as either editor enhanced with plugins. You really missed out with this choice.

The pure text editing is just a tiny detail. I exclusively use vim keybindings inside Emacs, as many others do.

Emacs makes extending the editor a breeze. As a new user this just means that you have packages (like VS 'extensions' or IntelliJ 'plugins') for, well, everything. For a more advanced user it means you can automate away many things that are a pain in the ass to repeatedly do in your daily work.

I'd suggest you try Doom Emacs when you have a couple of free hours to get a taste of what a properly configured Emacs can do. And, once you are on it, just press "SPC f p", select 'init.el' and check what popular packages you can activate just by uncommenting a line and doing a 'doom sync'. Then press "SPC f p" and select 'config.el' to check how even "configuration" in Emacs is just elisp code. You are just running a piece of code you can edit and even debug from itself _while_ you are running it (although that'd require a bit more explanation of how it's done) . This should give you a taste of what Emacs is about.

They're the default keys because a lot of programs use the GNU readline package for line editing.

It's also possible to configure GNU readline on your system to use vi keys. See https://vim.fandom.com/wiki/Use_vi_shortcuts_in_terminal

Put this in ~/.inputrc

  set editing-mode vi
  set keymap vi-command

You'll also want `set show-mode-in-prompt on`.

Note that this feature is broken when you have a PS1 with a \n in it, in an older version of readline/bash (I am not sure which), so if you're having this problem, just upgrade your bash version.

would definitely agree. i find tmux + vim does almost everything i need. granted i don't try to script anything myself. generally there are command line tools or vim plugins that do most i want. adding to much gravy to vim also just slows vim down which can be incredibly frustrating when one is used to typing very fast.

i would say just a couple of years of vim isn't enough to really become one with the software. think it took me around 5 years to really understand why vim is amazing. took me at least one year just to get the hang of it properly and be highly productive. i can't even type in a normal editor anymore as my brain is wired to vim commands. and i still to this day learn new commands which make my life easier.

that being said i totally understand why people love emacs. but i get a decent amount of the window management stuff just using the tmux.

and vi is installed almost everywhere as an editor which makes editing in 90% of environments a breeze. even when in windows gvim does pretty good.

> the emacs cursor movement commands, which are (for some reason) the default cursor movement commands in most command line environments like the Postgres CLI.

I think this is because they're used in GNU readline. They're also defaults in all the macOS GUIs, though, so maybe not.

> GNU readline

Interesting... I always assumed that emacs was around for a while before anybody generalized a "readline" library, but I guess it makes sense that readline would have come first.

emacs definitely came first, and readline adopted emacs bindings (it also supports vi)

To each their own. Minds function differently, desire different workflows, and thus are extended better with different tools.

I use both non-evil emacs and neovim, given the mood I am feeling that day. For quick and dirty things, I prefer neovim, and for more extended workflows, I prefer emacs.

But besides functional differences, the two "mediums" feel different. Neovim is clean (and hangs less in general). No bloat. Emacs is a monster, suited towards my liking (with many years of .emacs config).

But as much as I love Lisp, sometimes you want to get away from the bloat and sit quietly with a blinking cursor in vim.

I had a very similar experience and at the end of the day I switched back to vi(m) (and specialized IDEs) mostly because I didn't have the time to constantly evolve my emacs environment to solve the tasks at hand efficiently. I can see the appeal of emacs though if you really have the time and energy to deep dive and make it your own environment.

To this day, I still swap ctrl/capslock - that is so useful that it should just be a standard.

The default cursor movement commands probably predate emacs. Such that you are used to readline defaults. https://news.ycombinator.com/item?id=24083753 is the first post I'm finding on that.

That said, I'm curious what the weight of emacs was on you? If it was that you were wanting to be in the other editor, than it makes sense that you should stay in the other editor. But this is no different than a lot of things. Is why some folks don't like changing the vehicle type that they use daily. Very little rational argument one way or the other. Such that, yes, you should use what makes you happy. Not only does it make you happy, but you are probably more effective because of that.

> what the weight of emacs was on you

What I've noticed about emacs lovers is that they all customize it heavily - I didn't want to do that, since to me the point of using a plain text editor is that it's always available in exactly the same form wherever I happen to be. I did start to looking into all the ways to customize it, but at that point, I couldn't really see much benefit over just using an IDE.

But that's just me.

Oddly, I haven't customized mine heavily. I'd assert that there really isn't a single "crowd" that are computer users. All the more true for stuff as customizable as emacs.

Even more amusing, I'm fairly certain I had more customization in vim before I decided I wanted to learn lisp. What ultimately killed my customization in all things, was I felt like I was customizing on top of a very shaky foundation. Emacs/vim are stable enough, of course. But building/packaging software is basically a giant playground.

Yeah I adore picking at my config to solve some small issue. Or implement a cool feature or customization.

I don't really use Emacs for the editor! It's more because it's a very configurable language runtime/vm with an editor interface.

And org-mode is great too.

I've been using Emacs for more than 30 years and my init file is mostly loading and configuring extra packages, and not customizing the editing behavior. I have no problem working in a basic "emacs -q" session (which skips loading the init file) when I don't want to "pollute" my main session (eg. working with huge logs/dumps).

This has gotten easier as the years go by, as well. Standard emacs has a lot of affordances that computers just couldn't do without bogging down the system years ago.

This is the way. While I do rebind plenty keys to enhanced or do-what-I-mean versions, I'm careful to avoid fundamentally change the meaning of any of the vanilla keys. So I see my config as more of a progressive enhancement over `emacs -q` or `mg` and I can still work with them just fine (if somewhat less comfortably).

Being able to work with `emacs -q` is also important to me for extending Emacs. It's easy to partially roll back a change if I break something in my config, and I can test out new elisp code against base Emacs.

"What I've noticed about emacs lovers is that they all customize it heavily - I didn't want to do that, since to me the point of using a plain text editor is that it's always available in exactly the same form wherever I happen to be. "

So you not customize vim either?

If you don't, you're missing out 99.999% of the greatness of both editors and doing yourself a huge disservice.

It's like being a carpenter and limiting yourself to only ever using a screwdriver.

> you not customize vim

No, and I have a specific reason - I ssh into remote boxes a lot, and I want the editor to work more or less the same wherever and whenever I use it. I guess I could customize vi to be a multi-purpose IDE but... that's what I have IntelliJ for.

If you're using vi or vim for really simple tasks, and not using it much, you're not missing out by not customizing it.

But the more you use it, the more you're missing out by just using vanilla vi or vim... and I hesitate to mention them in the same sentence because even vanilla vim is thousands of times more powerful than vi.

Vim's true power, however, lies in its customization and plugins. You're really missing out by restricting yourself this way.

That isn't a perfect reason to not customize your local editor. Most all allow opening remote files and shells. And simpler things like recently opened files can already be very convenient.

Simply put, IDE in the IDEA sense is not the only end goal. Such that that straw man is obnoxious.

Now, it is perfectly fine to just not want to. Such that I am not saying you should reconsider. Just don't be too proud of that reasoning.

I have all my emacs stuff in a git repo called .emacs.d. Wherever I am, I clone it into my home folder, and Emacs picks it up when I run it. Then it ends up looking the same as it always is.

"But what if you end up somewhere where you can't do this?" - well, when it happens, I guess I will figure something out! But I've had no problems so far, and I've been doing this a while.

    tmbp ~/.emacs.d % git log | tail -n 1
    Date:   Sat Feb 23 23:30:41 2008 +0000

(Before that I used svn, also with no problems.)

My config currently works with Windows, macOS and Linux, terminal or GUI, and with any Emacs from 26 to 29, and it behaves about the same in all cases. This didn't take much effort! - though each untested combination have a bad habit of requiring 5-10 minutes of fiddling about.

Emacs predates readline by 13 years

I think of emacs as more of an operating system for emacs lisp with an in-built editor more than I think of it as an editor.

I say that because I have "live documents" that run Jira queries for me, and cross reference defects to other systems behind REST interfaces and can drive the whole thing with a few keystrokes.

(And it didn't take long to put together)

Emacs and emacs lisp, is a bit like Smalltalk in some ways too, once you get the hang of it. (and I've thought of porting that entire workflow I just mentioned to Pharo too)

> to this day I still don't see what the hype was about.

As an Emacs user[1], I agree. The flexibility is really cool, and there are a handful of Emacs applications (notice I didn't call them "packages") that are "killer apps", like Magit, Org-Mode, Calc, etc.

But, even though I do use and like Emacs, I can't honestly recommend it to anyone and I wouldn't even consider it to be a very good programming environment unless you're specifically working in a Lisp/Scheme (where it's awesome).

These days, I mostly use Emacs for programming in Rust and for using Magit as a git porcelain even when not using Emacs for the actual code editing.

Here are the things that suck[2] about Emacs (mostly from the point of view of a programming text editor):

* The UI is slow. Don't tell me that it's "only" when we have long lines, or too much syntax highlighting or whatever. Sure, if I turn off all of the useful programming features, the UI updates fast enough for me to not notice any latency, but any time I open a file that uses a LSP server or equivalent (not just Rust- I've done Clojure, JavaScript, PHP, and C++ in Emacs), the latency for even just moving the cursor around is noticeable and it's distracting.

* Tramp sucks. I don't understand how everyone says that Tramp is awesome and magical. Every single time I've tried to use it to do anything, it's been a bad experience. It's been a few years since I've even tried it, but I remember having to wrestle with ssh-agent authentication, some packages not playing nicely with it (besides the "obvious" ones like LSP-mode), and the whole application hanging if the Tramp session hung for some reason.

* It's actually really HARD to customize properly. The experts say that Emacs is "self-documenting" and "introspectable", but many times, I'll try to customize some behavior or a keymap or something, and I'll read the documentation for a variable or function and it'll say something like "takes a plist of FOO definitions,"--well, what the heck does a "FOO" definition look like? What are the keys for the plist? What are acceptable values for those keys? It's very common to just have to dig through the actual elisp code to find out. Then, you'll find out that your customization doesn't even work correctly because some other mode or function stomps on your code, or gets initialized in a different logic path that isn't affected by your change. Since every feature and every package is different, you have little chance of just figuring out a few conventions or any standard structure for packages.

* Handling buffers is tedious. Sometimes buffers appear and take over the whole frame, sometimes they split the frame and steal focus, and sometimes they split the frame and don't steal focus. And it's very ad-hoc and tedious to try to separate out "background, system buffers" from "my actual work buffers". There are tons of Emacs packages that attempt to make it easier to manage buffers, switch between them more easily, group them in lists, etc.

Like I said, I like Emacs. But, I also run Linux on my personal machines and run a de-Googled AOSP ROM on my rooted Android phone. UX, polish, and convenience are obviously not a high priority for me.

[1]: I've used Emacs to varying degrees and with varying levels of dedication and hardcore-ness since 2008-ish. At a few points, I would've said that I was pretty competent/proficient in Elisp, and have authored some fairly elaborate functions to help me with common tasks within Emacs. I even use to try to do a version of "literate programming" with org-mode and org-mode babel blocks in place of something like Jupyter notebooks for Python.

[2]: Yes, this is a very negative comment, but I tend to complain loudest about the things that I love and care about. I don't complain or criticize things that I don't like or don't want to use.

> Handling buffers is tedious.

I feel the pain. I often daydream about spending time customizing it to my needs, and add that to the other 576 ways I want to customize it and don't have time.

And then I sigh and remind myself "At least it's better than tabs!" before I return to my tasks at hand.

I have love/hate relationship with Emacs too, but for the stuff I do in Emacs I hate other software more. So Emacs it is.

I love emacs, but agree with many of your criticisms.

Emacs can be slow. I don't use LSP, so can't comment on that, but it's definitely slow on long lines with syntax highlighting.

I don't use TRAMP for exactly one of the reasons you mentioned: it can hang Emacs. I want to avoid that at all costs, because I pretty much live in Emacs.

Emacs' default handling of windows (in emacs terminology it's "windows", not "buffers" that you're talking about) is painful, but you can improve that through various packages, like popper[1]

Depending on what problems you run in to and your skill level, it could be tricky to debug elisp programs. However, compare that to when you run in to some bug in VSCode... how are you going to debug that? You'll probably have to submit a bug report and wait for the developers to get to it (if they ever do)... how is that better than emacs?

Also, remember that you don't have to go it alone in troubleshooting the issues you run in to with emacs. There's a whole community ready and willing to help.

Despite the downsides of emacs, I still use and love it. Every editor has downsides, and emacs is no exception. Its positives far, far outweigh the negatives for me. There's just so much more that it can do than other editors, and it's far more customizable. I very much doubt I'll ever seriously consider switching to another.

[1] - https://github.com/karthink/popper

> Emacs' default handling of windows (in emacs terminology it's "windows", not "buffers" that you're talking about) is painful, but you can improve that through various packages, like popper[1]

Whether I'm complaining about buffer handling or window handling is a matter of perspective. If some event causes Emacs to create a new buffer and to split my frame with a new window to display it, I see that as Emacs handling the buffer *by* creating a window. Not that it matters, because we all know what I mean, because we all share the pain.

It's such a universal issue that there are tons of packages and tips for trying to improve the situation, such as popper. I've tried several over the years and have given up on using any of them because it's always a game of whack-a-mole. There's always some new surprise that is not caught by the helper package and/or your own configuration. So, today, I just have some easy-to-hit key bindings to quickly close the most recent buffer/window, or change focus, etc. It's still a pain in the ass to sift through my buffer lists, but oh well.

> Depending on what problems you run in to and your skill level, it could be tricky to debug elisp programs. However, compare that to when you run in to some bug in VSCode... how are you going to debug that? You'll probably have to submit a bug report and wait for the developers to get to it (if they ever do)... how is that better than emacs?

I don't know anything about VSCode, honestly, but I'll pessimistically assume that its plugins are "closed" to the end-user. Is that true?

But, it's all a double-edged sword. Everyone acts like Emacs is so open that you or I can just go in and fix whatever we want, but that's obviously not true- neither in a strict technical sense (can't edit the tons of inner C code directly in my configs), nor in a practical sense. If Emacs is such that you or I can just hack some ELisp to improve whatever we want, then why haven't you or I fixed our troubles with TRAMP, or slow UI rendering, or the buffers/windows problems?

Is Emacs very hackable? Yes. Much more so than any other editing environment. Is it completely changeable? No. Not even close.

Yet, the trade-off is that there's no structure to anything. Packages all do their own thing, and tap into various parts of Emacs when they're loaded. So, if you load the same two packages in different orders, you can end up with different results. This is especially frustrating with keymaps. Plus, a lot of (most?) packages have auto-loading, which means you don't always even *know* the order in which your packages will load, so sometimes your Emacs will behave differently than other times even with no config changes!

I love the philosophy of making everything hackable, but there's definitely something to be said for enforcing some structure or limits on when and how things are modified.

By far the best part about other programming editors compared to Emacs is that I can install umpteen addons/plugins/whatever and still go to ONE settings menu and see/edit all of my keybindings. And those keybindings will always be correct, no matter how many times I restart the editor, no matter what order I do work during an editing session, etc.

> Despite the downsides of emacs, I still use and love it.

Same here. I love it, but I also hate it. It's so powerful and there's so much potential, but it's also just so bad in a lot of ways.

Closing thought:

Sometimes people say Emacs has bad defaults. But that makes it sound like it's just a matter of some settings. Like you just need to pick a nicer font, pick a nice color scheme, change some key bindings, and turn off the splash screen and that'll do it.

But, if you look at all of the buffer/window helper packages (e.g., popper), and all of the package-management helpers that basically every single one of us use (use-package, straight, elpaca, etc), and how many people ask for help with key binding (and use things like general.el), then it starts to seem like the issue of "bad defaults" isn't really about minor settings tweaks--it's just that Emacs doesn't really *work* that well by default.

I'm going to keep using it, but I'm not going to pretend that it's actually a good editor. It's not even actually a good application platform because a hung SSH connection through TRAMP or a slow-to-load email refresh in gnus or mu4e can take the whole thing down--imagine if your OS went down when an SSH connection dropped...

> which are (for some reason) the default cursor movement commands in most command line environments like the Postgres CLI.

AFAIK/IIRC these bindings are something to do with readline being widely used for CLI interfaces?

Additionally, they work all over OSX too (on text inputs), not just the shell--<C-a>, <C-e> for start and end of line, etc, probably lots of others too that I'm unaware of.

why didn't you just use evil mode? vim is great and so is emacs and with evil mode you get vim inside emacs. i still use emacs for magit as it's hands down the best git gui i've seen so far.

i used to use spacemacs but just wanted a quicker startup while still being reasonably configured... doom emacs is both.

> I've been a hardcore vi user pretty much my entire life, but I decided to force myself to spend a year using emacs a while back just to see what all the fuss was about.

This is like saying that you have been a mountain biker all your life, but then decided to play the trumpet for one year. Nonsensical conjunction.

Nonsense. Emacs and vi have similar use cases, right? And similar inputs (keyboard) and similar environments, for similar users.

They might be a difference of degree along a few axes, but they aren't a difference of kind like trumpets and mountain bikes are.

As someone who used Emacs 10yrs before ditching it.. I just really don't think it's very good at doing much.

I mean sure it can sorta half ass a lot of different things but besides org-mode and magit, it's a pretty mediocre and clunky piece of software (clunky, incredibly slow, ugly, etc)

I did the same experiment and came to the same conclusion. There’s really nothing killer in Emacs that makes it a huge sell over just using vim which is a much better editor unless you just love Emacs lisp. Emacs also has some glaring issues - tramp being a major one. It’s slow and very unreliable.

Vim is much more in line with the Unix philosophy. It’s a great editor that can be extended with fzf, ripgrep, lsps, git etc. Emacs has three versions of every plugin and they’re all usually not as good as the thin vim wrapper around fzf etc. If you’re not editing and need email, mutt is a great email client. Irssi is a great chat client. Emacs is very much an all or nothing computing environment.

I am glad I tried Emacs though, because I did love which-key and ended up adding it to my Vim config. And Emacs is slightly easier to quit?

ADVICE: Try both Emacs and Vim vanilla before you do anything else. Downloading a "distro" is really doing yourself a disservice by not showing you just how much either can do without the chrome. And for the love of RMS DON'T USE VSCODE.

Huh, my experience is the other way around. The "killer" of vim is the control scheme, and evil mode ports that over very faithfully to emacs. Then you get the best of both worlds. Why would you use vim other than in very barebones environments where you cannot access your own config?

(I also don't see how tramp is an issue -- it opens up workflows I wouldn't even have access to without it!)

Why would I want to run an emacs layer adding more latency to my work to turn Emacs in to Vim when, as I said, I can do everything in Emacs I can do in Vim.

> (I also don't see how tramp is an issue -- it opens up workflows I wouldn't even have access to without it!)

Because it will randomly freeze and it's single threaded, it's slow, and it's also not novel. Vim can also edit files over SSH, VSCode can run itself remotely.

> I can do everything in Emacs I can do in Vim

Can you immediately jump to the source code associated with any key binding, read it, debug it, modify and reload it, etc., regardless of whether it comes from the base distribution or a plug-in?

For me that’s the killer feature of emacs.

I am in the same boat. Been working a lot with C++ recently and could not get debugging working. Threw in the towel and loaded vscode in about 2 hours had everything humming along and being productive.

I'm pretty sure I did the wrong thing and started with a setup like Spacemacs where random stuff would break and wouldn't even know where to look. Thought I can't seem to loose the muscle memory of vim bindings so evil is a must. On my next round will try dooms or centaur so I learn more under the hood. I do miss magit and helm.

> some glaring issues - tramp being a major one. It’s slow and very unreliable.

Over SSH? Did you turn on ssh connection sharing in ssh config?

> ControlMaster auto

> ControlPersist yes

> ControlPath /tmp/ssh-%u-%r@%h:%p

massive speedup when you do this, otherwise it starts a new connection for every operation.

Yes, and it's not that it's just slow, it also freezes Emacs completely when it borks (and it does bork). I also found that none of the emacs terminals could correctly display my prompt and I ended up writing a bunch of bash conditionals to make my prompt dumber to work in Emacs. Just worked out of the box with Vim's :term.

Are you using tramp on a LAN or halfway round the world with 200ms latency and poor bandwidth?

A common thing people run into with Emacs is using the "shell" under the impression that it's a terminal emulator. You want "term" for a proper terminal emulator that can handle fancy terminal stuff. The "term" terminal emulator can even run TUI stuff like nano, and even vim itself!

Tramp is fast for me as well, it did take some work though. I had to configure it to use my controlmaster options from my ~/.ssh/config, set tramp-verbose to 0, set remote-file-name-inhibit-locks to t, and finally set vc-handled-backends to just Git. I'm glad I spent the effort to make it fast though, because now it's pretty magical.

Use both heavily. Vim is fantastic for editing one off files.

Emacs on the other hand is fantastic to work on a computer for a long period of time. I do use evil mode, as I do think it's a much better way to work in a file. Project management, magit, org-mode, being able to edit functionality of the editor within couple of mins to adjust for an temporary change/or indefinitely is what keeps me coming back to emacs.

I've tried vim variations that build in project management and all I'm missing from emacs, but left it at some own written telescope functions to cover base needs.

Love for both, but to me they are not comparable.

(Maybe because I picked up emacs at the same time a good friend picked up vim, and it's been a parallel editor journey for 6+ years)

Vim has terminal support, gdb support built in. We have vim plugins maintained by the top Vim plugin specialist for git and project management. We have vimwiki, markdown, org mode support. We have fuzzy finding, autocomplete, lap support. I really don't think you can reasonably tell me you can't live in Vim, when I have had the same session open editing the linux source tree for like two months now.

Maybe a Vim expert can help me out. I’ve used Vim for a long time, but never with any plugins, and only a few lines in my .vimrc.

My problem is that the syntax highlighting, specifically for TypeScript is pretty bad. I have a regular expression (for parsing front matter) that seems to cause Vim’s syntax highlighting to go haywire (it stops and sometimes crashes).

Is anyone aware of a way to get more reliable syntax highlighting in Vim, ideally with a minimum of fuss?

using lsp with typescript-language-server?

most of the neovim setup scripts (lazyvim etc) get this set up automatically

An LSP seems overkill for syntax highlighting? This seems more like a treesitter thing.

(Mind you, I have no experience with TypeScript, just saying this as a general remark on what those components do.)

Oh, my initial research (reading the Neovim docs) indicated that setting up Neovim would require a lot of manual configuration for getting an LSP working. I will give it another look, thanks!

Most blog posts I found seemed to assume you already had a gigantic custom config, plug-in manager, etc. I couldn’t find a “how to set up better highlighting and/or an LSP for people who know Vim but don’t know anything about configuration” guide.

Not disputing that VIM has those things, but I am telling you that I can't live in Vim based on your plugin setup. But of course, I'm glad there are good crafted ext/plugin communities on both sides so we can all can tweak it the way we like!

>I really don't think you can reasonably tell me you can't live in Vim

Vim at the end of the day is a terminal application and when it comes to debugging objectively it does not live up to the graphical interface of a proper IDE. Emacs is only slightly better in that regard, it's a GUI application but the age shows as well.

I don't think it's an accident that a lot of vim users are obsessive print-debuggers and that's just a plain handicap coming from living in a terminal. From just observing a lot of developers work I would say not knowing how to fully utilize debuggers and the modern interfaces we have for them is the number one productivity killer.

> There’s really nothing killer in Emacs

1. Org mode 2. Magit 3. Wdired 4. Synergy between various components (shameless plug: https://mbork.pl/2023-01-30_The_benefits_of_everything_being...)

1. Org mode - I will admit that I'm not a fan of org mode and find it to be oversold and another time waster for people who are already wasting time configuring their editors. I personally use vimwiki, there is a vim plugin for org mode.

2. Magit - Tim Pope is the pope of Vim plugins and fugitive is easily as good or better than Magit. I have never had any issue doing any sort of complex task in git or fixing conflicting using fugitive.

3. Wdired - Tim Pope again has vim-vinegar to improve netrw. Never had a problem or thought about manipulating directories inside of Vim.

4. Again, if you believe in the Unix philosophy then you have to admit that Emacs is simply bloated and trying to do too much and therefore is not really the best at anything. And more importantly, if there's something that Emacs can't do you've screwed yourself because you haven't built an environment around many distinct tools on the command line and it's going to be awkward to integrate.

> if you believe in the Unix philosophy then you have to admit that Emacs is simply bloated and trying to do too much and therefore is not really the best at anything

On the contrary, Emacs tries to do just one thing: provide an Elisp runtime for other applications. It does this fairly well.

Do not confuse Elisp applications like evil, org, calc, magit, etc. with Emacs itself!

Yep. If you see Emacs as a text editor with lots of features, then it's doing lots of things. But, if you see Emacs as a platform that comes bundled with some apps by default, then its "one thing" is to be a text-oriented app platform.

The whole "do one thing" slogan is kind of vacuous anyway; e.g., what if my "one thing" is "implement all WWW standards to be able to use any web page"? Is that still "one thing"? If not, then wouldn't implementing only "one" part of WWW be useless?

> I will admit that I'm not a fan of org mode and find it to be oversold and another time waster for people who are already wasting time configuring their editors. I personally use vimwiki, there is a vim plugin for org mode.

I actually use emacs solely for org-mode. I find editing single files and even larger projects to be more of a pain that it is worth, so I just use my custom vim to do that.

What keeps me with org mode and emacs is mostly bibliography management. I have emacs set up to read my Zotero directory, and with a keybinding I can insert a reference to a book or magazine or the such. Now, what is really great about this is that when I export the org file (usually to latex->pdf, but also occasionaly to HTML), it exports the references in the style that they need to be in (MLA, APA, Turabian, etc.) and creates a bibliography page at the end of the export with everything that I referenced.

I can also add notes to any references using org-roam, so that I have have annotated bibliographies quite easily.

If I could have something else that does just this, I would drop emacs in a heartbeat. But until I do find that, emacs and org-mode it is.

Same. I have try many outliners to irrationally avoid emacs but they all suck compared to org-mode.

How do you surf the web in vim?

How do you read email, RSS news, and usenet with vim?

Does vim have a chat client as powerful as ERC?

Mainly, though, is vim programmed in and extended through a lisp, and does it have an entire lisp ecosystem built around it?

Don't get me wrong, I love vim, and used it and vi for 25 years before switching to emacs. But my emacs can do far, far more than vim ever did... and there's no way I'll be switching back until it has all the above and more.

seems weird to me that one would want to do any of these things inside vim... though it should be possible with the right plugins... but why? just use a window manager like screen or tmux to multi-task.

It's because of the tight integration with the rest of the editor and all the rest of the packages that I use.

For example, when I go to edit an email I don't have to start up an external editor, so there is no context switching. Also, as emacs is super powerful, the editor that I use to edit my emails is super powerful, unlike the editors in most other mail clients.

Copying and pasting or importing/exporting between the various packages and other emacs buffers that I use is also seamless unlike anything that you do between conventional, separate applications. Everywhere that I go within emacs and everything that I do has the full power of emacs to do it with. I have macros, snippets, and elisp (to name just a few) at my fingertips.

Another advantage is that all these packages that I use (email, my git interface, RSS reader, etc) are all written in elisp and are integrated using elisp, so if you know elisp (which I do) it's easy to modify them to your liking, and have them do exactly what you want. This makes the whole experience super customizable to an extent unmatched pretty much anywhere else.

Without such integration and customizability, virtually all other software that I've used seems primitive and rigid by comparison.

So, yeah, it makes a big difference.

> seems weird to me that one would want to do any of these things inside vim... though it should be possible with the right plugins... but why? just use a window manager like screen or tmux to multi-task.

Imagine you put tons of information in vimwiki from your browser.

It's not a far stretch to wish you had a text browser inside of vim to more easily get important information into vim wiki.

At some point the browser could even begin to feel like a hindrance to curating and improving upon your higher quality vimwiki notes.

Emacs is like this, but not just for notes... for pretty much everything.

> just use a window manager like screen or tmux to multi-task.

I'm quite used to my auto-completion and snippets in emacs. As well as my clipboard history. The flexibility of isearch and how intuitive it's UX is.

If I leave emacs I never have all of those familiar things that fit like a glove. I'm in a different world with different rules that is far less malleable, understandable, and introspectable as emacs.

Hopefully that helps make sense of things a bit =)

I think this sort of defense of EMacs misses a key point: most people have no interest in running a browser, email, chat, etc. from within their text editor.

Generally people prefer to do those sorts of things with specialized applications that are more tailored towards those individual use cases.

Alas, living in emacs can't be appreciated until you get good at emacs. More than the "one-stop-shop" aspect of it, there's the "everything is a buffer of manipulable text" aspect which, again, can't be appreciated until you make the leap of faith.

> Again, if you believe in the Unix philosophy then you have to admit that Emacs is simply bloated and trying to do too much and therefore is not really the best at anything.

If.

Emacs is a lisp refugee in Unixland. It does not follow the Unix philosophy, it follows the Lisp philosophy. But it integrates.

-- Source unknown (to me)

> Never had a problem or thought about manipulating directories inside of Vim.

It's extremely useful though, I find myself using the fact I can treat my directory list as a text file quite often.

I wouldn't call Magit "killer" at this point, its basically feature competitive with other editor git integrations and that is about it

Also related plug, a newsletter with emacs plugins to help out with, mostly org mode and AI and emacs integration open source tepos.

https://generativereview.substack.com/p/tasks-open-source-em...

The tell in your message (and those in general from vim users), is insisting on treating Emacs as an editor, and comparing it primarily on that benchmark.

There are no shortage of Emacs lovers and users who will accept that vim is a better editor. You didn't need to try Emacs to gain that appreciation.

The other tell (common on HN, which has a clear selection bias), is comparing Emacs to an IDE like VS Code. Many, if not the majority, of Emacs users are not primarily using Emacs for coding.

> Vim is much more in line with the Unix philosophy.

Neither follows the Unix philosophy well. And as many people have pointed out, most of the Unix utilities are poor at following it well.[1] The amusing thing about the Unix philosophy is that when you stay within Emacs, the Emacs environment is a much better exemplar of the Unix philosophy than Unix and its tools are. It is a lot easier to compose functionalities in different Emacs packages than it is in UNIX.

I was using a Mastodon client for Emacs and wanted to render LaTeX formulae into rendered equations. I'm an average elisp coder and I got this working in under an hour by composing different Emacs packages.

There are various ChatGPT clients out there. I wanted to integrate it with my Emacs email client (notmuch). It's not a lot of work. I doubt one could integrate things into mutt as quickly/easily.

When reading an email in Mutt, how easy is it to quickly do a Web/network query on a selected text, perform analysis on the result, and display the outcome within Mutt? The analogue is fairly easy in Emacs, despite the mail tool(s) there not having any functionality to do this.

As for Mutt in general: I used it for about a decade. While it has a soft spot in my heart, there is a reason I switched to an Emacs client - before I knew anything about customizing Emacs with elisp. There were lots of gaps in Mutt that other clients out there filled. I miss nothing from Mutt, other than the color scheme.

In many of these cases, there are simply no quick, viable solutions outside of Emacs. People spend a lot of time doing these things in Emacs because it enables them to do more than they could otherwise. Imagine someone who doesn't know any programming complaining about someone else who does. To them they just see a person "wasting" all their time on another "tool".

[1] An example: https://www.johndcook.com/blog/2012/05/25/unix-doesnt-follow...

I've had the same visceral reaction when dealing with grep and find. Overly complex and bloated (albeit extremely useful).

Agree. Except vim cannot be better editor as emacs can be better vim if one likes

"Emacs has three versions of every plugin and they’re all usually not as good as the thin vim wrapper around fzf etc"

This is a bold claim. Not that fzf isn't good, but I'd like to hear about some specific ways in which fzf is better.

The strength of Emacs lies in customizing it to the user's needs. A clean installation of Emacs is not representative of what Emacs can be, but the various modern configuration frameworks such as Spacemacs and Doom Emacs offer a window into their creators' visions of what Emacs can be. And from there, it's easy to slowly transform their vision into your own.

These frameworks offer good defaults that lean towards having lots of features packed in, but it's easy to take away everything you don't want. Both Spacemacs and Doom Emacs can be stripped to almost nothing, leaving you with just a standard for organizing your custom configuration.

Vim is pretty much the best of both worlds: the ease of use of vi combined with the small footprint of Emacs!

I am personnally fan of command line vi modes. readline has one (bash, gdb, and others), zsh and fish have (a better) one too. I have remapped Caps Lock to Esc and it's never been easier to just go up and down the history with j an k and to make quick edits.

The some reason is the (GNU) readline library that powers most command line editing.

Also, macOS seems to have copied many of them, so they're worth learning for that too IMO.

> the default cursor movement commands in most command line environments like the Postgres CLI.

and also macOS!

Reply on news.ycombinator.com