Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The extensible vi layer for Emacs

github.com

Post reply on HN
Print view View original

61–70 of 104 posts

Re: The extensible vi layer for Emacs

#61

Post by aidenn0 »

weavie wrote: post #32
bin_bash wrote: post #6

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.

Re: The extensible vi layer for Emacs

#62

Post by aidenn0 »

shaunsingh0207 wrote: post #16
giancarlostoro wrote: post #4

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…

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

Re: The extensible vi layer for Emacs

#63

Post by distcs »

jrootabega wrote: post #42
distcs wrote: post #37

Earlier quoted context omitted.

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…

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 jus…

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.

  V
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.

Re: The extensible vi layer for Emacs

#64

Post by aidenn0 »

jrootabega wrote: post #42
distcs wrote: post #37

Earlier quoted context omitted.

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…

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 jus…

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.

Re: The extensible vi layer for Emacs

#65

Post by aidenn0 »

distcs wrote: post #63
jrootabega wrote: post #42

Earlier quoted context omitted.

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 jus…

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. V Instead of s…

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

Re: The extensible vi layer for Emacs

#66

Post by clircle »

lillywastaken wrote: post #40

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

Re: The extensible vi layer for Emacs

#67

Post by distcs »

jrootabega wrote: post #42
distcs wrote: post #37

Earlier quoted context omitted.

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…

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 jus…

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

Agreed! Fixed that. See sibling comment of mine.

Re: The extensible vi layer for Emacs

#68

Post by jrootabega »

distcs wrote: post #63
jrootabega wrote: post #42

Earlier quoted context omitted.

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 jus…

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. V Instead of s…

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.

Re: The extensible vi layer for Emacs

#69

Post by jrootabega »

distcs wrote: post #67
jrootabega wrote: post #42

Earlier quoted context omitted.

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 jus…

> "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

Re: The extensible vi layer for Emacs

#70

Post by faizshah »

ithrow wrote: post #48
faizshah wrote: post #33

Earlier quoted context omitted.

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. F…

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.
Post reply on HN