_7tgr

Entering + exiting insert mode with i and Esc moves your cursor to the left by one, so I suppose this neutralizes it?

It does, you'd just have to install a python plugin that registers the autocommand-- or leave out the plugin and register the autocommand yourself. The (n)vim/emacs communities aren't fond of integrating the hot new thing for each language directly into the editor-- I think this is a lesson that comes from being 50 years old!

As for whether it would be buggy, I'd doubt it? Unless Black's principle of operation is different from most formatters, it should just write the formatted contents to the file, right? The autocommand you'd use would just run Black on your current file on each save. So where % is Vim's symbol for the name of the currently open file, :silent! suppresses stdout/stderr from the formatter, and :! runs a command:

autocmd BufWritePost *.py silent! !<format_cmd> %

(Don't quote me on that, but it should be essentially correct. I'm not at a computer right now.)

Actually, it looks like you can install an (n)vim plugin from the official Black repo here:

https://github.com/psf/black/blob/main/plugin/black.vim

And then the autocmd would be

autocmd BufWritePost *.py silent! Black

This stuff is documented here: https://black.readthedocs.io/en/stable/integrations/editors....

Anyway, I think it's actually a really cool effect of doing this that you realize a lot of the scaffolding underneath most editors _isn't_ that complicated! It's totally understandable :)

For what it's worth, the 'VSCode-level' functionality in my init.lua has probably required roughly a few hours of maintenance over the ~7 years I've been using Neovim. The LSP setup is just a matter of finding a plugin manager (or not), installing the lspconfig plugin, pasting in the config from the README, and inserting a single line that contains the name of the language server you want to configure.

It can definitely lead you down all sorts of twisty paths if you look at other people's elaborate configs and decide to do that sort of stuff yourself but it's very pleasant/low-maintenance if you stick to the basics (meaning roughly what people do with VSCode). It takes me roughly a few minutes to configure Neovim for a new language :)

(Of course, there's some other stuff in my init.lua that I've put there for fun, like clipboard and window management scripts, but that's not strictly necessary. I've spent a bit more time figuring out the Lua API to write these, but I personally think it's worth it for the extra ability to mold the editor to my needs).

FWIW, I just needed to install the default nvim-lspconfig plugin (it's provided by the Neovim maintainers, and it doesn't do anything besides provide default LSP server configs for a lot of languages to the builtin Neovim LSP client), paste in the keybinds recommended by the README, and call lspconfig.rust_analyzer.setup in init.lua. Configures itself to start whenever rust_analyzer is in PATH. Seems to work well enough! I don't think it's missing any functionality.

You might want to give nvim's Lua API a try. They took the opportunity to fix a lot of the semantic issues with vimscript

Yeah, likely to update all the plugins it uses or something. I don't use it so unsure :)

I'm playing into the joke here, but on most terminals, alt + <key> will actually be sent to the program as <esc> + key. You can use this to avoid pressing escape in Neovim.

Helix is cool, but it doesn't have Vim keybinds, which is unfortunate. I find its own system to be a little worse than Vim's (see my other comment about it in this thread).

Helix is interesting but I don't really gel with its editing language (subject + verb instead of verb + subject like (n)vim's). Happy to discuss what I think is lacking in more detail, but basically: the premise of 'you can see what you're about to operate on before you do the action' is satisfied for me by visual mode, and I like macros better than multiple cursors. So I don't want a (subjectively) less efficient editing language for these features. I think I generally agree with the complaints in [1], with the addition that I don't want to have to chord (press shift in the case of Kakoune, I forget what helix does here) to extend a selection.

I wish they'd add a Vi mode. ;)

[1] https://github.com/noctuid/dotfiles/blob/master/emacs/editin...

No, it's not clunky. The plugin community is just a lot more active, imo. I personally avoid plugins wherever I can, since I prefer to write my own little Lua scripts that do stuff the way I like. (And I quite like the Lua API-- the lua plugins I use seem be a lot faster/less janky than the vimscript ones, as well? not sure)

I see where you're coming from. FWIW, I've been using Neovim for an odd 7 years or so and only use plugins where absolutely necessary. I'll usually just add an appropriate BufWritePost (trigger after saving the buffer) autocommand for the language's file extension that does what I want. Or I'll add a keybind in .config/nvim/ftplugin/<lang>.vim (or <lang>.lua). You can do fancier stuff with plugins but I find that I just don't need it (and you probably don't either, by the looks of it).

The default LSP client config at https://github.com/neovim/nvim-lspconfig#suggested-configura... sets everything up for you, if you're using an LSP server. I'm not sure why it hasn't been merged into the Neovim repo; possibly because they want to keep the editor core fast and minimal.

All this means you have to do a little more configuring than with something like VSCode, but to be honest, I haven't legitimately needed to make big changes to my config in a few years. There's stuff I add for fun (like little lua scripts to manage my clipboard and to layout tabs the way I want), but to maintain a 'VSCode' level of functionality none of it's needed. The advantage of spending a little extra time, for me, has been that my editor 'fits like a glove', so to speak :)

Well, sure, but setting up the build environment is pretty easy! You just specify the libraries as you normally would, and it works. The only difference is that those libraries are only available to that package, and not globally. The function `stdenv.mkDerivation` will actually build a standard ./configure && make style C project for you if you provide it some package source, you just have to copy out the build artifacts (with something like (cp project bin/project) and specify a list of libraries needed at build/runtime.

Agree that the documentation for all of this could be a lot better and more discoverable. It's good once you get over the initial hump though.

Sure, I agree that I could have been nicer. On the other hand, I have very few spoons for responding politely to people who retort to others’ requests to not be judged on the basis of their race with, effectively, “suck it up”. It’s difficult for me to consider that an attempt at helpfulness, though it’s possible that someone without personal exposure to these issues could mistakenly think otherwise. It causes a lot more damage than some snark on my part, imo.

In any case, thanks for taking the time to offer a more charitable perspective on the comment I responded to.

Can’t believe I have to state this explicitly, but I am on Hacker News, after all-- scraping the bottom of the barrel here.

It is absolutely reasonable to ask people to reconsider their prejudices. Your line of thought does nothing but reinforce people’s existing biases without leaving room for the nuance of social context. Racists misuse statistics all the time to justify their awfulness. Consider whether you’re really different from any of those people. Or do I just need to get to know you more?