The extensible vi layer for Emacs | Hacker News Reader

The extensible vi layer for Emacs

github.com

125 pointsxrd97 comments

I used that settings for a few years, then tried to move entirely to vim, and now I'm very happy with vscode + vim.

I like vim as a touch typer, I think it's a setting that minimize end motions. It's also very convenient in the terminal. On the other hand, I think it's not convenient as an IDE: too many shortcuts, clumsy integration with LSPs, especially when you need to work with different languages.

For me it works best as a light, universal, editing mode on top of a modern solution for an IDE. That being said, I wonder if I wouldn't be better off moving away from vim entirely and get used to a simple setting which works straight out of the box.

> That being said, I wonder if I wouldn't be better off moving away from vim entirely

That's a surprising sentence to read, as someone who's also used to vim (although I've moved from vim to emacs+evil and not the other way around).

I have some gripes with my emacs+evil setup, just as I had some gripes with my vim (and then neovim) setup. But none of those gripes were related to the actual text editing, but rather making those tools behave like an IDE.

For the modal text editing, after I got used to it, I have zero complaints, and I feel much more comfortable editing any sort of text/code that way.

If I had to choose, I'd rather give up syntax highlighting than modal editing, because it has become so ingrained.

> That's a surprising sentence to read, as someone who's also used to vim

Well, I feel modal editing is "comfortable", as in easy on the fingers. But overall, I'm also quite fluent with the mac os shortcuts. Maybe it's just a matter of learning the few things I don't know how to do without vim and I'd be equally happy. The added bonus would be to have a simplified set up that would work in every contexts where vim isn't available. That being said, it's not something I want to do actively as I'm happy with my set up, but just wondering if the benefit is real.

Even on windows, while there are some obvious editing benefits with Vim mode, there's so much you can do with modern shortcuts. VS Code is customizable as hell, and the mouse is still an invaluable tool. With a TKL keyboard, I have no issues reaching for it and then resting my hands back on my keyboard without looking down or searching for it.

Spacemacs is also a good option. I use VSCode + vim for remote development which is super nice now, I think VSCode has by far the best remote development experience, I even use it as my main terminal.

For local development I use Webstorm, Rubymine, intellij etc. with IdeaVim, this is mainly because I prefer not fiddling around with plugins and configs I want my IDE to “just work” no matter what language I am using.

For writing project plans, design docs, etc. I used to use spacemacs for org mode with vim integration but now I have found myself switching to Obsidian (which has vim keybindings) and I have been dabbling in Quarto with VSCode but I haven’t settled on a good workflow.

Spacemacs is also nice because you can use magit if you want. But I don’t recommend using eMacs or vim as your main IDE because, like you said, the auto complete tools like intellisense and GitHub copilot integrations in other IDEs just work a lot better.

I generally now just feel like I want my development environment (laptop, ide, shell) to “just work” I want to spend as little time as possible configuring that stuff and I just want to focus on actually building stuff.

Intellij/Webstorm doesn't "just work", at least for javascript: https://youtrack.jetbrains.com/issue/WEB-57184/wrong-warning...

It's a real turn off that a commercial IDE can't get fundamental stuff like the one show in the bug tracker correct (or fixed in a timely manner). You start to question why you are even paying for the thing.

There are some annoyances like the caches and the indexing time when reinstalling node modules but I'm an FEE and I use it everyday productively for FE. The fundamentals are all sound, my favorite feature is the debugger, git integration and test runner.

I can't work out what is actually wrong here - there appears to be very little detail, would you mind explaining?

False warning about unused definition 'salary' when it is actually being used.

Thank you for explaining - I didn't think to click on the thumbnail as I thought the snippet _is_ the expanded thumbnail.

The way I see/read it: it _isn't_ being used in respect to nothing _reads_ it, except within the calculation to raise - there's nothing that reads the result of the raise. It's warning you that you are (potentially) needlessly capturing state. I agree it's a valid warning (for that specific example.)

I appreciate it is just an example to demonstrate the issue but I am unable to deduce a scenario where that wouldn't be a valid warning.

'salary' is part of the constructor's body and the constructor is being used, it shouldn't warn. Look how it just warns about 'salary' but not about 'name', in the image, only 'salary' is gray out. It's not even consistent.

That's just a warning, though. Annoying, but it's not like you can't work because of it.

Is Spacemacs still in active development?

Yes. Their main branch is the only one being developed, if you are wondering looking at their releases.

For all the space/doom emacs users check out VSpaceCode it's basically all the space emacs shortcuts in vscode and i can't live without it anymore.

https://vspacecode.github.io/

what made you move off emacs?

The performance and the time investment, even with doom, there were lots of bugs and performance issues especially regarding lsp/debugging. I'm sure the problems can be resolved but i would need to sink my time into it.

NeoVim has got native LSP support, and works pretty well for me out-of-the-box for most languages. LSP servers need to be installed externally, but I hope they manage to bundle them somehow in the future. LunarVim already provides automatic LSP server installation.

I doubt Neovim would bundle them.

I asked for two things which are conceptually much simpler:

1. a project manager/file explorer solution (file browser plugins have always been super popular for Vim; plus Sublime, VS Code, etc, all offer file explorers, they're extremely useful for... exploring projects for folks.

2. moving the command bar at the top

And they were both closed as WONTFIX mentioning that the Neovim core is meant to be compact and everything else should be built on top.

So that would require someone making and maintaining a super popular Neovim "distribution". I'm not saying it won't happen, but both in the Vim world and the Emacs one it doesn't seem like any distribution "won out" and you're always worried your distribution will just go away at some point.

https://www.lazyvim.org/ is really good. I use it for rust, golang, typescript (with react etc.), markdown, haskell, f#, c# and probably some others. Most all ready to go - the only exception was needing to uncomment two lines in the config for typescript lsp, all others set themselves up and away I go.

The command/status bar pops up in a modal akin to ctrl+p in vscode.

Neovim also has a server mode that lets it be used to drive other editors, so you can get the best of both worlds.

Yes, neovim + vscode is quite good, better than a "vim emulation mode". I believe one of the maintainers (justinmk) uses this as his primary workflow, or at least "at work" workflow?

Not all plugin work, mostly the esoteric ones that spawn many buffers etc, but all your motions etc work fine.

Personally I find vscodes text rendering not as nice as alacritty for what ever reason, otherwise I would probably use it as my primary interface.

I've always preferred having LSPs installed in my user bin folder (or system wide). I like to hop nto other editors and some of them, like Helix, do not have auto installer for LSPs and tries to use the locally installed package.

In other words, I like to have 1 LSP installed in my system for all of them.

I am the same and Neovim has a plugin, Mason, that auto installs them all into a bin folder. I just include that bin folder in my path and all other apps can use the same LSP servers.

one kill ring to rule them all

There's also a Mason[0] plugin that handles the installation of LSP (also DAP/linters/formatters) installation in a very visual way.

[0] https://github.com/williamboman/mason.nvim

Thanks! Will try to hack it up into my setup this weekend.

I've been using Mason for LSP installation, works pretty well.

There's also meow-mode[1], which isn't a vim emulator as such, but it is a different modal editing layer for Emacs which is a lot faster and has a lot of neat ideas. It doesn't interfere w/the stock keybinds at all though, which is much nicer imo (I use a 'hybrid' editing style generally)

1: https://github.com/meow-edit/meow

What I like about Meow is that it replaces a lot of stuff for me -- Evil, evil-collection, general, expand-region, and maybe something else. And it does not seem to be as invasive.

But the killer feature is meow's macro system

What’s great about meow’s macro system?

https://github.com/meow-edit/meow/blob/master/EXPLANATION.or...

There's also Boon which I like quite a lot but I opted against using mostly because of all the places I would need to type where I wouldn't have access to Boon unless I ported it (a plan I assure you but one lumped behind 1,000 other projects TODO).

https://github.com/jyp/boon

I've been seeing posts about packages like God Mode, Boon, and Meow[1] for a long time, and just haven't set aside time to check Meow out yet bit am very exited to c:

1: https://esrh.me/posts/2021-12-18-switching-to-meow.html

Haven’t tried others, but I really like boon. It’s so simple and it has the verbal actions like delete

I’ve patched the boon code to support switching between Dvorak and QWERTY

I used to use emacs-evil but found myself having to remember both vim and emacs keybindings. That may be my own fault since I probably wasn't using ALL the settings / extra packages that make vim keybindings work everywhere.

I've since switched to god-mode [0], which just turns emacs keybindings into modal ones. I find it works quite well. I think emacs keybindings are easier to remember but harder to use. Turning them modal solved that for me. (For example, Ctrl + F for forward, Ctrl + B for backward is easy to remember, but hjkl is right by your fingertips).

Side-note, it looks like god-mode was archived and then made part of the emacs orphanage. I started using it years after it was archived before it was part of the emacs orphanage. Noticed no issues, since again all it does is just make emacs keybindings modal.

[0]: https://github.com/emacsorphanage/god-mode

Although it is in the orphanage, the current maintainer is very receptive to contributions. I believe there isn't much activity because it is very stable, and there aren't that many users to find its flaws. For me, the biggest problem is remembering to turn it off before starting editing, but I guess that fault is on me, and it must happen to everyone at least once in a while.

There's active development of god-mode still though[0].

Mentioned elsewhere here, I've found meow[1] to be really interesting/good. And it leverages some of what makes god-mode nice (from their list of key features: "Minimizes modifier usage (e.g. `SPC x f` for `C-x C-f`) inspired by god-mode")

[0]: https://github.com/emacsorphanage/god-mode/commits/master

[1]: https://github.com/meow-edit/meow

Make sure to either:

- use evil-collection or

- be prepared to design vim keybindings per mode or

- instead use https://github.com/meow-edit/meow

A light bulb went off in my head, is Neovim able to use Emacs as a GUI yet? Why emulate VIM in 2023 when you can just become a GUI for it.

I'm still waiting for JetBrains to wake up from sleeping at the wheel and implement a Neovim client for their IDE core.

Its certainly possible, though useless.

Most vim emulation plugins struggle with accuracy, EVIL exceeds it. Manly due to evil-collection and various other packages, pretty much every emacs package has evil support, and that integration feels very native to emacs

This is a case where being a neovim gui would be worse. Though, someone could totally do it for shits and giggles.

Finally, that operating system would have a decent text editor :)

Out of the box several changes are needed to get it truly vim-like. Off the top of my head

- global undo tree

- the " and * registers work very differently than in vim, but there's a setting to fix it

It's kinda embarrassing, JB wants to push their new editor, but even months after public beta, the vim emulator is still barely usable, and afaict it's maybe like 1-2 people working on this.

I don't get it, if you are targeting developers, why is it that having Vim keybindings not a top priority? Or am I living in my own circle?

https://youtrack.jetbrains.com/issue/FL-10664

In my experience anyone using something other than VSCode, or Major IDE is a noteworthy signal that the developer cares about their tools and is probably better than the median.

There's an interesting blog post from a recruiting company breaking down the data they have on editors and developer success in their interview process. https://triplebyte.com/blog/technical-interview-performance-...

You may very well be living in your own circle. My anecdata is that most engineers use VSCode these days. In my current organisation I am the only person that uses Emacs that I am aware of (and I use evil-mode). I know a handful of people use (n)vim. But by far the most common editor I see being used is VSCode.

I work on a frontend team, most of my coworkers use VSCode and very few use the vim plugin for it. On our backend teams I believe IntelliJ is still the most popular editor, it’s really uncommon to find anyone using vim or eMacs for work.

Personally I just use Jetbrains IDEs w/ IdeaVIM for most things because I can’t be bothered with all the plugins and configurations I would rather my IDE just work out the box in any language.

My thinking is, if you focus heavily on letting your editor be a client for Neovim, you now can pull in all the stubborn VIM users easily. "Look! It behaves the most like vim that any editor you've ever used does!"

I fully agree with you. I'm not sure why they're asleep at the wheel.

A personal anecdote:

I grew up using Emacs—I think the first time I fired it up was when I was about 7 and was learning how to use mutt to read and send email. I used Emacs exclusively—I did learn the basics of vi bindings but never seriously used it—until I was about 24. I got a nasty case of RSI from using a mouse too much for too long. I went all-in on my ergonomic setup: I got a split/tented keyboard, a standing desk, went to physical therapy, etc.

I also took a look at my keystrokes and decided to 1.) get a keyboard with a thumb cluster so I could put modifier keys on my thumbs, and 2.) switched to Evil mode for the Vim bindings.

Life is awesome now.

I believe Emacs+Evil is the best of both worlds. I initially poo-pooed modal editing (why do I have to distinguish between inserting and appending?! It's so stupid!) but I've relented—using Vim bindings is like having a little composable language to talk about text editing. It's amazing.

Evil is incredible too. I'm still tweaking my setup to this day. But that's the thing—I like being able to tweak my setup to get to the maximum ergonomic configuration for me. I think there's some room for some better defaults and/or starter kits in this space (e.g. switching to vterm-mode should automatically take you out of Evil and drop you into the normal Emacs bindings, etc.) but things like evil-collection makes it so that I don't have to switch in and out of Vim-movement thinking.

Some things that switching to Evil-mode feasable:

- I started using the GUI so that Emacs could distinguish between e.g. Ctrl-Shift-x and Ctrl-x—it's nice having richer modifier combinations at your disposal.

- Having Ctrl-z bound to `emacs-evil-state` is a life-saver in situtations where you want to switch back to Emacs bindings for whatever reason.

As I understand it, Evil is the best Vim emulation out there bar none. E.g. I can use `/` as a motion command: `c/foo <RET>` will delete from the point to the next occurrence of `foo` and put me into insert mode. All this without loosing any of the customizability and the larger package ecosystem of Emacs.

I want a vi layer for helix. I don't want to have any vimrc configuration, just open my editor and have LSP and everything working immediately. I just can't figure out how to switch to helix keybindings.

Vi commands are verb-noun (cw - change word). Helix are noun-verb (wc - select the word then change it).

Learn to use multiple cursors in Helix - many of the things I have found lacking from Vi - eg pressing . doesn't work the same way in Helix - can be made up with more or less by using multiple cursors.

Helix was very disappointing for me; maybe it's just still immature (I tried it a few months ago and posted to the chat room several examples of things that were trivial in vim but had no helix equivalent; people there seemed receptive to making then work). kakoune is much closer to a good noun-verb replacement, at least for now.

There is this configuration: https://github.com/LGUG2Z/helix-vim

This switches most keybinds to be vi-like.

I learned helix's keybinds pretty quickly, it's not too difficult. Though, I don't really use it anymore, I prefer Neovim.

It's not evil but there is also a built in emulation for vi called viper.

I've never used it to emulate vi but I have used it to emulate ex, which is a part of vi. I don't know if anyone else feels this way but when I started with emacs a long time ago I thought that ex commands were much more productive for things like searching and replacing. For anyone who knows vi, that is for example :%s/regex/replacement/

So I just bound the ex prompt to C-c :

Maybe emacs does better for search/replace these days. What do others think?

For search and replace, the ex substitute command (:%s/pattern/string/[flags]) does feel more convenient and flows out smoothly from the fingers while typing such a command. For search and replace operations, it is indeed very productive.

However the incremental search (C-s) of Emacs goes much further than that. It is packed with features. While it has too many features to enumerate in one comment, I'll just pick one thing about it that I have found useful and quite enjoyable. It is the set of various toggles Emacs incremental-search comes with. Some of those toggles turn out to be very useful in special circumstances.

Say, I have a source code file that is doing some regex-based work. Both the regex "f.." and the strings it matches like "foo", "fox", etc. occur in the file. Now say, I want to search for the regular expression pattern "f.." (not the strings it matches). I can of course do that simply with:

  C-s f..

After searching for that regular expression, I decide that I now want to search for strings that match the regex pattern "f..". Now I can simply change the string search to regex-based search with this toggle:

M-r

As another example, let us say, I start searching for the string "web_server" with this key sequence:

  C-s web_server RET

But then I realize that the current code has the words "web" and "server" written together in all kinds of notation like "web->server", "web::server", "web-server", etc. and now I want to match all of them. In Vim, I would have to cancel the current search and write a new search expression, perhaps something like /web.\{1,2}server or maybe /web[-_:>]\+server depending on what we need. In Emacs, I can do it with this toggle:

  M-s w

And now it would match "web->server", "web::server", "web-server", etc. I know you specifically mentioned search-and-replace, not just search. The conveniences I illustrated above are available equally well in search-and-replace too because converting a currently ongoing search to search-and-replace in Emacs is yet another toggle:

M-%

https://github.com/emacsorphanage/god-mode

I've shot out emacs vs. vi back in 1999 and settled on vi after preferring emacs initially. Still, I think emacs is the better editor platform. every couple years, I try the available options in emacs for a vi input layer. None of them come close once you start typing quickly. It's way too easy for these emulations to stumble over quickly followed inputs. So in the end, I'll agree with djha-skin - just use (n)vim.

I've always had view-mode come on by default, and I have a bunch of custom keybindings for view mode which are nicer on the hands when you're just reading text.

So (add-hook 'find-file-hook 'start-view-mode) to turn it on automatically.

(defun view-mode-background () (if (bound-and-true-p view-mode) (face-remap-add-relative 'mode-line '((:background "#9400D3"))) (face-remap-add-relative 'mode-line '((:background "red"))))) ^ this helps a lot to know whether or not you're in view mode

And then: (defun view-mode-keybindings () (define-key view-mode-map (kbd "j") 'View-scroll-line-forward) .. etc

I used Evil for 5-6 years. Meow is another great modal system for Emacs.

Meow is really interesting for me as I never used Vim much. Meow seems to provide the benefits of modal editing with most seamless integration in Emacs. https://github.com/meow-edit/meow

Now I finally understand the comment in another Emacs thread. I thought people was talking about the Mew - a mail reader for Emacs.

It's been years since I used Mew. Wonder about any overlap in (current) Mew and Meow users.

I use Doom-Emacs which is just everything emacs can do + vim

This, spacemacs development is a bit stalled. Also, I would just use vim if it had TRAMP mode.

Just use vim. Yes, emacs has a lisp engine, but so does nvim[1]. Really, though, using vim properly means that it doesn't need to swallow the kitchen sink[2]. Just use vim.

1: https://github.com/Olical/aniseed

2: https://blog.djha.skin/p/emacs-users-im-okay-i-promise/

Your link seems to agree with the original article, not with your comment:

> To be most effective, Vim should be used from inside other tools. Vim inside IntelliJ, Vim inside VS Code.

> In whatever tool you’re already using, if you want a better editing experience, add Vim to it.

> To be very clear then, Emacs users: Rock on. Be happy.

So, Vim inside Emacs a.k.a. The extensible vi layer for Emacs.

Very silly advice. I use both emacs (Doom, as my IDE) and vim (as my CLI editor - git commits, etc) and telling people to use either one instead of the other is like telling them to use a car instead of a bicycle, when they already have made a transit plan and are happy with their situation. Emacs is just simply bigger in scope than vim; its ecosystem of packages and functions is completely unparalleled in vim-world; and as for vim it is useful for simplicity, efficiency, and ubiquity. They serve different purposes and they are both good tools.

When I first started using code editors I chose Emacs but was often worried I made the wrong choice and should have used vim. Until one day I realized that what makes vim great is the keybindings, not the software. Take away the modal editing and all you are left with is another crappy terminal editor. Once I had that epiphany I switched to evil mode and never looked back.

I came to a similar conclusion—Vim truly has Emacs beat with the keybindings. Emacs is a win though because it can be reprogrammed to emulate Vim with near-flawless fidelity.

Emacs vs. Vim is a meme. You wrote a whole blog post as a PSA over a meme.

I understand what you're saying but the feelings were real. I kept getting frustrated because I would comment and say you know vimm is not that bad and I would just get piled on by emacs users saying no come back it's okay just try us again and it was annoying so I wrote a response to them up as a blog post so I wouldn't have to write my opinion twice.

Okay I understand. Lame behavior on their part.

The fall of emacs is inevitable. Don’t deny yourself any longer, brother, join us.

Actually changed from vim (and neovim) to emacs 4 years ago. never looked back (except tui fasthacking)

hahaha.

Neovim isn't emacs, and you can't make it emacs no matter how hard you try - Emacs is writen mainly in lisp, neovim has a lot of c. You don't have to worry about if something is possible in emacs, you can just hack onto it, on neovim you have to spend an awful lot of time seeing if something is possible - Emacs has decades of ecosystem, neovim does not - Emacs is build on lisp and has first class support, fennel is a second class citizen in neovim, users are exepcted to (rightfully) figure their own way through things. Whereas the internet is full of decades of elisp knowledge - Emacs is a proper GUI. neovim is not, yet.

In the future, can neovim match and exceed emacs? yes. Is it capable of it? yes.

It however, is not currently is not an emacs replacement in any way shape or form. It is an entirely different editor, with a different way of going about things, and should be treated as such.

This is coming from someone who often contributes to neovim and neovide (a neovim GUI), and uses fennel both inside and outside of neovim extensively.

As I said, If you're trying to use vim like emacs, you're doing it wrong. You can and people do, but that's not the point. See my second link on the subject.

On a thread about emacs, you posted about telling people to use vim. why do it if you aren't trying to get emacs users to use vim?

If someone told me to change my workflow just to use the same bindings, that gives me every reason not to do it more.

By telling people to use Vim instead of Emacs, you are implying that Vim is a replacement for their use case, so they can use Vim like Emacs.

Here's a good place to recommend the browser extension vimium (and vimari for safari).

Emacs also has a vi layer built in: viper mode.

Viper mode is terrible though. Half the things I am used to in proper Vim do not work correctly in Viper mode. I don't remember those annoyances anymore but someone who has recently tried viper mode may be able to share the details.

(Edit: Turns out I do remember some of the annoyances. See the grandchild comment below where I have noted some examples.)

I found Evil mode is so much better at emulating Vim than viper mode.

viper is just a vi layer, not vim, as far as I know. Being able to have basic vi movement and operators is where most of the value in vi[m] layers comes from, IMO, and I haven't yet found any problems there. The most recent bug I've been aware of in viper (not that I am any authority here) was when the Emacs maintainers broke basic Emacs alt/meta key sequences when viper was active, and that happened because they just weren't thinking/caring about viper, which is the reason I spoke up here in the first place - people don't really think about it and it gets neglected. It's a vicious cycle.

So I fired up Emacs:

  emacs -q
  M-x viper-mode RET

Chose expert level 1 for beginners so that it is closest to Vi behavior. (Recommended level is at least 3 but that does not make a difference for what I am about to explain.)

  C-x C-f foo.txt RET
  i
  hello world RET
  hello world RET
  hello world RET
  ESC

Looking good so far.

gg

Does nothing!! Okay no problem. Let me try:

  :0 RET

Good. I am back to the top line.

Instead of starting visual line mode, it brings up find file minibuffer.

So that's 2 problems already from 2 minutes of using Viper. I have to admit though that I come from Vim (not Vi) so maybe my expectations are not fair for Viper. Is gg a Vi command or Vim? I can't remember. But I expect these basic things to work. It is this kind of stuff that used to trip me up often that I discontinued Viper and went with Evil.

BTW this list of annoyances in Viper keeps going on and on.

- dab, da(, di(, dib, etc. don't delete a block.

- gqq, gqgq, etc. don't reformat paragraphs.

- * does not search for the current word

- and so on and so on

Maybe I am being unfair to Viper but I guess you can see why in 2023, a Vim user might want to skip Viper completely and go straight to Evil.

Yes, gg and v/V appear to be vim-only commands. One vi counterpart to gg is 1G. Visual mode is a vim-only concept, I believe. The rest of them, I would bet are vim-only.

Yes, I can see why, if you require all of these vim features, viper would not be good for you. "Viper mode is terrible though." was not a good way to express this. The title of the thread, and the name of the package (incorrectly) state that it is a vi layer, so it's natural to mention the vi layer that's built into Emacs. It's definitely something that people should remain aware of and still provides value. IMO, Emacs + viper is significantly better than just Emacs, so it's worth knowing about. Comparing its vi functionality against vim is definitely good, but it being forgotten and neglected is not.

> "Viper mode is terrible though." was not a good way to express this.

Agreed and thanks for calling it out. Will be more careful next time.

I should add that I would love to see viper mode enhanced to (perhaps optionally) support some vim functionality, and I admit I would find it silly if someone said that viper should only ever support strict vi functionality. But I would also be sad if people used the existence of Evil as a reason to declare viper dead.

I know that either G or gg was added in vim, but I don't remember which.

It is impossible for me to switch between vim and viper. My hands will just start doing a text manipulation that doesn't work in whichever I'm currently using, and it breaks my flow.

Prior to evil-mode, when I used emacs for something, I used it without viper because at least then it was so very different that it didn't trick my subconscious into doing something that wouldn't work.

With a few tweaks to my config, I never have that problem with evil.

> "It sucks, but I can't substantiate that" is not really good discussion.

Agreed! Fixed that. See sibling comment of mine.

adjusted mine as well

Why not just use vim?

Notepad++

<< cat

Butterflies?

I've had a macro for that in EMACS for the past 30 years.

Reply on news.ycombinator.com