[HN Gopher] The extensible vi layer for Emacs
       ___________________________________________________________________
        
       The extensible vi layer for Emacs
        
       Author : xrd
       Score  : 111 points
       Date   : 2023-03-03 13:01 UTC (10 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | didntreadarticl wrote:
       | Notepad++
        
         | pksebben wrote:
         | << cat
        
           | atahanacar wrote:
           | Butterflies?
        
             | mcbuilder wrote:
             | I've had a macro for that in EMACS for the past 30 years.
        
       | icelake111 wrote:
       | [dead]
        
       | dbtc wrote:
       | Here's a good place to recommend the browser extension vimium
       | (and vimari for safari).
        
       | Blackthorn wrote:
       | 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?
        
         | susam wrote:
         | 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-%
        
       | jrootabega wrote:
       | Emacs also has a vi layer built in: viper mode.
        
         | distcs wrote:
         | 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.
        
           | jrootabega wrote:
           | 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.
        
             | aidenn0 wrote:
             | 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.
        
             | distcs wrote:
             | > "It sucks, but I can't substantiate that" is not really
             | good discussion.
             | 
             | Agreed! Fixed that. See sibling comment of mine.
        
               | jrootabega wrote:
               | adjusted mine as well
        
             | distcs wrote:
             | 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.
        
               | jrootabega wrote:
               | 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.
        
               | distcs wrote:
               | > "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.
        
               | jrootabega wrote:
               | 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.
        
               | aidenn0 wrote:
               | I know that either G or gg was added in vim, but I don't
               | remember which.
        
       | clircle wrote:
       | I used Evil for 5-6 years. Meow is another great modal system for
       | Emacs.
        
         | tuukkah wrote:
         | 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
        
           | favadi wrote:
           | Now I finally understand the comment in another Emacs thread.
           | I thought people was talking about the Mew - a mail reader
           | for Emacs.
        
       | djha-skin wrote:
       | 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/
        
         | tuukkah wrote:
         | 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_.
        
         | avgcorrection wrote:
         | Emacs vs. Vim is a meme. You wrote a whole blog post as a PSA
         | over a meme.
        
         | john-radio wrote:
         | 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.
        
         | celeritascelery wrote:
         | 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.
        
           | ashton314 wrote:
           | 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.
        
         | noelwelsh wrote:
         | No
        
           | lampshades wrote:
           | The fall of emacs is inevitable. Don't deny yourself any
           | longer, brother, join us.
        
             | josephd79 wrote:
             | hahaha.
        
             | hexo wrote:
             | Actually changed from vim (and neovim) to emacs 4 years
             | ago. never looked back (except tui fasthacking)
        
         | shaunsingh0207 wrote:
         | 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.
        
           | djha-skin wrote:
           | 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.
        
             | shaunsingh0207 wrote:
             | 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.
        
             | nequo wrote:
             | 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.
        
       | heroytgoogle wrote:
       | I use Doom-Emacs which is just everything emacs can do + vim
        
         | adr1an wrote:
         | This, spacemacs development is a bit stalled. Also, I would
         | just use vim if it had TRAMP mode.
        
       | ParetoOptimal wrote:
       | 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
        
       | lillywastaken wrote:
       | 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
        
         | LanternLight83 wrote:
         | 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
        
           | [deleted]
        
           | srcreigh wrote:
           | 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
        
         | clircle wrote:
         | 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
        
       | hprotagonist wrote:
       | https://github.com/emacsorphanage/god-mode
        
       | ephaeton wrote:
       | 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.
        
       | giancarlostoro wrote:
       | 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.
        
         | mi_lk wrote:
         | 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
        
           | ticviking wrote:
           | 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-...
        
           | giancarlostoro wrote:
           | 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.
        
           | Ankhers wrote:
           | 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.
        
             | faizshah wrote:
             | 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.
        
         | shaunsingh0207 wrote:
         | 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
         | :)
        
           | aidenn0 wrote:
           | 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
        
       | 2dmodta04286 wrote:
       | Good post
        
       | ashton314 wrote:
       | 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.
        
       | lummm wrote:
       | 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
        
       | yodsanklai wrote:
       | 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.
        
         | faizshah wrote:
         | 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.
        
           | heartbreak wrote:
           | Is Spacemacs still in active development?
        
             | philonoist wrote:
             | Yes. Their main branch is the only one being developed, if
             | you are wondering looking at their releases.
        
           | ithrow wrote:
           | 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.
        
             | faizshah wrote:
             | 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.
        
             | oblio wrote:
             | That's just a warning, though. Annoying, but it's not like
             | you can't work because of it.
        
             | Jenk wrote:
             | I can't work out what is actually wrong here - there
             | appears to be very little detail, would you mind
             | explaining?
        
               | Scarbutt wrote:
               | False warning about unused definition 'salary' when it is
               | actually being used.
        
         | lvncelot wrote:
         | > 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.
        
           | yodsanklai wrote:
           | > 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.
        
         | cryptolake wrote:
         | 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/
        
           | khqc wrote:
           | what made you move off emacs?
        
         | bheadmaster wrote:
         | 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.
        
           | bobbylarrybobby wrote:
           | Neovim also has a server mode that lets it be used to drive
           | other editors, so you can get the best of both worlds.
        
             | bongobingo1 wrote:
             | 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.
        
           | filmor wrote:
           | I've been using Mason for LSP installation, works pretty
           | well.
        
           | vasac wrote:
           | 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
        
             | bheadmaster wrote:
             | Thanks! Will try to hack it up into my setup this weekend.
        
           | oblio wrote:
           | 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.
        
             | Jenk wrote:
             | 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.
        
           | rickstanley wrote:
           | 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.
        
             | pksebben wrote:
             | one kill ring to rule them all
        
             | iamdbtoo wrote:
             | 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.
        
       | worldsavior wrote:
       | Why not just use vim?
        
         | [deleted]
        
       | bin_bash wrote:
       | 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.
        
         | weavie wrote:
         | 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.
        
           | aidenn0 wrote:
           | 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.
        
         | eNV25 wrote:
         | I learned helix's keybinds pretty quickly, it's not too
         | difficult. Though, I don't really use it anymore, I prefer
         | Neovim.
        
         | [deleted]
        
         | vulcan01 wrote:
         | There is this configuration: https://github.com/LGUG2Z/helix-
         | vim
         | 
         | This switches most keybinds to be vi-like.
        
       | cyrialize wrote:
       | 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
        
         | luispauloml wrote:
         | 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.
        
       ___________________________________________________________________
       (page generated 2023-03-03 23:01 UTC)