Live data from Hacker News

Notes on switching to Helix from Vim

jvns.ca

221–230 of 242 posts

Re: Notes on switching to Helix from Vim

#221
post #84

The bloat of the neovim distributions are real and what I would suggest for anyone who is a long time vim user is to check out kickstart. https://github.com/nvim-lua/kickstart.nvim , specifically the modular fork https://github.com/dam9000/kickstart-modular.nvim which will give you a great (minimal) starting point

Heh the thing I like about kickstart is everything is in one file, though it is a bit unwieldy, so I surrounded most bits around fold markers to make it a bit more manageable.

interesting! yeah I think the one file concept is really neat. Here are some more details about my config with the modular fork if you are curious https://jarv.org/posts/neovim-config/

Re: Notes on switching to Helix from Vim

#222
post #207
post #190

Earlier quoted context omitted.

Check your understanding of ergonomics if you fail to see the obvious

Can you give at least a few examples? I have no understanding of ergonomics it seems

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!)

Re: Notes on switching to Helix from Vim

#223
post #131

Earlier quoted context omitted.

I think a lot of people on this site have genuine reading comprehension problems. I mean that as an observation, not an attack. > "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…

When someone is competent, as must be after using a tool for 20 years (not days). Expecting that someone to complain about a difficulty for something trivial is surprising. There are other ways to highlight that it is easier or simpler in Helix to have working LSP, for example, saying it is "as easy as in vscode". But it is definitely bewildering why would the OP choose to start by bragging of the vast experience, an…

> Expecting that someone to complain about a difficulty for something trivial is surprising.

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.

Re: Notes on switching to Helix from Vim

#224
post #55

Earlier quoted context omitted.

It has both? Granted, Ctrl+D requires manual construction from a sequence of commands, but click to place extra carets works as is

> requires manual construction from a sequence of commands 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.

A-s = ["save_selection", "select_mode","search_selection","extend_search_next"]

you select a token, then pess alt+s to select the next instance and so on

Re: Notes on switching to Helix from Vim

#225

That bit about search using the ripgrep plugin not providing context has always been available using telescope and a handful of clone plugins.

Indeed, Vim has had ways to do this for years, before nvim. I suppose their point is that it comes out of the box? It is worded in a way that makes it seem like they think like there are no options. 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 cu…

If %s is Vim's answer to multiple cursors, then it's hopeless. I'm using both VSCodim and Vim, the former when doing dev, the latter for quick editing remotely through ssh. Tried Helix but it kind of annoyed me after years of using Vim.

Re: Notes on switching to Helix from Vim

#226
post #220

Earlier quoted context omitted.

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…

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

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.

Re: Notes on switching to Helix from Vim

#227
post #216
post #160

I feel like I am not asking THAT MUCH from my neovim setup, but it is so complicated. My collection of vim config is about 1000 lines, that's insane, but when I try to trim it, everything seems required. 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 rel…

So... have you tried Helix? Covers everything you're asking for, and doesn't require any config fiddling for it.

Helix has no file tree.

Re: Notes on switching to Helix from Vim

#228
post #207

Earlier quoted context omitted.

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

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 :).

Re: Notes on switching to Helix from Vim

#229
post #61

I cannot express how liberating it feels to opt out of "advanced" editor tools like lsp. I program in neovim with no plugins, no syntax highlighting and no autocomplete of any kind. There is a discipline that this imposes that I believe leads to better quality programs. It's not for everyone I suppose, but I really recommend trying it.

what do you think about ctags? i think when trying to understand a codebase for the first time a tool to quickly look up definitions, etc. helps immensively

Re: Notes on switching to Helix from Vim

#230
post #111

Earlier quoted context omitted.

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

How is so? I have my dot files in GitHub. I just have to clone, run `PlugInstall` and it's all ready.

[deleted]
Post reply on HN