Hacker News Reader

Comment by gpanders | Hacker News Reader

I did a brief write up on some of the biggest new features here: https://gpanders.com/blog/whats-new-in-neovim-0-7/

Thanks for summarizing the highlights!

The client-server part is the one I'm most excited about. It is one of my favorite things in kakoune and it'll be nice to have it on neovim too. I find it more intuitive to use separate terminal windows with all the usual window manager shortcuts, instead of using vim-specific terminal splits.

Do the kakoune and neovim keyboard shortcuts conflict for you? I've put off trying non-vim modal editors because I think there's only enough room for one set of shortcuts in my head. How difficult is it for you to switch between them?

It's not too bad, because the most basic commands are about the same. The ones that get me the most are dd and V. When I switch to the other editor I get these wrong a couple of times before the mental model readjusts. That said, I never was a super advanced vim user because I couldn't remember the rarely used motions. Part of the reason I started using kakoune is that I find it easier on my brain. Basically everything is in Visual mode by default, where you select before issuing the command.

I've been using vim (neovim) for more years than I can count, but there is still so many movements that doesn't stick in my head, probably because I don't use them so much.

I recently came across the which-key.nvim (https://github.com/folke/which-key.nvim) neovim plugin, which helped me a lot to speed up finding what movement I want to do. It basically shows you a popup with what combinations are possible after you press any key (while nvim waits for the next one), so you can basically explore commands by just pressing keys, instead of having to look them up.

This is neat. I'm the type that immediately disabled the arrow keys when I was learning vim and treated it like learning the piano (which, I admit, is a bit mental) and just forcefully drilled most of it into muscle memory.

I think this would have sped me up even more. Definietly neat. There's also a few plugins/configs around highlight as-you-search worth exploring. That being said I strongly recommend against going plugin shopping, you only need precious few. It is a better use of your time to do it the hard way sometimes.

Seems to be missing one of the bigger changes: support for python 2 has been completely dropped in favor of python 3.

It's always fascinating how differently people read the same text. I was just here browsing comments about the python2 drop after noticing the headline of the changelog:

> BREAKING CHANGES

> Support for Python 2 is dropped. For Python 3, the minimum supported version is 3.6. Legacy :pythonx commands are still available, and always uses the python 3 provider.

> One use case for the new remote functionality is the ability to open files from the embedded terminal emulator in the primary Neovim instance, rather than creating an embedded Neovim instance running inside Neovim itself.

Hmm, if I type "git commit" within the terminal, is there some value of $EDITOR that would make it launch a buffer to edit the commit message, then finish when I close the buffer? (and if so, are there distinguishable success vs failure ways to close the buffer?) That's my biggest editor-within-an-editor moment.

For that to work, you'll need the 'wait' versions of the remote flags. Those are still being worked on in a PR, but I'm hoping to finish them up by the next release: https://github.com/neovim/neovim/pull/17856

That said, this sort of remote opening has been possible in Neovim since the client-server stuff was added in the early days. This is only adding the remote editing flags and implementation to Neovim itself to make it easier.

Neovim-remote(https://github.com/mhinz/neovim-remote#typical-use-cases) is an outside-of-Neovim way to do it with the Python client. It has an $EDITOR setting listed there. Or if you don't want to use Python, you can use invim(https://github.com/groves/invim#to-use-as-your-git-commit-me...). It's just a shell script. Or you can wait for the next release!

I'm not sure if I understand you, but with EDITOR=nvim it'll do just that. To "commit" w/ the message you have in editor, ZZ. To abort, use :cq

That's a separate nvim instance within the terminal of the outer nvim instance. If I'm understanding this feature correctly, the idea is that instead of that, you make the outer nvim instance do stuff. Then pasting back and forth between buffers works better, etc. It wasn't clear to me from this short blurb though if that includes blocking for the buffer to be handled and then signalling success or failure to the caller. (or for that matter if I'll remember the mechanism for it if there is one. I operate on muscle memory and might just stick with the tiny editor within the bigger one. But I'm curious anyway.)

It would be nice if it overrode EDITOR with some command that opened a new pane in your existing Nvim session. That seems doable.

Alternatively, Tim Pope's fugitive is pretty great and you can write :Git commit and it does just that.

It could even overlay the terminal pane for the duration of the command with the buffer pane. So it'd look a lot like opening the second editor instance, except incorporated with the first editor's buffer list, registers, etc.

Oh, I see. I got derailed by the usage of terminal to refer to three different things :)

> Add let g:do_filetype_lua = 1 to your init.vim file

Seems odd to not mention how to do this in init.lua

Yeah. These conversions are fairly straightforward, though:

    vim.g.<var> = <val>

This is really helpful, thank you!

Does the new filetype.lua script still run the ftdetect/ scripts? Or will those only be run by the filetype.vim fallback and need to be ported to the new system?

Yes it does.

Does "Distinguishing modifier keys" feature work on macOS Terminal ?

Reply on news.ycombinator.com