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
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.
Bonus is once you get used to defaults, almost every server has a Vi installed whose basic features you can use.
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.
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"!
> 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.
So, ergonomic or not, some people do prefer the default -- at least one person :).
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!)
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.
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.
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
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.
I'd be more than happy to help you configuring it to your needs.
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.
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.
ctrl-n and ctrl-p should let you select next and previous from the autocomplete menu while avoiding the arrow keys.
> 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
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:
vim.lsp.config('ccls', {
init_options = {
compilationDatabaseDirectory = 'build',
},
})
vim.lsp.enable('ccls')
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).
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)
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.
> 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.
> Customizable Layouts: choose from classic, modern, and helix presets or customize the window.
LazyVim keymaps: https://www.lazyvim.org/keymaps
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.
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?
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.
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.
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.
For me, after trying the Lazy neovim plugin distro and being a long-time vim user, Helix fills a unique need:
- It's beautiful (lots of attention to detail) - It's fast (meaning: at no point did I think Helix is slower than it should) - It's hugely ergonomic (each default keystroke resonates with me and the modal selection is a boon for my brain and productivity) - It requires almost no configuration out-of-the-box
I can't be bothered to use neovim and configure it, and vim doesn't cut it. I need something in the middle between nvim and VS Code, and that's Helix for me. This might have been different had I been a vimscript wizard, which I'm not.
I don't need Helix to be more modular or UNIXy, I simply need it to keep on the direction they've taken. There's a thriving ecosystem of tools around it, and I can use it with Claude Code (by simply refreshing the buffer when there's a new edit). What else can I ask for?
Helix is a great editor, one of the very best I've ever used. As a result, I started chipping in monthly money to keep the project going.
In terms of future improvements, the only one I'm missing the most is the ability to render images or math formulas from the editor, which I hope can at some point be done through a plugin using Kitty's terminal protocol or sixel. This is especially handy when working on Markdown files for notes or blog posts.
Long live Helix.
No matter if VSCode or (neo)vim, needing tens of plugins from almost that many different parties always made me feel quite uneasy.
So, I kind of agree with you, but that’s still a lot of dependencies baked into the editor. It’s probably not as bad as Neovim+plugins, but it’s still a supply chain issue.
305 with helix- removed
258 with gix removed (git stuff in multiple packages from a single upstream group)
240 with windows api wrappers removed.
170 if you remove all subprojects (split on -/_ taking first field, then uniq).
fast math and various hashes
backtrace utils
various build utils
some allocators, zero copy facilities, mmap and structures like lrus
time and date handling
character maps / internationalization
concurrency libraries (futures, runtime, etc)
cross platform path & directory helpers
support for general unix platforms, for redox, for linux, for windows
logging infrastructure
some compression libraries
markdown
various testing helpers
rope string representation
shell lexer and utils
terminal interaction models
toml
wasm & wasi
so where's the rest? well the rest is in the project: tokei says helix contains 132kloc. tokei says neovim contains 984kloc.
so round a little and you get: helix has an order of magnitude more dependencies, but also an order of magnitude less code than neovim.
while I'm sympathetic to concerns around dependency bloat, particularly with an eye to the js ecosystem and supply chain security, it's important to look through the right lens - when the functionality is fairly closely equivalent (there are differences, helix has a lot more modern features, vim has a lot more traditional text manipulation and unixy integration features), and there's an order of magnitude tradeoff in both directions - this is likely demonstration of fairly effective code sharing in helix.
there are important supply chain safety techniques required when using a wide number of disparately owned dependencies. there are also important supply chain safety techniques required when managing a wide number of disparately owned sub-directories of a larger project. there could just as well be a needle in neovims vimscript haystack as there is in helix dependency stack, i can tell you now though, as i'm familiar with almost all of helix dependencies i've put eyes over their code at least once, there's almost certainly been more eyes on helix deps recently than on neovims vimscript - though eye's passing over don't always catch things either of course.
IMO that was the biggest motivator to switch was helix’s well put together lsp/lint config.
- Code actions on save, for example adding Go imports: https://github.com/helix-editor/helix/pull/6486
- Fuzzy search with a filepicker like telescope+rg, seems to have been added earlier this year: https://github.com/helix-editor/helix/pull/11285
- Automatically updating buffers when the files on disk change (claude, templ, sqlc, etc): https://github.com/helix-editor/helix/issues/1125
- File tree in browser, which has been rejected in favor of a plugin system which has not materialized yet: https://github.com/helix-editor/helix/pull/5768
There were a number of other things too, that I could have lived with. I guess I'll try again in a year or two.
> Code actions on save
There are command on save hooks which solve the problem for Go, but I could see this being not as applicable for other languages.
> Fuzzy search
Man, I'm pretty sure this shipped before telescope was particular stable or popular. Although, I don't recall if Helix originally used the ripgrep backend at first. They reworked it earlier this year and it was a massive improvement.
> Automatically updating buffers
+1 to this. I constantly suspend (ctrl+z) my editor and sometimes forget about it and could really use this prompt.
> File tree in browser
Space+e or Space+E opens a hierarchical file explorer on HEAD, but this is definitely relatively new
However, when you already have a fuzzy-search based file picker built in, an explorer doesn't bring much extra utility.
I bounced off after a couple of hours because 35 years of muscle memory for vim commands meant I was making constant infuriating mistakes[0]. Which is a shame because I'd really like to use helix and avoid the neovim config faff.
[0] I did try one of the "vim keybindings for helix" but they were only partially correct and that annoyed me even more.
[keys.normal.space.f]
f = "file_picker_in_current_directory"
F = "file_picker"
b = "file_picker_in_current_buffer_directory"
"." = ":toggle-option file-picker.git-ignore"
g = "global_search"
e = "file_explorer"
r = ":reload-all"
x = ":reset-diff-change"
w = ":echo %sh{git blame -L %{cursor_line},+1 %{buffer_name}}"I think this is catching me off guard. Especially in the past 5 years there are Neovim distributions that make this extremely easy to configure.
I am not disagreeing that many (most?) developers don't want to spend time debugging their editor - they just want it to work batteries included (or a simple button click to install). I think this is why JetBrains products are so popular (I still don't understand VS Code - it's the worst of all worlds between vim/emacs and Jetbrains).
But if you've been a (neo)vim user for 20 years, it sounds very odd that you haven't successfully gotten LSP to work in a way that feels comfortable. I don't want to assume things about the author because I do not know them, but it feels unfair to say for vim and doesn't strike me as honest.
As a similar example, I could never be bothered to install and configure any LSPs even though I've been using vim for more than a decade. The friction of doing that was always just a little bit higher than installing a full blown IDE when the work actually requires high level LSP functionality.
If someone is new to vim, I 100% agree that it's easier to get started with VSCode/Jetbrains/etc.
But if someone has been using vim for a long time as their default editor, especially Neovim, and when LSP support came to Neovim about 4 years ago [0], it comes across as someone who isn't a power user if they didn't end up installing it. Which is fine, but the community has also started to build reasonable "batteries-included" distributions of Neovim (LunarVim is a great example) if someone didn't want to figure it out themselves but still wanted to use it.
It's one thing if someone just doesn't love the experience Neovim brings to them. That's reasonable, because it's subjective. But it is odd to use a tool for so long and not further investigate what it offers to fit your needs. Before LSP, there were libraries (CoC for example). And if it was never satisfactory, why not look at alternative editors which had their own flavors of indexing/code navigation?
--
[0]: (https://github.com/neovim/neovim/commit/a5ac2f45ff84a688a094...)
They can be easier to get started with than just installing Neovim from scratch. But they add their own complexities. First, you have to know that they exist, and pick one. Then you have to know how to configure them, they may have their own nuances about how things are done. Under the hood they're using all the same packages, so you'll need to learn how to configure those as well if you don't want the defaults.
I would say the distributions to make it extremely easy to get started with a functional IDE experience with LSP features. But they're not without their own learning curve.
Also it might be the fact that vim was never my main programming tool when IDEs were available for the programming task at hand. I debug as much as I write code, so having the debugger in the same context is important to me.
These things may all sound like excuses, but what I'm trying to convey is that vim can be a tool with which someone is proficient, but it's not the main one for writing code, and as soon as friction gets higher, it gets disregarded in favour of something else.
I hope they're happy using helix tho
Also, Emacs and Vim is very much about making the tool your own. I don't mind shaving the yak every now and then, because once an inconvenience is solved, it stay solved.
I also took pause at the claim that LSP was the issue. Neovim + treesitter + LSP feels... fairly solved at this point? It was definitely a bit rough 5 years ago, but it's pretty smoothed out now. Not sure where that opinion is coming from (and it feels at odds with everything else I've read from jvns, to be honest!)
Vim is better of course it’s just hopeless to get people to use it.
By the way - I actually generally think this is a good thing that companies standardize on something. I might not like the choice they standardize on, but the barrier to entry for new engineers is already high, so having an easy-to-use and familiar development setup that "just works" from the start is pretty reasonable for large companies.
One major drawback of the noun-verb approach is its inability to support repetition using the `.` command, which is one of my favorite features in Vim. I often find myself doing something along the lines of `dd..`, `dap..`, `<Ctrl-a>..`, or `/foo<Enter>cgnbar<Esc>...un...`.
More importantly, noun-verb editors have a shortage of usable keys. Too many common operations require the use of the alt key, and that bothers me a lot. This seems inherent to the noun-verb model.
To expand on this, Vim has normal, visual, and insert modes. Noun-verb editors only have visual and insert modes, resulting in fewer options for key assignments. To exacerbate the issue, noun-verb editors have no distinction between motions and text objects. This means they must map text objects in visual mode, whereas Vim only needs to map them after some verbs. So noun-verb editors uses up more keys in less modes.
(As to the rest: I use a pretty minimal set of plugins and I use the built in nvim C-o/C-p or C-x C-o/p "dumb" autocomplete. At least I think it's built in...)
To answer the question: it's a feeling, like lots of things in software development. I tried "no syntax highlighting", found that I liked it, and I no longer use syntax highlighting. To say "specifically" how it's "better"... I'm not even saying it's better. "I like no-syntax-highlighting" is the statement I'm making (which, when it comes to syntax highlighting, is a statement a lot of people have issues with). So, from my personal experience, I take issue with the statement that no-syntax-highlighting is making things "difficult for the sake of it".
Try this out for analogy: I ate Red Baron pizzas every Friday night for 15 years, then I heard about homemade pizza 10 years ago. I tried making homemade pizza. It was good! ("I tried it and liked it") Now I only eat homemade pizza on Fridays. How is homemade pizza specifically better? It's better because I like it more. That's all there is to it. It's a preference.
(For the analogy to work, you have to like or at some point have liked Red Baron frozen pizzas. I happen to like them... the analogy is flawed though, I admit!)
(Let me preempt criticism that I'm comparing Red Baron frozen pizzas to syntax highlighting. I am not. It's only about the preference, not the object of the preference.)
I have my editor configured with zero highlighting for keywords and syntactic elements. Admittedly, I have compilation/lint/syntax/type check errors set to invert the erroneous block, black background white text.
Syntax and keyword highlighting is just noise given I’ve been trained by decades of colourblind unfriendly interfaces
And I'm using more my mental idea of the code and direct line:column navigation. My context is often less than 10 lines of code.
I'm not saying you need every plugin ever, but autocomplete?
Maybe you haven't tried "advanced" editors in a while, and it was a lot worse last time you tried?
The trick is to avoid idle browsing of the code. Be intentional about what you need to do.
I use tools like grep/ripgrep to get a more focused of the code. Then with the line number, I can jump directly to where I need to be. Same with tools like linters and compilers.
In the same file, I often use search instead of line/character movement. You search for a symbols and you just cycle through their location.
I don't think it leads to a better code. But badly organized code will make this harder, so you tend to think about organization.
Re: syntax highlighting, I don’t know how people can work with their harlequin-on-LSD themes that are a constant distraction with no semantic benefit. I have gravitated around mostly mono or duochromatic themes, while 99% are a vomit of colours. I still don’t get why variables or function names need a distinct colour.
Can’t really justify it at work though, projects are too big to and gnarly keep in my head.
With nvim 0.12 (nightly) I've switched to vim.pack (built in plugin manager) and the only plugins I had to install are mini.nvim and lspconfig.
https://helix-editor.vercel.app/
Significantly more pleasant to look at than the OG docs and he includes some nice tips and tricks, e.g. recipes for efficient editing and keybinds that help mitigate the lack of a built-in terminal.
Clearly I've been able to have seperate modes in my mind for "traditional" keybindings, as I don't find myself having difficulty switching from a text field in my browser or chat apps and then going to vim and back, so I wonder if it's just a case of the helix muscle memory needing to be so ingrained, or if it's just in an uncanny-valley to the vim experience.
My personal journey:
2010-2014 - sublime text
2014-2017 - vim and later neovim (bunch of plugins to resemble IDE-like experience)
2017-2024 - jetbrains (intellij idea with language plugins mostly)
2024-now - neovim (with lazyvim)
I tried helix in 2023 but it did not stick. Do not remember details but remember the final impressions of having to train muscle memory to “awkward” vim-like key bindings and dealing with various annoyances and bugs. End of trial and error I left it as a terminal $EDITOR for quick and adhoc tasks while doing all the heavylifting in intellij. Ditched it finally when vim muscle memory and hx muscle memory made my brain short circuit several times in a row.
Now I am back to neovim and it is surprisingly as productive (when equipped with proper plugins) as the beefy jetbrains IDEs.
That said, helix looks promising. Maybe it’s the next big thing, who knows)
You'll get an error if the session doesn't exist but it's easy to dismiss. There are probably plugins that do this in a more seamless way though if you prefer.
And thats the thing. Neovim (vim) is about the unix way, use existing tools and use them from vim.
Last time i checked this was not an option in helix, and some very trivil things was impossible, like populating the quickfix (is it a thing n helix?) from a makefile command.
Bottom line is helix is basically a stipped down version on vscode, and wont really succeed without a plugin system (and when/if it lands, its basically just a vscode alternative)
Kakoune fully embraces the unix philosophy, even going so far as relying on OS (or terminal-multiplexer, e.g. kitty or tmux) for window management (via client/sever, so each kakoune instance can still share state like open buffers).
A comparison going into the differences (and embracing of the unix philosophy by kakoune) by someone who uses both kakoune and helix: https://phaazon.net/blog/more-hindsight-vim-helix-kakoune
Sensible defaults and easy setup are a big deal. No one wants to fiddle with setting up their lsp and tree-sitter. There's probably more to their differences in popularity than just this, though.
I think the philosophy of delaying the plugin system as long as possible is one of the reasons helix has achieved that.
With Helix I just have to learn selection first, and few different binds compared to vim. With Kakoune, I have to onboard into a more complex ecosystem, in addition to that. A lot of people already have vim/neovim config fatigue so that's not very compelling.
In Vim you can for example do "dap" to delete around a paragraph, but you cannot easily invert it ("pad") because 'p' is too common and is already bound.
You can also easily do the "select first" in Vim by first pressing 'v' to start a visual selection, so I just don't see the point.
My biggest beef with Kakoune’s editing philosophy is that it seems to emphasize “editing in the large” as its preferred mode of interaction. This is totally backwards to me. Editing in the large (making multiple identical edits throughout a buffer) is a rarity. Most edits in day to day use are single edits. So the fact that Kakoune likes to leave a bunch of extra cursors in your wake (like a trail of breadcrumbs) as you jump around a file to make single edits is extremely infuriating to me, like it’s trying too hard to be helpful.
The irony of Kakoune using a clippy-style contextual help window is not lost on me!
I've been using vim for 25 years, my muscle memory isn't going to tolerate switching to a whole new text-editing "language" at this point. But I could perhaps learn to live with a new dialect.
Not sure what "trivial" is trying to convey here, but in any case personally I would put quickfix list as a rather advanced feature. Like in the excellent book Practical Vim[1] its covered in chapter 17 on 21 chapters.
[1] https://learning.oreilly.com/library/view/practical-vim-2nd/...
It has tabs if you add (the completely undiscoverably named) bufferline="multiple" to the [editor] section in config.
My requirements:
- language support (syntax, formatting)
- lsp (I want the goto definition)
- file browser
- quick jump (fzf...)
- a little bit of eye candy, nice fonts and a few icons to make things clear
- auto reload if file changed externally
- splits I can manage with the keyboard
- persistent undo
- in terminal or with excellent SSH remote editing
I would love to have an editor with better defaults. I don't mind learning something good and robust if it will serve me for years.
- I use Neovim in the terminal, so that's where I configure the font (Hack Nerd Font Mono) [1], which I install via homebrew on macOS[2].
- LSP: Can't recommend mason.nvim and mason-lspconfig enough. Install LSP servers with mason.nvim, and then mason-lspconfig handles automatically configuring and enabling whatever you've installed.
- I'm using mini.icons[3]
- For the file browser, I highly recommend Oil.nvim[4], which I discovered from this video by TJ DeVries[5].
- I was using fzf-lua, but switched back to Telescope because it was a better fit for me personally (I missed C-k to automatically append a file glob to live_grep. I missed being able to toggle the previewer. I missed being able to hit Esc and move around the picker input box with Vim motions)
Might be misunderstanding "splits I can manage with the keyboard", but (Neo)vim is pretty configurable here! I actually just use the default keybindings of e.g.
- `C-w` then HJKL to move
- `C-w C-v` to open a side-by-side (vertical) split
- `C-w C-q` to close the current split
- `C-w C-o` to close other splits (make current split the only one)
- `[NUMBER] C-w C-w` to jump to the [NUMBER]th split.
- `C-w o` to jump back to the last split you were at
[0] https://github.com/wilkystyle/nvim
[1] https://www.nerdfonts.com/
[2] https://gist.github.com/davidteren/898f2dcccd42d9f8680ec69a3...
[3] https://github.com/wilkystyle/nvim/blob/db16245731dea45f0c58...
Right, I saw some people share some snippets here before. But none of them act like Sublime does. I can't double-click a token and Ctrl + D to select next instances of it in my file.
you select a token, then pess alt+s to select the next instance and so on
Also, I can't immediately start typing like in Sublime to replace the content. For example:
"test/filenameA.c"
"test/filenameB.c"
"test/filenameC.c"
"test/filenameD.c"
If I select test/ with the cursor, then A-s, it won't select 3 and 4. If I do this, however:
C-d = ["search_selection", "extend_search_next"]
It does select test/, in all 4 lines, but I can't immediately type "blah" to change test to blah.
I’m not sure if replicating Sublime’s Ctrl + D is possible or not, but there are other ways to achieve every use case for it I can immediately think of. e.g. I think I’d typically be doing `<space>h` to select every instance of the symbol under the cursor, or using `s`elect to reduce a selection to a match, possibly yanked and pasted.
C-n = ["search_selection", "extend_search_next"]I was curious about what could it be.
Then you mention it doesn't have two essential behaviours that I am used to, and I wonder if these people just know vim and cli editors and that's why they have such opinion. Because I am also a SublimeTexter.
After 10 years of writting software, i know exactly what i want out of my IDE, so i took up a clean (completely clean) neovim and started building every single functionality by myself exactly as i like it. I call it, jokingly, unlazyvim.
I had been using vim for many years, but finally, after so many years my editor feels like a fine glove. Don't look up my code, don't ask what I built. Go build your own.
For many years I’d mostly been using a GUI version of vim/neovim, so switching to actually using an editor in the terminal was a bit of an adjustment."
For a long time my pain with this was that I often want to open an ephemeral editor while not losing context and sight of my terminal.
With a GUI editor you always get a fresh window, but in the terminal this is difficult.
Luckily
zellij edit
bind-key j command-prompt -p "vim:" "new-window -c '#{pane_current_path}' 'stty -ixon -ixoff && vim %1'; select-pane -T '%1'"
There are other things too, like pressing `*` then using `:%s` is no different than the behaviour they describe. I use a plugin that shows you all the updates live as you type making it essentially the same as multiple cursors (for this example). The only difference is that you're typing on the command prompt as opposed to the current line.
I really liked helix, but the problem is that pretty much everything I use is setup using Vim bindings (shell, browser, ideavim,...) so switching to helix concept of editing was different enough to require effort, but close enough that it screwed up all my other muscle memory.
But ya, I'm way too invested in Vim to bother with Helix. I have years of scripts and plugins I've written. I can't even be bothered to switch to nvim (I tried once and was not fun).
The way :s works in Neovim looks like multiple cursors to me, but I’m not familiar enough with Helix to know what the difference is.
For example, typing `w` select the word. However, typing `2w` select the second word and not two words. To select two words you have to enter in visual mode (`v2w`). To remove two words you thus need to type `v2wd` or `wdwd`. In Vim you can type `d2w`. I miss this composability. In Kakoune (one of the main inspiration of Helix), you can type `2Wd` (`2wd` has the same behavior as Helix).
I was also hoping that the use of Ctrl/Alt modifiers be completely removed. Why not fully embrace modal editing?
Fun fact, Vim has built-in integration for grep-like tools via the `:grep` command.
For Neovim, it checks if ripgrep is available and uses it out of the box. For Vim, you can add this to your .vimrc:
if executable('rg')
set grepprg=rg\ --vimgrep\ --hidden
endif
Likely fix here, coming soon according to the last comment: https://github.com/helix-editor/helix/pull/11738
fzf-lua (and several other picker plugins) provide really powerful features and ux out of the box.
I understand that configuration can seem overwhelming but investing a few hours will be really rewarding. I love (neo)vim
Back when I explored helix as a long-time vim user, I had some LSPs set up with neovim. But I was very much in doubt how to take advantage of these LSPs and what kind of configuration options make sense. The "hard" part is understanding what LSPs can do for you and what kind of key bindings I need to set up, so that I can use the relevant features.
Helix gives you a sane user interface to LSPs that is discoverable
> "Using vim/nvim for 20 years". "cba to configure LSPs its too hard". What?
Nowhere did she say that she tried and failed to set these up. Your comment indicates that you read it as her saying that it's too hard to do. Where did that come from?
She said it "felt like too much work" which is A) unrelated to difficulty and is B) something that you can say after you've done the thing, just as legitimately as you can say it before you do the thing.
Being able to recognize that something that works just fine but isn't right, and not being satisfied with that is a skill whose importance is difficult to convey. It is related to the sense people get after a while that gives them an allergy to unnecessary complexity. Complexity is fine if it is required. The zero-step LSP set up procedure for Helix proves that the multi-step LSP set up procedure for vim can be improved.
Is it? It isn't to me. It's expected, to me. As I've gotten older I've gotten much, much less tolerant of convoluted and unnecessarily complex hoops (which I collectively call "bullshit") that must be jumped through in order to get something working. Especially when there is an alternative nearby which puts me through zero hoops.
When I was young and Linux was brand new I had all the time in the world for compiling, patching, debugging, fixing, compiling, testing, deploying, logging, parsing, notifying, writing tooling and customizing. As I enter my 6th decade I have zero time for most of those things. The mere thought of that kind of thing today for almost all software is anathema. And anything that makes me do anything that should have been sorted out by the software author but wasn't immediately goes to the bottom of the list of consideration for any purpose in the future.
Not to take away from Helix, which I think is a cool project. But I think it's greatest strength is that it can (and should) be more than a vim rewrite in Rust. It can actually get rid of the legacy parts of vim and redo the things which did not work and integrate modern features from the beginning.
Helix is actively inspiring Neovim to become a more comprehensive baseline. Which is freaking awesome. One day the ootb experience will be so good with neovim that few will care for these "zero config" distros.
For all the Vim similarity, inverting the do-this-to-that seems like an arbitrary annoyance that I don't understand. Why go from "change this word" (cw) to "I want to change this word, so I'm going to select it first, then change it" (wc). I mean, it's not a big deal, especially if you're not already using Vim, but why THAT of all things? The difference is [explained] but the reasoning behind it is not.
Also the docs mention zero configuration but the first thing I had to do was find out why the LSP wasn't showing any information and then create a config file to fix it because the default behaviour doesn't show anything from the LSP, which makes it seem like it's not even there.
And there's no :help command.
Maybe it's a great editor, but I guess they're not targeting existing Vim users for conversion.
[explained]: https://docs.helix-editor.com/from-vim.html#migrating-from-v...
> why THAT of all things?
Because that's a fundamental improvement
There were a few blogs with more detailed explanations, not sure about Helix, but kakoune had it covered https://kakoune.org/why-kakoune/why-kakoune.html
> Kakoune tries hard to fix one of the big problems with the vi model: its lack of interactivity. Because of the verb followed by object grammar, vi changes are made in the dark, we don’t see their effect until the whole editing sentence is finished
but, this is probably less important than the simplicity of the selection first model, as it ties into multisel, etc. a selection is a cursor and an anchor. other keys manipulate the selection(s) in very particular ways, which are predictable. external tools interface easily with the selection format, as it represents cursors and anchors.
each benefit taken alone is quite small, but together they offer kakoune a very lean, predictable design when combined with its use of external programs for tasks like sorts or paragraph reflows.
helix is similar to kakoune w.r.t. the editing model. kakoune has `w` to select the next word (and move the anchor to the start of the next word), and `W` to select the next word (and keep the anchor where it is, so you now have two words selected). helix has `v` to enter visual mode, which is essentially equivalent to caps lock with kakoune --- `vw` in helix is equivalent to `W` in kakoune (i believe).
i think selection first is better, but i think it's fair to prefer vim's style, obviously. but there's certainly ample reasoning, though helix might not explain it thoroughly, because (at least, at one point) they may have expected users to have viewed kakoune previously, and understand its philosophy, as helix is essentially a batteries-included kakoune (and kakoune explains the reasoning quite thoroughly).
It's a nice project though, I just use that feature constantly
is `reflow` a binary that comes with kakoune or something?
But some people don’t actually want to find the perfect editor, they would rather stay on the journey forever, trying to master a new tool every few years. Sounds miserable, never knowing true mastery and enlightenment.
Helix seemed all the same until I started watching a series of tutorials on Youtube.
I get better everyday.
I'm on Windows 10 x64 BTW
The best writing about this is "Why Kakoune" (Kakoune inspired Helix): https://kakoune.org/why-kakoune/why-kakoune.html
I don't want to learn a new language just to configure my editor.
So by choosing scheme they essentially say this is an editor for computer scientists only. </controversial opinion>
But when you're just configuring software this heavily dynamic nature becomes a strength. I just need to build the abstractions in my config that I need, nobody else. It's easy to poke around in and spend a few minutes writing and iterating on code to get the config I want.
I agree that the prefix notation and the soup of parentheses give it a higher learning curve than something like Lua which is easily understandable if you have experience in pretty much any modern programming language. But it's not the mathematical/computational purity that makes Lisps appealing, it's their highly dynamic nature.