If you're wondering why you might want to use this instead of just launching Neovim directly in a terminal, then for me the answer is performance. Everything is silky smooth, much smoother than in Kitty/Alacritty. And to disable those annoying animations, just put this in your config.
How do you handle multiple projects at the same time, with a tiling window manager?
The nice thing about the terminal is the possibility of having layouts, tabs and so on. Or using tmux/zellij with a terminal that doesn't support these more advanced features.
As a data point, I'd like to chime in here. I have been a 15 year user of tmux (and screen before that) and never thought I'd change my development habits. Over the holidays I decided I would do one of those once-every-five-years upgrades to my vim setup as I had accrued dozens of vendored plugins in normal vim and wanted to see what the big deal with neovim was.
I bit the bullet and evaluated some of the "distributions" (AstroNvim and kickstarter) and played around with all the new lua plugins that I had never thought I needed (why use telescope when FZF-vim worked so well?).
Anyways, after a month of tweaking and absorbing, I found myself running Neovide only, and doing something I never thought I'd see, running tmux from within neovim/neovide. I think this only works (for me) because of session management (there are half a dozen plugins for handling quickly changing 'workspaces') and because the built-in terminal (with a very useful plugin called toggleterm: https://github.com/akinsho/toggleterm.nvim) works so well.
I have not stopped using tmux and layouts, and it sits in another fullscreen iterm2 workspace, but I find that I now spend 90% of my time using a fullscreen neovide and summoning/toggling tmux momentarily for running commands.
Of course, the caveat here is that my preferred mode of operation is being fullscreen as often as possible. I think if your preferred mode of operation is to always see splits then running neovim from the terminal within tmux is still the way to go.
As for why I like neovide? I find the animations, when tweaked to be less 'cool' are extremely useful to see where the cursor jumps to. I am also a huge fan of the fact that I can finally use 'linespace' to put some space between my lines of code -- it is an aesthetic I didn't realize I wanted.
> Of course, the caveat here is that my preferred mode of operation is being fullscreen as often as possible. I think if your preferred mode of operation is to always see splits then running neovim from the terminal within tmux is still the way to go.
Oh interesting, it sounds like it can't do permanent splits? Very odd to me.
I just open multiple Neovide instances. In each instance I usually have the screen split in the middle (two buffers at the same time), with the one on the right often replaced with the built-in terminal emulator.
I don't get the point of tmux when you're running locally. We have a desktop environment whose entire point to to manage several instances on your screen already. Isn't it better than using a multiplexer?
I've actually found the animations helpful even thought was initially skeptical: Because it visualises the vim motions it makes it much clearer what is happening. Especially if you make a mistake you'll see it much more clearly what it actually did. Also when making longer cursor jumps it is easier to see where it went.
I'm sure they will help a lot also when learning Vim for the first time.
But the be fair, the default animations are bit much but they can be toned down.
Should I take this opportunity to switch to Neovim for once? I've attempted using vim/neovim/emacs, etc. many times but it's just so confusing to me.
Why would I go over the trouble of debugging my editor for simple stuff like having LSP completions and semantic highlighting? It's insanely difficult for me to wrap my mind around vim packages, configs, etc., when VSCode/GoLand/et al. do a pretty darn job being decent editors that you don't need to hack on and just work out of the box.
Don't get me wrong, I'm not throwing shade on vim/emacs, I'm just wondering what am I missing since everyone's been super happy and productive with vim for ages, and if I'm approaching these tools the wrong way...
Friend... don't try to "switch". Just use multiple tools at the same time. I personally use all: Neovim (great writing/editing experimence, LSP+Treesitter+fzf allow you to get really far), Emacs (for Magit), VS Code (if Neovim or Emacs breaks I can still edit the code ;)) and WebStorm to run tests using nice and rich UI.
Don't try to limit yourself artficially.
I have almost exactly the same habits when using editors mentioned above. I'm not sure if I've been using Vim (neovim now) or Emacs (+evil) for longer, but both have great reasons to be installed at the same time.
No, I use Emacs keybindings in the rest of the tools. Tried to use vim bindings but they don't seem to do everything correctly or smoothly and it annoys me.
Actually... I use my own keybindings which are more ergonomic twist of Emacs bindings. For example for moving char left I use C-d and to move word left I use C-S-d (control+shift+d). Convenient to press using both hands (using right shift with pinky). Of course Control is swapped with Caps lock.
I suggest you try something like LunarVim[1] or NvChad[2] for a ready-to use IDE-like neovim configuration.
I had the same problem with configuring (neo)vim, it's simply too much work to get a reasonable IDE experience.
Using an already well tested and documented configuration helped me to make the switch.
I would recommend against heavy-handed plugins, it's the reason I burned out on nvim and fled to helix. The thing about a breaking change in a plugin (like, oh, I don't know nvim-treesitter - likely the most installed plugin) is that you find out when you are about to do work/be productive.
lazyvim is definitely the one I found easiest of a bunch of these. I've been using it for a while now, I haven't tried in neovide though, I just did and it ran but when I did an update there was a compilation error (on mac). So maybe avoid an update there? :) It was easy to fix in standard iterm2 though (just resync).
I think if you're happy with the experience that the IDEs you mentioned provide you, then there is very little reason to switch.
Being familiar with vi keybindings can be useful if you ever find yourself on a minimal system with no other editors available, but the subset of knowledge you need in that situation would be much smaller than if you wanted to use Neovim as your primary development environment. I think Emacs/Vim/Neovim and the like are better suited to users who actually enjoy the process of configuring stuff like LSPs and code completions in a way that's fine-tuned to their personal preferences and works the same across all programming languages.
If you are happy and productive with your current editor(s), no, you don’t need to spend valuable time picking up and configuring another one. Save the effort for when you actually need it.
Despite what others may say to convince you otherwise, this is the only correct answer ;)
I feel you, I feel the same. I just like modal editing too much.
Even though I have to remap CapsLock to Escape to make that usable.
I feel naked without those commands at my fingertips. It's not even about speed, without it it's like... it's like woodworking with a table knife
If I were to take up modal editing now, I'd go for Helix. It's a better editing paradigm (Kakoune inspired) and it aims at just working out of the box.
I finally opted for Lunarvim but I believe all those Neovim distributions are great
I'm the same way. I've tried like a half dozen times over the years to "get into" vim. It seems like the perfect thing for me. I used to love wasting time ricing my Arch install. But you know what happens? I get 3 hours into setting it up and realize I am only marginally closer to what I already have with VS Code. And in VS Code if I want more language support or some fancy new feature, it's like 3 clicks and it's just working immediately.
Adding language support in neovim isn't very difficult once you're setup. I use nvim-lspconfig[1] and just about any language you could need is documented[2]. But like others have mentioned there are batteries included distributions of neovim if that's your cup of tea.
You won't get the deep magic of emacs, or the benefit of learning vi key bindings (sadly there's not yet a helix mode for gnu readline) - but you get a great modal editing experience, good defaults and great discoverability.
I moved from vim/neovim a while back - and now I find vi/vim verb-object (d[delete]w[ord]) yanky compared hx visual select/object-verb (wd).
I'm intentionally trying to move from nvim to helix, but I still sorely miss macros, `gv`, `g;`, piping rg to the quickfix list, and a few others. Slowly getting used to it though, the ultra-fast startup time and no-hassle LSP integration is nice.
I use visual mode a fair amount for block-wise changes (something that helix does very well).
Unfortunately I reliably labor to get might visual selection correct in helix and then mistype a key and it's gone. Glad to hear it's coming!
`g;` takes the cursor to the location of the most recent change you made (and then the one before that, etc.). <C-o> in helix doesn't ever seem to get it right (unless I remember to <C-s>, which I never do).
Also glad to hear about macro support.
I should take another look at if they are interested in contributors. One of my main interests in helix is that I enjoy rust and don't know C/C++, so I feel like I could maybe "give back." That said, my first issue I raised was not taken very seriously (and is a show-stopper for helix on windows in my case).
Wonder how I missed that. I'm getting a re-education in helix today -- thank you! I'll go through `hx --tutor` again before I insert any more feet in my mouth.
While I can't say this is true for vim, in Emacs, I found that the customizability helps for a lot of different programing tasks. I run my terminals in Emacs and they are associated with my projects. Magit (the Emacs git package) helps me do complex rebases with diffs alongside creating branches and everything else you might do in git (even the reflog when things get rough). There is event a handy rest-mode that lets me write and save HTTP sessions. I connect to my database in buffer as well. What makes all this so handy is that I can move the buffers around to compare things side-by-side, use a single large buffer, etc. While VS Code has splits and terminals, I found that in Emacs I can access everything from my keyboard and now that I've gotten used it, I don't even think about it.
I've heard that a lot of vim folks get similar behavior via tmux and leverage other shell tools.
I'm not going to argue you should switch, because it is an investment. It is like owning a house, you have autonomy but you're also on the hook to fix the air conditioner. You also can't just drop it and move to the next editor. Your hands and workflows become tied to your editor. Keybindings may be similar, but it is not the full story. Either way, it is a journey getting good with your tools, so enjoy it!
For some people (myself included) the infinite configurability is the selling point, and configuration is the 'cost of doing business'. I'm an Emacs person but I'm sure it's the same for (Neo)Vim people too. You're gradually crafting your editor using your editor, and that feels good.
Along the way there are innumberable little choices that you make that shape it into something completely your own. Plus you know it's never going away or getting enshittified because it's open source and has been for decades.
Now, does it actually make you more productive? Or is any productivity you gain swallowed up by tinkering with configuration? That's an open question, and a valid one. People who enjoy an out-of-the-box IDE experience are fine by me - different strokes and all. I just enjoy working in an environment that is always gradually evolving according to my needs, even if it means putting in the work.
I think there's a faction of vim/emacs users who use it because that's all that was available when they started out. vi and emacs are ancient- nearly 50 years old. PCs introuced IDEs (think Turbo Pascal) in the 80s, but there really wasn't anything like this in the Unix or VMS world. So if you started programming for non-PC, non-8-bit machines, you would certainly have encounteded vim or emacs early in your career. I'm one of these people.
There's another faction, of users who have come to vim/emacs in the era of decent IDEs. I think a lot of these people have come in due to the keyboard focus of these vs. IDEs, or because they are very quick and responsive (though recent IDEs themselves are finally really fast, too), or due to aesthetics or because it's percieved as being "hardcore" or "cool".
IMO if you're productive with what you're using now, stick with it. But try other things and see if they click. This goes both for the Unix graybeards and the IDE kids.
I'm sort of halfway in your description there. When I began my Unix journey 33 years ago, yeah, that's all that was available. I picked up emacs because I hated (and still hate) the modal aspect of vi, and because I also used emacs to connect to MUDs and MOOs and IRC, and read my email, all in one. On my 486 with 8MB of RAM, emacs did almost everything for me in one place. I grew to really like C/C++ mode in it, especially the way it handled indentation and reformatting at a time when this was actually not a commonly well-done thing even in some of the IDEs at the time.
I then left it backgrounded in my brain for a couple decades, only using it here and there when I didn't have a GUI available, while I used JetBrains IDEs. I couldn't be bothered to do all the customization.
But the past few weeks, I got pissed at JetBrains for the way they're handling the CLion->RustRover transition, and my CLion license ran out and I said f'it, and spent a weekend really tuning emacs for my workflow. And, honestly, it's kind of awesome.
The key point being I can make it do whatever I want really. So the learning curve really comes down to what I put on it. LSP + Company Mode + Rustic Mode + Treemacs + Projectile is a pretty good approximation of an IDE. And then I just went through and tuned it up with the bindings I wanted, adjusting things as I went.
I had never in 30 years invested this much time into emacs before, and it was entirely worth it.
Anyways, the TLDR is: it's not just the "I want to be hardcore" and "I am ancient", there's real practical value to the depth of these tools that's actually hard to get out of other "editors", even VS Code. I can't speak for Vim, I have never liked that way of editing, but with Emacs it's really about building your own lightsabre.
You need to eat the upfront cost of learning to use vim's keybindings effectively. Once you've done that, you can edit text files quickly and efficiently on any Linux box from the last 30 years or so. Having an editor you can run right in the terminal, Ctrl+Z out of to run some commands, and then `fg` to keep hacking away is an incredibly powerful way to make using the terminal much lower friction.
Beyond that?, I just run LazyVim unmodified. It supports Copilot out of the box, which was my killer feature for it. Last year I even wrote a set of shell scripts I can curl into any new Ubuntu machine to fully automate all the setup for me, which might be of use to you as well, if you want to skip all the configuration. It also installs fzf, fd, rg, and a whole bunch of other useful tools all at once.
Can't speak for vim, but with emacs it's a lot like building your own lightsabre. If you want to invest the time, it can be very rewarding, as you're basically building your own tool chest full of your own customized tools.
But it does take time, and doesn't come "out of the box" with the creature comforts you're probably used to, and has "weird" ways of doing things that are very old but there's usually good reasons for them.
What I like about Emacs is that there are a lot of opportunities to automate away little things. For example, you can make it update copyright years automatically or define a template that will be automatically inserted into all files of a certain type under a certain directory (and that text is itself programmable).
What I like about neovim is that it's as fast as greased lightning. If I could say the same thing about Emacs there would be no competition.
If you’re not loving it then don’t waste your time on it. Use the tools that suite you. Getting into vim is a commitment to configuration, I’ve probably spent close to 50 hours of my life configuring this little text editor. It’s been relatively fun, but mostly because as soon as I started getting into it I had the bug to make it perfect for myself. I ended up switching to VSCode with a neovim extension and my life improved significantly lol
FWIW, I settled on using both. Vim with a simple config and Jetbrains(with vim plugin) when I want all the bells and whistles. Using both equally for coding.
My simple config does include vim-commentary, vim-surround (both supported by jetbrains too) and fzf.vim.
I will preface everything with: if you don't see yourself getting value out of vim... don't use it. It's that simple. Vim has been one of the greatest things in my life for most of my life, but that doesn't mean it will be for you. Everybody is different.
Also, I started using vim basically at the same time I started using Linux and really learning to program. There were plenty of other editors and IDEs around at the time. Even for the languages I was learning. I still use vim, but not those editors.
I will break vim into two parts: its philosophy(s) and its technical implementation. I think both are valuable, but for separate reasons.
First the technical implementation
Because I've been using vim for so long and from such a foundational stage for me, vim is largely just how I think about editing text now. Not just insert vs normal mode, either. Vim includes a whole host of features for editing text. I've been using it pretty regularly for many years now and still learn about new features. The rabbit hole is huge.
To the point that I find a lot of plugins either re-implement built-in features or outright go against the philosophies in vim (more on this later). Personally, I spend as much time (or more) trying to remove plugins as I do trying to find new ones to solve a need.
Plugins have better SEO, but worse integration with the editor, on average. Because of this, I might use a plugin for a bit just to solve a need, but then upon reading up on vim documentation (some of the best around), I might find a way to do something better than my current plugin-based way.
A frequent example is when I need to open a file that doesn't have built-in highlighting support. Instead of adding another plugin that might include more than just syntax support, I might really just need to alias it as another language. e.g. Jenkinsfiles are mostly just Groovy, so the following line is all I personally needed to make editing Jenkinsfiles in vim acceptable [0]:
au BufNewFile,BufRead Jenkinsfile setf groovy
None of that is to say "don't use plugins". Some people use hundreds of plugins, others use zero or very few. Both are correct. Personally, I still think that it's really easy to get carried away with plugins in attempts to try and turn vim into vscode or an IDE. If that's your goal, save yourself a ton of headache and just use vscode or an IDE. Truly ask yourself what it is you are trying to achieve with vim and work towards that, not feature parity with a completely different piece of software. [1]
Probably the biggest watershed moment for me was learning to use vim's buffers to manage multiple open files instead of always using vim's tabs. It has tabs, but they are a different metaphor from "tabs" in most editors. That still resulted in me adding a plugin to display open buffers at the top of the view, but that is an incredibly simple plugin that augments built-in vim functionality rather than try to shoehorn vim's tabs to work like tabs in other editors.
Getting a bit more philosophical
If you'll pardon a somewhat-forced metaphor, vim is a box full of handtools, not an all-in-one power tool. Each one can accomplish the vast majority of what the other can do and neither is inherently better than the other, but their ways of doing so differs greatly.
In particular, vim (like handtools) expects you to learn how to use it. It expects you to not only read the manual, but to keep referencing it and gradually learning new techniques for doing things. It expects you to sharpen it. It expects you to oil it. It will cut you if you abuse it [2]. This is also true for the power tools and other editors, but the whole point of using those is that your expected learning and maintenance is greatly reduced.
The payoff for those years (yes, years) of dedicated learning, at least in my experience, is that you will have a closer understanding of how the tool works. You will gradually develop a sense as though the tool itself has wants and needs. To be entirely too romantic, it is a symbiosis. Again, the way I think about editing text is in vim's commands and metaphors [3].
The other reward for that time spent is that vim doesn't really change. Sure, it's still updated (thankfully) and gets new features, but it is glacially slow to really change anything fundamental. This is often cited as a bad thing, but I personally love it as it means I can depend on it. I don't have to worry about my tool changing out from under me. That is rare in software, especially these days.
Sometimes even a master woodworker might still need a 3D printer, but having mastery over a hammer and chisel can pay dividends.
[0]: That line creates an autocommand for whenever a file called Jenkinsfile is opened or read, set its filetype to groovy instead.
[1]: There is an old article called Linux Is Not Windows. It's been a while since I've read it, so I might not agree with everything in it, but it presents a really great point: the only way Linux can be better than Windows is by being different. That means you will have to change your mindset before you understand it and/or like it.
[2]: Pretty big stretch here. It's not buggy and won't really do damage. I really just mean "cut" as more of "will be slower/harder than it might be otherwise".
[3]: I should point out that, while tools like vscode have plugins and settings to emulate vim's commands and a couple of modes, I have always found those lacking for my needs. I hope it's clear by now that vim is far more (to me, at least) than just using hjkl to move, dd to delete a line, etc.
Just install lazyvim and you basically have everything you need! A few languages are already configured as lazyextras so it's easy to add what you need
Only if you have carpal tunnel problems or painful arthritis, it will make you happy and as productive as a normal developer with vs/vscode/jetbrains/etc
The amount of time you need setup *vim in order to make it a useful editor is not justified, i have seen people waste weeks on it and the only reason is if you have a condition that vim helps to masquerade.
Personally m waiting to get enough money to justify a kinesis keyboard, that will the only reason to improve my neovim knowledge... as for the moment the vim keybindings for vscode are as good as neovim.
Something like gvim is relatively easy to get into if you can give it a few days and look some things up.
Neovim is bizarrely confusing and difficult to configure. The UIs are all weird terminal windows with no buttons, it isn't clear which of the dozens of folders are actually being used for configuration files, it isn't clear how the actual attributes are being declared, it's a disaster.
Although I'm happy with my current neovim setup, I do envy the cursor animations in this. Why hasn't a terminal emulator with cursor animations like this been invented yet?
If I had to guess, it's because terminals don't know what a cursor is. From the terminal's perspective, it is just told to print a solid blinking block at a certain location. Neovide knows what the cursor is because it is communicating directly with Neovim.
A terminal could do this, but there would need to be direct integration into Bash, ZSH, etc.
Terminals do have a concept of a cursor (there are dedicated control sequences for cursor management). There's no fundamental reason a terminal emulator couldn't implement an animated cursor like this, my guess as to why no one has done it is simply that it's not a very commonly requested feature.
Another problem is that the cursor moves while the screen is buffer is being rendered. The location is only really known once the cursor settles in the same place for some time, which is unacceptable in terms of latency.
Yeah true, maybe could be done with heuristics though - in nearly every case, there's only one single blinking block, which is the cursor. However, not everyone has their cursor configured to blink, and there are cases where there are other blinking blocks. Not sure how to deal with that...
I used this as my daily driver for several months last year - it was nice and fast, and I liked the cursor animations actually, but I ended up dropping it because of really strange window sizing problems on Windows with multiple monitors and multiple DPIs.
I wonder.. anyone have recommendations for going back to [Neo]Vim from Kakoune/Helix? I was a Vim user for ~8 years, but switched to Kakoune for the selection first editing style. I vastly, vastly prefer it.
However i'm extremely jealous of Neovide. As much as i love Terminal Editors, i feel like Terminals themselves have been an annoyance for a long time for me. Despite having solely worked in them for ~15 years, i don't like them at all for my primary editor. I just miss too much.
That animated cursor move effect is very interesting! I wonder if it could display extra information for the user, with some tweaking. Trying to think of some things that we do subconsciously while navigating code...
Moving across a code block with "{" and "}" could highlight the parentheses and the link between them, for a fraction of a second.
Highlighting or landing on a variable could send a tiny zip of pixels towards the nearest uses of that variable.
I've wondered sometimes if making the current function or block pop a little brighter than its surroundings could also give your subconscious mind a bit more information.
All these would have to be incredibly fast animations, just a few ms would be great for me. I loathe the slow-to-me animations in Android, and always use the dev tools to speed them up.
I'd be interested in giving this a try, however it seems to be completely resistant to the tiling window manager I use on macOS, Amethyst. It's fairly odd; I have not encountered another app that does this.
Most of these things don't have any way to configure margins. Does Neovide?
Books (made from paper) invariably have a region with no printing on the left and right sides of every page -- margins. But users of most text editors are tougher than that: they don't need margins apparently. I want the leftmost and rightmost parts of the editor window to be able to be blank margins.
I'm on Emacs currently because it is easy to configure margins (at least in graphical Emacs) but it would be nice to have another option.
You could either branch your Neovim configuration on `vim.g.neovide` [0] or start Neovide (and the underlying Neovim instance) with a different config file by setting XDG_CONFIG_HOME.
- Ligatures: ok, nice, possible in terms too (hopefully Alacritty one day)
- Animated cursor: I would disable that for sure
- Smooth scrolling: I would disable that too (surprised anyone would want it in neovim actually - do people scroll? I navigate line-by-line (or many lines) so it seems natural that the rendering should be the same, otherwise it's just a permanently clipped top and bottom line)
- Animated windows: ..that maybe looks a bit smoother, hard to tell without side-by-side, it's not horrible anyway
- Blurred floating windows: that's nice
- Emoji support: if you want it you probably have font configured anyway
Seems like it's for people who are reluctantly in a terminal, to position it more like a VSCode/Sublime alternative in an appy sense, there's not really much of an up-sell here for anyone familiar and happy with vim/neovim in the terminal IMO.
I am a pretty big terminal user, and I still use a graphical front end (specifically Neovide and Neovim-Qt). If you are happy with the terminal, you're right, there's no "upsell" here, but if you're happy with something, why would you switch to something else?
I use a graphical frontend precisely because I was unhappy with the terminal, and not because I am stupid, inept, or lazy.
For one thing, a graphical interface liberates you from constraints on key binding, fonts, and colors. Whether any particular graphical interface implements such improvements is up to the developer. But that's the beauty of the whole system: unlike with Gvim, none of that has to be upstreamed into the main application.
Neovim-Qt also offers a couple of interesting features like native scroll bars, a tab/buffer line made of native "tabs" instead of drawing it with plain text, and a native right-click menu. It also has some kind of adaptive color thing, for people who really like to "rice" their system and get a uniform look and feel across applications.
Something to keep in mind is that all of these projects are relatively new and developed by hobbyists. It will take years and years for any of them to reach feature parity with Gvim.
> Ligatures: ok, nice, possible in terms too (hopefully Alacritty one day)
I wouldn't hold my breath. Seems like its getting the iPad calculator treatment[0]. Which is to say rather than ship something working that can be improved, they're leaving a UX void.
Yeah, that's the issue I was alluding to ('one day'). Note the original author replied immediately saying yes would love to, ... but also that was over 7y ago now. But not a flat no, not a won't-fix; they don't leave requests hanging around that they have no interest in supporting.
Edit: and in fact, I'd forgotten all about it, but you can tell I'd seen that issue because it was locked on my suggestion ;)
It sounds like it's not deprecated, they've moved it out of the config file and into a Vim global variable. That's probably meant to be a feature, in order to work with changing color schemes.
The effects and animations remind me of the cool window effects in Gnome/KDE, back when they were first made available, like the window burning down completely when closing.
Cute, sometimes very cute, but ultimately distracting and only adds a delay to the intended action, so after a week the novelty wears off and I usually revert back to the old UI.
Typically "no-nonsense" UX (the kind used to get stuff done) has minimal animation, if any. The whole point is to focus, not to get distracted by railgun animations.
The feature list seems to be mostly eyecandy and emojis.
The point of railgun animations is not to distract you, but let you focus faster since it shows the path between the start and the end, which is especially helpful when cursor travels large distances.
So it adds no delay, has a very focused practical purpose, in what way is this "nonsense" UX preventing your from getting stuff done?
Some keywords are `mousemoveevent' and '<MouseMove>'. Then you can hook up anything into a mousemove event, including activating an LSP hover window. I like to activate hover info by keyboard, so I never looked into this.
It’s a bit weird to me that this is specifically for neovim when it kinda seems like a generic piece of glass for “some TUI” that in this case happens to be nv. Maybe I missed the point.
Theoretically you could support the same RPC API from a completely different text editor, and thereby use any Neovim-compatible frontend . That sounds like a nightmare of course, but it's technically possible.
For the commenters here: do we have something like VimR [1] for OSes other than the Mac that provides a file explorer sidebar with smaller font size (probably sans)?
Is there any complicated no-nonsense GUI for Neovim that transcends the GarbageUI of the terminals and, for example, allows you to have advanced keybinds to invoke various vim actions (like enter insert mode on tap I and exit it on hold I or modtap J+I)?
What's wrong with the native keybindingings? The simplicity to bind any command, even external programs or scripts is one of the best features of vim. For example I have leader+m to compile based on my current filetype, leader+d opens the binary in :termdebug (gdb) and many, many more. I keep adding to my config anytime I get sick of a repetitive action.
You don't need anything fancy to do what you're asking, except for holding a key, which AFAIK isn't possible. Some bind j+k to esc in insert mode. I don't like messing with the characters in insert mode because it creates latency and fucks with my typing but I swap esc and caps since esc is my most used key, and caps my least.
So you use your most used key with a sidewise motion of your weakest finger of your weakest hand? That's just bad ergonomics, and that's what's wrong with the native keybindings - they are simply awful ergonomically
JK is not the solution as your mentioned yourself since it's within the same simplistic/terminal-limited key input handling (also, it fails if you speak more than one language where JK is common in regular words, and also fails if you speak just one language since you can have variable names or other abbreviations/terms with JK in them).
There are ways to avoid any latency/typing sideffects, but as far as I know that is only possible by eschewing the "but functionally it should act like the terminal UI" maxim, hence the original question whether any GUI app is ready to break off the rusted chains
> So you use your most used key with a sidewise motion of your weakest finger of your weakest hand?
I'll clarify that for you, my most used individual key. Most of my typing is on the home row.
> and that's what's wrong with the native keybindings - they are simply awful ergonomically
You asked for a way to bind the keys, you got one. Now all of a sudden your problem is that the default keybindings not being ergonomical. I use vim keys EVERYWHERE to help my RSI, but to each their own.
> There are ways to avoid any latency/typing sideffects, but as far as I know that is only possible by eschewing the "but functionally it should act like the terminal UI" maxim, hence the original question whether any GUI app is ready to break off the rusted chains
This makes zero sense. My point is that there is no native way to bind hold. The latency comes from vim waiting for either a second keypress to run the binding, or typing the character. You can natively set the delay lower and I do in :termdebug, but when typing it's very noticeable at my typing speeds. You could write a plugin and one probably even exists if you want that functionality.
But please, explain how a GUI would solve that in a way a TUI can't. Very curious to hear what you come up with.
I'll clarify that for you: this is still a big ergonomic issue typing notwithstanding
> You asked for a way to bind the keys, you got one.
No, I asked for a specific way to bind keys, and got nothing ("except for holding a key") and another JK nothing you yourself don't like
>Now all of a sudden your problem is that the default keybindings not being ergonomical.
There is nothing sudden about it, it was you who asked what's wrong with the defaults.
> I use vim keys EVERYWHERE to help my RSI, but to each their own.
That's not true since the vast majority of those aren't supported everywhere, but also irrelevant - I use better keys everywhere, so?
> This makes zero sense. My point is that there is no native way to bind hold.
That's why you don't get it. Binding hold/modtaps is what allows avoiding the latency etc.
> The latency comes from vim waiting for either a second keypress to run the binding, or typing the character
Even in this case of two taps (not what I mentioned) there is no need for a wait, you can type right away and perfectly clean up later if the 2nd key is a combo. Neovintageous plugin for Sublime does this
> You can natively set the delay lower and I do in :termdebug, but when typing it's very noticeable at my typing speeds.
I don't want just the delays, that's a failed branch of key chord evolution, delays can't be perfect. I've described what I want in the very first comment
> But please, explain how a GUI would solve that in a way a TUI can't. Very curious to hear what you come up with.
By having access to all keyboard event info, not being limited by the terminal, and handling that properly. Check out kanata or google modtaps and home row mods, don't remember a link with a great description.
> I'll clarify that for you: this is still a big ergonomic issue typing notwithstanding
> That's why you don't get it. Binding hold/modtaps is what allows avoiding the latency etc.
Modkeys are how Emacs does it, but have you ever heard of Emacs pinky? Why do Emacs users swap control and escape? To me chords and modal editors are the solution. My way solved my RSI, it's definitely more ergonomic than the finger gymnastics I need with modifiers.
> That's not true since the vast majority of those aren't supported everywhere, but also irrelevant - I use better keys everywhere, so?
Use vimium in chromium, vimium-ff in firefox. Vibreoffice for LibreOffice, adding 'set editing-mode vi' in ~/.inputrc sets it for pretty much every TUI program such as gdb, sqlite, psql and so on. My window manager dwm has vim keys, neomutt for mail, newsboat for rss. For rofi and dmenu I set them manually to follow the same pattern. And the list goes on, what do you mean? Everything works exactly as expected and is intuitive to me.
Anyway, in your first comment you ask:
> Is there any complicated no-nonsense GUI for Neovim that transcends the GarbageUI of the terminals and, for example, allows you to have advanced keybinds to invoke various vim actions (like enter insert mode on tap I and exit it on hold I or modtap J+I)
The answer is yes, just use the vim way of binding the keys? The problems you mention are invented and have nothing to do with a GUI. What does a GUI even have to do with the keyboard? What am I missing, it's still unclear and I'm confused?
If you like mods just bind mods, vim supports it and I bind ctrl+p to fzf. What is even the problem? Explain it to me in a simple way don't ask me to search for what you try to say.
If you don't like neovim, or the terminal, just use VsCode like everyone else? Who's forcing you to live with something that pisses you off so much?
Modtap isn't modkeys, seriously, just google, I know you're confused, and since you keep ignoring what I write or replace my words with your wrong ones, my simple words won't help alleviate your confusion
(also ironic mention of emacs pinky when you're using pinky for one of the most frequent commands)
> Vimium in chromium
So what's your Vimium command to scroll down by two paragraphs and then select the next two sentences?
> The answer is yes
That wasn't a yes or no question
If you like neovim and the terminal so much, just stay there and ignore this GUI topic, who is forcing you to avoid the light of knowledge at the end of the Google tunnel to insist there is no problem just because you can't see it?
> Vim supports mods
So how do you bind left control p to run one command, and right control p to run another? (hint: this limitation is also terminal-related)
> Modtap isn't modkeys, seriously, just google, I know you're confused, and since you keep ignoring what I write or replace my words with your wrong ones, my simple words won't help alleviate your confusion
Don't use google as a verb, better alternatives exist. I search, and it's only 1 vowel so easier on the tongue. Anyways, setup modtap in your keyboard or OS to trigger some key, and bind that key in vim? It isn't like it's universal functionality, I've heard of it but never encountered in any program.
But that wasn't why I brought up modkeys, latency came up as a problem in insert mode right? You claim modtap is the solution for that, I don't use modifiers at all in insert mode, but there are some even in the default config. One that comes to mind is entering normal mode for the next motion then returning to insert mode. Can be useful but rarely, esc is easier.
Modtap or not is not the solution for the latency we were talking about, normal mods do that just as well. Are you following?
> (also ironic mention of emacs pinky when you're using pinky for one of the most frequent commands)
Not at all, on the contrary it proves my point. I moved it _because_ I was getting Emacs pinky. Problem -> solution.
> So what's your Vimium command to scroll down by two paragraphs and then select the next two sentences?
I don't scroll in paragraphs, I use d/u for half-page down/up, j/k for normal scroll. Hit v for visual mode then it's just standard vim motions. I don't really understand the question, obviously some things are missing if that's where you're going. I'm not going to run :keywordprg in my browser for example but that's fine, stop moving the goalposts. I love it for f/F to follow links, / to search and so on, and I don't even use half the features.
> If you like neovim and the terminal so much
I was trying to be helpful and answer a simple question but you seem to have a really bad day. Use it don't use it, I don't care. The community is fine without your energy.
> So how do you bind left control p to run one command, and right control p to run another?
I don't, I use both interchangeably to reduce strain on my fingers. As you mention yourself ergonomics are important. I avoid using modifiers unless I have to, shift is an example that is difficult to live without. They're also interchangeable.
If you really need it then work around it by replacing at the OS or keyboard level if yours supports it. Edge case that to me feels like inventing a problem to have something to whine about. What other common programs that you use support that feature? If you're the power-user you want to be you'll figure it out, everything is possible.
> Anyways, setup modtap in your keyboard or OS to trigger some key, and bind that key in vim?
How would the OS know what mode you're in? How would it know know what command is expecting input in a sequence?
> It isn't like it's universal functionality, I've heard of it but never encountered in any program.
And this is relevant how? Modal text editing isn't universal functionality, so?
> normal mods do that just as well. Are you following?
You haven't provided any explanation for your rejection, so there is nothing to follow. Like, I've listed two specific examples. Explain exactly how normal mods do it "just as well".
> Not at all, on the contrary it proves my point. I moved it _because_ I was getting Emacs pinky. Problem -> solution.
Nope, you just didn't get the irony: "Bad solution → similarly bad solution"
> Hit v for visual mode then it's just standard vim motions.
And then those standard motions select the whole comment instead of the next sentence.
> I don't really understand the question, obviously some things are missing if that's where you're going.
Bump "some" to "a lot" and you'll be closer to understanding
> stop moving the goalposts.
Yeah, do that. Listing a few commands that work moves my original goalpost.
> I was trying to be helpful and answer a simple question
No you weren't. In your ignorance you mistook a complicated question for a simple one and later proceeded to try to prove to me that my problem doesn't even exist, and it's just something "to white about" simply because you don't understand it and are fine with bad solutions because before you used even worse RSI-inducing ones
> The community is fine without your energy
Who appointed you the community representative for such baseless claims?
> I don't
That question wasn't about YOU.
> They're also interchangeable.
Unless you bind them in a convenient non-interchangeable way. I know you don't do that and can't even imagine that, but that's just your limitations
> Edge case that to me feels like inventing a problem to have something to whine about.
No, but every now and then I get out of my cave and meet people and have to use my voice. You should try it. Are you always this confrontational?
> How would the OS know what mode you're in? How would it know know what command is expecting input in a sequence?
The OS doesn't need to know what mode you're using in vim to send another key. But you could make a plugin to change the window title and let the modtap program listen for that.
I use window class and title for my window manager to handle programs differently, I don't see why a modtap program couldn't if that is something you want. Use your imagination.
> And this is relevant how? Modal text editing isn't universal functionality, so?
I'm not the one bitching about missing modal functionality in programs. That's why it's relevant, what programs meet your expectations? I see that is conveniently one of the few questions you skipped answering from my last comment, so I'm going to assume none?
> Explain exactly how normal mods do it "just as well"
Regarding latency? Not listening for the next key means no latency? But you knew this. The only reason I brought up latency was that coords are not a good choice in insert mode. Use it if you want, I don't. Don't make such a deal about something I mentioned in passing.
> Nope, you just didn't get the irony: "Bad solution → similarly bad solution"
Please tell me you're a child...
> And then those standard motions select the whole comment instead of the next sentence.
Have you even used it? Stop hallucinating ChatGPT.
> Bump "some" to "a lot" and you'll be closer to understanding
I never claimed it does everything vim does. Do you expect your e-mail client to compile programs? Emacs might be more your cup of tea, you'll never have to leave it. Most people are completely fine with the different ways different programs implement vim keys in their context, usually just movements, sometimes yank and move. It's very convenient for most of us.
> No you weren't. In your ignorance you mistook a complicated question for a simple one and later proceeded to try to prove to me that my problem doesn't even exist,
I asked why it was a problem and proposed solutions and workarounds. I'll try to ask again because I'm genuinely curious, what programs do you use that support modtap and meet your standards?
You obviously have strong feelings about a program you don't even use. What programs are not garbage and have no-nonsense UI for modtap? Do they even exist or are you just looking for a reason to whine about a program you have no intentions of using?
Do I understand you correctly? Modtap is the issue? Or is it the lack of a GUI for configuration?
> every now and then I get out of my cave and meet people
You should get out more often and meet more people, then you might stop telling people what words they should use in writing (especially with irrelevant tongue arguments)
> The OS doesn't need to know what mode you're using in vim to send another key.
Of course it does since the key is command+mode-dependent. And you forgot to answer the second question, so I'm going to assume you have nothing constructive to offer here as well.
> let the modtap program listen for that.
Which program would that be? Also, why couldn't the Vim app listen to itself, removing the intermediary? Can you not imagine that?
> I don't see why a modtap program couldn't if that is something you want. Use your imagination.
You fail to see plenty of things here, nothing my imagination could fix.
> Regarding latency?
No, regarding functionality.
> Have you even used it? Stop hallucinating ChatGPT.
Of course, right before writing that comment, I'm not as ignorant as you are and don't replace facts with imagination.
> It's very convenient for most of us
And again, this is neither about you personally nor your imaginary "us" that you feel you can speak for.
> I asked why it was a problem and proposed solutions
Not a single solution, plenty of insults
> I'll try to ask again because I'm genuinely curious
Genuinely curious people don't denigrate something they're clueless about and do not fear google so much they put a word police hat on at the first mention
You're like a dog chasing your own tail, everything you ask has already been covered in previous comments (such as how vim listens for keys from external bindings or how those bindings can know the mode from vim). I don't enjoy repeating myself and it's obvious you're not looking for solutions only drama.
I don't know what modtap program you should use, I don't use them you're the one demanding it. Do you have mech keyboard, use that? Fuck do I know, DYOR. Nothing I would suggest would satisfy you anyway and my patience ran out several comments ago.
What programs do you use and what _exactly_ are you missing in vim. Is it modtap? A GUI? I don't even know what you're so pissed about and you refuse to mention it. Be constructive or find something else to waste your time on, this will most likely be my last response as I don't expect anything different in your next one.
> everything you ask has already been covered in previous comments
No, you've covered nothing, I've pointed to flaws in your supposed solutions, but your imagination covered them. Not a single solution
> I don't enjoy repeating myself
You don't need to, you can address specific issues you keep repeatedly ignoring
Instead of retreating back to your:
> I don't know what modtap program you should use
I know, and that's the biggest problem in this conversation - you don't know a lot, yet keep imagining you do and arguing that the solution "oh must exist, just use your imagination, here is some naive kludge about window titles and mech keyboards"
> Do you have mech keyboard, use that?
So how would the mech keyboard firmware know what command and mode vim is in the middle of? Oh, wait, you have no clue, you don't use anything, so why do you keep offering all these non-solutions?
> it's obvious you're not looking for solutions
I am, that's why I asked the question, you're just not competent enough to offer any
> Nothing I would suggest would satisfy you anyway
Yes, that would require more knowledge and less arrogance on your part
> you're the one demanding it.
Quote where I demand it. That's just another one of your rhetorical fissy twists
> what _exactly_ are you missing in vim
The original comment was just one sentence, and it lists exactly what I'm missing, including exact examples. The fact that you're still clueless after so many comments is on you
> I don't even know what you're so pissed about and you refuse to mention it.
I'm pissed about aggressive ignoramuses dismissing problems and wasting time policing words and offering empty solutions because vim pinkies are fine and convenient for them.
Just to clarify to make it a bit harder for you to twist it again - I'm not pissed about the fact that there is no great keybinding support in vim GUI, great things are rare
Yes, you're right. I'm sorry vim doesn't raise your chickens and cook your tendies. What a terrible software. Your mom will have to do until someone creates something better.
See, I can also completely miss the point and act all high and mighty. It's not my problem my suggestions aren't good enough, however you've not mentioned a single solution you are happy with. How come?
> I can also completely miss the point and act all high and mighty
You've misspelled "All I can do is".
It is your problem since you're the one sticking like a flea trying to prove your suggestions are good with a sprinkle of imagination, and getting all pissy when you run out of arguments.
Be constructive or find something else to waste your time on
Can you show me on the picture where vim touched you?
The saying "never argue with idiots, they will only bring you down to their level and win by experience" has never been more relevant.
But now I'm kind of curious where this is heading, how long are you willing to keep this up? In how many ways can you say "but what about you" or repeat what I've already said?
Do you feel clever doing this?
Since the beginning you've been antagonistic about the most simple things. I'll give you an example:
>>>> but I swap esc and caps since esc is my most used key
>>> So you use your most used key with a sidewise motion of your weakest finger of your weakest hand? That's just bad ergonomics, and that's what's wrong with the native keybindings
>> I'll clarify that for you, my most used individual key. Most of my typing is on the home row.
> I'll clarify that for you: this is still a big ergonomic issue typing notwithstanding
And this goes on, and on, and on. All of a sudden 2 comments in my "stupid choice of keybindings" is the topic. You break up every sentence into 15 quotes finding anything and everything you can to get back at, why? I'm not trying to win anything here, there are no prizes or awards. Only wasted time.
What is so difficult about staying on topic? Why are you going out of your way to derail the discussion and making this about me to avoid answering a single relevant question I ask?
The idiot reference if pretty ironic, but it's not unlike you to miss it again
> All of a sudden 2 comments in my "stupid choice of keybindings" is the topic
Nothing sudden about that: you offered your stupid keybinding as an alternative to my awesome ones. And since you asked what's wrong, I've explained it. And since you didn't understand it, I've clarified it
> You break up every sentence into 15
So that anyone can follow and respond to a specific issue instead of writing more irrelevant rants. Although unfortunately that's also not idiot-proof
> how long are you willing to keep this up
This is my last, discussing your technical fails was still on-topic, now only cognitive fails remain, and that's not, so I'll stop feeding your trollish behavior
> Nothing sudden about that: you offered your stupid keybinding as an alternative to my awesome ones.
I'll bite, go ahead and show me how I offered this as a solution, quote me. I mentioned why insert mode isn't a problem for me, not a suggestion just mentioned in passing. Read it again please. Is this the problem? That you understand anything I mention as a suggestion? Did you think vimium was a suggestion as well?
What are these awesome keybindings you have if you don't mind me asking for the 100th time? I guess modtap but what program? How?
