> crashes: every week or so there’s a segfault and the editor crashes. ... This doesn’t bother me that much though, I can just reopen it.
Strange approach to data loss, since it doesn't have persistent undo, you can't just reopen it to the same editing state?
> After using Vim/Neovim for 20 years, I’ve tried both “build my own custom configuration from scratch” and “use someone else’s pre-buld configuration system” and even though I love Vim I was excited about having things just work without having to work on my configuration at all.
I don't really get it given how primitive the resulting Helix config is (I mean, even the most frequent commands are based off the mistaken unergonomic w/b defaults), presumably you would've been able to replicate it comletely in the first X years of using vim, and then there is no hell anymore?
> little help popup telling me places I can go. I really appreciate this because I don’t often use the “go to definition” or “go to reference” feature and I often forget the keyboard shortcut.
Exactly! Pity this basic contextual help isn't more widespread, every single app that uses a lot of keybind sequences could benefit from it, especially if it becomes a bit smarter and only shows a popup if you don't finish the sequence right away
> Exactly! Pity this basic contextual help isn't more widespread, every single app that uses a lot of keybind sequences could benefit from it, especially if it becomes a bit smarter and only shows a popup if you don't finish the sequence right away
I've been using Vim/Neovim for 20 years, but still can't get enough of which-key[1] which I only installed ~6 months ago.
1: https://github.com/folke/which-key.nvim
Yeah, that's the mortal sin of vim - insisting on shitty unergonomic defaults, requiring every new user waste time recreating a better UI while suffering for years before even the appropriate knowledge is acquired
I personally like Neovim's defaults since it fixes a few rough spots in old school Vim defaults.
Bonus is once you get used to defaults, almost every server has a Vi installed whose basic features you can use.
I have not seen any unergonomic defaults in vim. Check your understanding of vim philosophy probably.
Check your understanding of ergonomics if you fail to see the obvious
vi (the name) is ergonomical because of shortness (just two letters).
vi (the editor) is ergonomical because I use to touchtype and vi lets me to never put the hands out of the keyboard (typically its 3 rows but vi made me to learn the 4th row with digits).
vi (the system of text moving commands) is ergonomical because it has all what might be needed right from default.
I recommend you to start exploring vi from the following 4 commands to understand at least what kind of operations can be possible - w, b, e, ge. I promise there are some ergonomics in having all the 4 ways of one word iterating problem. After understanding what did I mean you are free to see some logic in _any_ vim command. (hint - pairness, there are almost no command without at least one complement pair).
Also there is a thing called "UNIX way" (all sayings about how one thing has to do only one task) and damn, vi clones are one of the most ergonomic programs on my PC. After mastering touchtyping using keyboard gives me pleasure, after mastering vi motions doing text editing gives me pleasure as well. Achievability of this kind of pleasure is what I call ergonomics.
GUI editors with modal windows and stealing-focus popups have too much power to destroy my pleasure from the dialogue with the keyboard.
> w, b, e, ge. I promise there are some ergonomics in having all the 4 ways of one word iterating problem.
Again, how can you promise anything if you're ergonomically blind? Take you w/b pair - this is just a dumb binding, these are two of the most frequently used commands in vim, yet they are not positioned in the most convenient location (hint: home row). The Word/Backword menmonic isn't paired (that would be forward/backward), but more importantly, it makes as much sense as binding cursor keys to Left/Up/Down/Right So it fails your own "pairness" criterion in its most basic movement!
> Achievability of this kind of pleasure is what I call ergonomics.
Of course you have your own personalized definition! Why would you use that in a conversation with others, though, when they're more likely using a more common one?
> there is a thing called "UNIX way"
it doesn't do its one thing "well", so as expected, you can't paper unergonomics over with some "philosophy"!
Your complain about w/b not laying on home row is just wrong, for example I do not use QWERTY at all and for me even h/j/k/l are not on the howe row and I still consider these commands ergonomical. Why? Because I use to touchtype.
> The Word/Backword menmonic isn't paired (that would be forward/backward)
What is paired is not a mnemonic but an action. If you start to understand that any command has a complementary command it makes your expectation from vi predictable. It happens in the following way: you learn how to do some moving you are needed, then you check the complementary action (there are 3 layers of complementarity in the word iteration problem: forward/backward, cursor on start/end and word/WORD), then you just make your muscle memory to learn what you saw, that's all!
> but more importantly, it makes as much sense as binding cursor keys to Left/Up/Down/Right So it fails your own "pairness" criterion in its most basic movement!
My thesis is that if the editor can move the cursor left then it must have an ability to move it right (and vice versa), if the editor can move the cursor upwards, then it must have an ability to move it downwards (and vice versa), nothing more. You are talking about some very specific ways to move cursor (there are plenty of them in vim to be honest) and BTW if you are comfortable with cursor keys, so why have you complained about w/b which are not laying on the home row? The home row story is about your hands laying on the keys with letters and controlling all 4 rows, not about your right hand laying on 4 keys and your left hand can not control anything except esc/meta/alt/ctrl/shift.
> Of course you have your own personalized definition! Why would you use that in a conversation with others, though, when they're more likely using a more common one?
Ergonomy is the Psychiatry domain, BTW we are not discussing ergonomic per se. We are discussion about achieving erconomic with only having some well-known instruments: keyboard, console software, display. Of course your definition of ergonomic (which you did not worked to write down here) is about wearing a hat which just reads your thoughts and outputs the correct result, but I tell you about some ways of achieving ergonomics on the hardware you obviously have, I don't tell about dreams of perfect world.
> it doesn't do its one thing "well", so as expected, you can't paper unergonomics over with some "philosophy"!
I promise I do not lie, I am teaching some people offline to touchtype and to use vi(m), but I can not teach you if you don't even ask questions. I write this comment because I work on a book about vi for noobs and I will never get tired to introduce people to see some ergonomics in the things I love which seems obscure to them. For example, if you didn't fire a single bullet you will never see what firearm products are ergonomic and what are not. If you didn't fire a single bullet towards the real enemy you can consider AR (full of bells and whistles) as ergonomical, while in reality what is ergonomical is AK (doesn't jam under the rain, doesn't afraid of the mud, allows to fire knippels against the drones instead of regular bullets). If you have never danced Salsa, you will never understand how the lead is leading and why the follower follows.
PS. Sorry for my bad English, this is not my native language and I am too lazy to polish my grammar with some modern tools. Sometimes I might misunderstand you or write down not what I really think.
Can you give at least a few examples? I have no understanding of ergonomics it seems
There literally is a plugin [1] containing sensible defaults that everyone in the community agrees would be good as default but “backspace” and “incsearch” are the most obvious. “Backspace” allows you to delete with the backspace key beyond the point where you pressed “insert”. I don’t think I’ve ever met someone who thinks the vim default (not allowing this) is ergonomic.
[1] https://github.com/tpope/vim-sensible
Have these already been adopted in neovim by default? It seems like I already have this behavior without needing any plugins.
I wouldn't argue that the vim default (of not allowing backspace beyond where you entered insert mode) is ergonomic, but I do prefer and exclusively use the default vim behavior. It's just what I'm used to at this point (24 years using vim/nvim) and if I set it the "ergonomic" way, it's disorienting.
So, ergonomic or not, some people do prefer the default -- at least one person :).
You can start with the original example 4 comments above and try to understand how unergonomic the default way of learning/remembering hundreds of key combinations in vim is.
Then think about the basics: why some of the most frequently used commands w/b are located so inconveniently and far away from each other (and if you reconfigure them, how unergonomic the config language is where instead of reading a sensible name like 'move_prev_word_start' you can only reference 'b' that you'd never use since, well, you've changed it to something else!)
You don't need hundred of commands to use vim, have you at least finished vimtutor? Finish it in the way it proposes, then start it again and think on your own, what commands for more effective passing the problems from vimtutor might have been there as well.
Letters w and b may be located wherever they are located, if you can not touchtype vim is not for you for the same reason we do not learn how to run before we master how to walk.
mini.clue is another good option for this feature in neovim.
https://github.com/nvim-mini/mini.clue
The mini set of modules are such a treasure, Evgeni is amazing.
I think you completely missed the context for the configuration issues in vim:
I’ve been trying to get a working language server setup (so I can do things like “go to definition”) and getting a setup that feels good in Vim or Neovim just felt like too much work.
Getting LSP to work on recent versions of Neovim is one plugin + one line of configuration. Here are the steps for enabling clangd:
1. Install nvim-lspconfig plugin
2. Add `vim.lsp.enable("clangd")` to init.lua
You can even enable LSPs on a per-project basis by taking advantage of the revamped exrc feature:
1. Add `vim.opt.exrc = true` to init.lua
2. Add `vim.lsp.enable("clangd")` to $projectdir/.nvim.lua
You don't even need the plugin nowadays, you can just go to the lspconfig repo and copy paste the default config if you don't know where to start. lspconfig was an incredible effort, and I consider it a good thing that it is now fading into a simple repository of default configurations.
I'd say that having a plugin with default configurations that is kept updated is a necessity. Because that's what enables me to use LSPs with a single line configuration.
Serious question: how often does a sensible default configuration need to change? I think I have used the same jedi-language-server config across projects and computers since before Neovim had a built-in LSP client, with the only changes being on the Neovim side gradually migrating to new features as they appeared.
Obviously do whatever works for you. But I do feel like most LSPs shouldn't need more than a few lines that you set and forget.
Well, LSPs come and go so that's one source of churn.
It might have been a bit harder in the past, but with recent versions of neovim (>=0.11) it's less than 20 lines of configuration. I have quite a few keybindings to jump back and forth through errors and the default keybidings already include things like renaming, go to definition or listing references.
I'd be more than happy to help you configuring it to your needs.
FWIW, in my (emacs, C++) experience, writing the editor config is a relatively minor part of the yak-shaving required to have jump-to-definition on an actual work codebase.
I had to get my project to emit compile_commands.json, get clangd, figure out which things about our build process clangd was not understanding from compile_commands.json and add them in .clangd. All to achieve a level of functionality significantly jankier than just opening the damn .sln file in Visual Studio.
Once I did all that it was, as you say, very little actual stuff written in my .spacemacs. And probably could have been less if I had felt like figuring out how to get my windows emacs to find clangd on the path instead of giving up and just specifying full paths to everything.
I only persevered because emacs (unlike Visual Studio) gives you all the necessary access to its internals to build LLM Tools around its LSP functionality.
Whatever vim is in rhel 8 supports ale. Ale with rust has been great. Go to definition is flawless, all my conpile and clippy errors are underlined as I type and binding a key to ALECodeAction will apply the auto fix if it has one. Usually that is to import whatever I just used, which vscode would do automatically, but still its nice and having vscode use clippy as well as check bogs it down. And ale runs cargo-fmt on save. So yeah, nothing I'd wish different from it.
Edit: upon further thought, I don't like having to move my hand to the arrow keys to select from the auto complete list, even if there is only one thing and then hit enter, rather than hitting tab to pick whatever is left.
> upon further thought, I don't like having to move my hand to the arrow keys
ctrl-n and ctrl-p should let you select next and previous from the autocomplete menu while avoiding the arrow keys.
I haven't used clangd myself, though, so I can't say either way, I just know ccls works well.
By convention I tend to have the generated build system in build/ at the top-level of the repo so that the file is at build/compile_commands.json. That, or I'll arrange to have a symlink there pointing to one generated elsewhere.
The nvim snippet I use in my init.lua to setup ccls to work in that scenario is:
My actual config does also contain a capabilities = ... argument that forwards the default_capabilities() from nvim-cmp, but you get the point. I hope that helps in case you're curious to give neovim another spin.I did actually try CCLS first, but this was several years ago so it's possible that it may work better (something about our codebase was causing it to crash) - I should try it again.
Lacking LSP didn't stop me from using spacemacs, though. Oh, no. emacs has an auto-complete mode that just chooses from a pool of symbols already present in open files and that turns out to be Good Enough for me to prefer editing code there vs Visual Studio, IntelliSense be damned.
My employer furnished me with a beefy enough workstation that I can have Visual Studio open (to semantic search the whole codebase for stuff I don't already known where to find and to build/run/debug) alongside emacs (for editing and general code browsing when I know where definitions live).
This. Now that LSPs are natively understood by neovim it's a very painless process. Especially if using mason to fetch the language servers.
> presumably you would've been able to replicate it completely in the first X years of using vim, and then there is no hell anymore?
I agree with this, but being able to ssh into a server and just grab Helix instead of copying over my Vim config and whatever else it depends on is really nice. Makes your dev env feel a lot more portable (although also more barebones than a crazy Vim config)
It's not like Helix is as ubiquitous as Vim on a random remote server. If that's not the case surely the effort to install Helix is bigger than copying Vim config?
I've had trouble in the past with systems whose version of vim is too old to understand the options in my config.
this was my plan, but then i got really into using LSPs and i'm not about to install every LSP on every server i ssh into.
Currently i just use sshfs to mount whatever directory i want to work on locally, nice to have all lsps available and also see my changes reflected on the server instantly.
How is so? I have my dot files in GitHub. I just have to clone, run `PlugInstall` and it's all ready.
Glad it works for you! My dot files are in a private repo, I don't want to bother with adding new SSH keys to my GitHub account and then remembering to cleanup everything for what could be a one-time use. `apk add helix` is way easier for me.
>> little help popup telling me places I can go. I really appreciate this because I don’t often use the “go to definition” or “go to reference” feature and I often forget the keyboard shortcut.
> Exactly! Pity this basic contextual help isn't more widespread, every single app that uses a lot of keybind sequences could benefit from it, especially if it becomes a bit smarter and only shows a popup if you don't finish the sequence right away
I agree 100%. This would be helpful in so many places. That was my favorite part of the article -- one little paragraph and screenshot, but it made me desperately crave that feature almost everywhere. I agree that it'd need to be smart about it -- after a timeout, as you mentioned, is a great idea. That way it can stay out of your way if you know what you're doing, and only pop up when you hesitate.
Neovim with lazy.nvim has that by default (delay included).
I'm not Neovim person, but would you happen to know what plugin provides that feature?
Sorry I'm exhausted and lazy.nvim is the package manager, but I meant lazyvim which is the distribution. Within this distribution I'm pretty sure it's which-key that provides a popup. If I type <leader> it pops with suggestion (and a little icon in front of each indicating if the next key has sub-commands or not).
folke/which-key.nvim: https://github.com/folke/which-key.nvim :
> Customizable Layouts: choose from classic, modern, and helix presets or customize the window.
LazyVim keymaps: https://www.lazyvim.org/keymaps
I've been using Helix daily for about three years, and it has crashed about five times. It is very, very rare for it to SEGFAULT.
> every week or so there’s a segfault and the editor crashes.
The author of the OP appears to have edited it to indicate that it's just crashing, and doesn't know if it's a segfault or just a panic. It appears there is some known potential for segfaults in tree-sitter, which is a native C dependency.
I have had treesitter crashes in the past editing markdown, causing helix to segfault, but the particular bug that caused my crashes has been fixed since years.
> every single app that uses a lot of keybind sequences could benefit from it, especially if it becomes a bit smarter and only shows a popup if you don't finish the sequence right away
Counterpoint: the sequence should only have an opportunity to be "unfinished" if there's actually a choice to make. Showing too many choices at once can be overwhelming and in the Vim environment there are usually a ton of choices. Consider for example if I input `n10` in editing mode; that could be followed by all kinds of repeatable actions and it could be followed by another digit of the count.
> if there's actually a choice to make.
I don't get it, there is always a choice to make, which is which action to continue with?
> Showing too many choices at once can be overwhelming
It can't be more overwhelming than having to remember all of those choices and using external docs/configs to look them up! Besides, it's not like there are no improvements possible and you have to show everything at once. For example, all your "all kinds of repetable actions" can be limited by the most frequently used 10 actions and an "others" submenu you could invoke separately if you were looking for something else. And your "another digit" is just a single line "0-9 continue the count", so what's the issue there?
> I don't get it, there is always a choice to make, which is which action to continue with?
The point is that if the input for a command is XY, there had better also be an XZ. Otherwise XY should just be X.
How is this relevant to the tooltip conversation? If you have XY (without XZ) instead of just X, well, maybe you could simplify, or maybe it still makes sense for you for some reason, whatever, in any case you'd appreciate immediate contextual help if you press X and then forget that Y is the finisher.
Because if the command is just X then you just input X and the action occurs. There is no need for "immediate contextual help" because there is no time wasted on a useless immediate context.
It's bad UI design to have the user input X and then wait for Y before doing anything when there is only one intention the user could actually have in mind. Having a popup say in effect "hey, I'm not going to do anything until you press Y" is not an improvement.
> input X and then wait for Y before doing anything when there is only one intention the user could actually have in mind
That's obviously false, the second possible intention is... cancellation. For example, you can bind Q,Q to quit the app (and no other key is prefixed with a Q), but then you could press Q mistakenly or change your mind at the last moment.
But you continue to argue with your own strawman - nothing about helpful popups changes the underlying behavior. So if your magic design is to run XY just on X press, that would be bad design, but you can still do it! And the popup will never appear because the action is complete, so no help needed.
You’re going to hate that my shortcut for Normal mode is j-k, and I don’t have any other j-* commands.