What's New in Neovim 0.10(gpanders.com) |
What's New in Neovim 0.10(gpanders.com) |
That tutorial, whose topic I can't even remember now, set me on a path for my professional career. During 2012-2015 there seemed to be way more competition in the editor space before VS Code gobbled the community mindshare. I remember starting my first professional job and having a coworker to keep pressuring me to use vim because he used emacs and wanted to argue with someone about emacs in the office (all in good fun I assure you :D). I think I started using nvim when 0.2 was release, but then I didn't really do much more with my rc file than what vim offered.
When neovim enabled plugin authoring with lua that's when it felt like the magic of neovim started to click for me. Plugins like telescope, harpoon, and fzf changed the way I fundamentally work now.
Although I think my favorite thing about neovim is watching other people use neovim, I'm always learning new workflows to introduce into my workflows. It sounds tiring, but it doesn't feel tiring if that makes sense?
Really excited to see inlay hints natively as that's something I really struggled to configure myself.
If I were to teach someone from the beginning I would still recommend (neo)vim.
That's weird to me as in more than 20+ years I don't think I've ever been around people arguing that in real life. It's always been more of a meme to me than anything real.
I like this origin story.
In my case, I was already a decent programmer and beginner UNIX admin when I got my first job, and one day I was using nano or some other "friendly" editor to edit some files on a server, when the literal grey-beard senior sysadmin that was looking over my shoulder pulled a face and said "OK, it's time you learn how to use vim", and spent some time teaching me the basics of it.
Now I have surpassed the Master and I use Emacs, though vim is still my second favorite editor.
me: we are using these beat-up terminals
trainees: is this what we are paying for?
me: we will be using unix (no linux easily available then)
trainees: but we use VMS!
me: and we will be using vi to edit our programs
trainees: wha???
....a week passes
trainees: actually quite neat! i really like vi
Every once in a while for the last few years I overhaul my Neovim config and try to add all the new goodies (commenting, LSP, etc., that are table stakes for most IDEs) as plugins using the latest and greatest plugin manager.
That works for a while, but like clockwork, something breaks- a plugin updates incompatibly, Neovim updates incompatibly, an external binary the plugin relies on updates incompatibly...
At this point I'm stuck with a broken IDE and I don't have the energy to debug all the moving parts. I suffer for a month or something and then restart the cycle.
For my latest config, I decided to treat Neovim and "just a text editor" and made a much smaller config ( https://github.com/bbkane/dotfiles/tree/master/nvim-03-lazy ). It's been really nice having something that "just works" for text edits and using VSCode for heavier IDE tasks.
I WANT to use Neovim for more complex tasks, but I also want a simple config that "just works".
I'm really excited that the core devs seem to agree and are adding tablestakes features to core- the new default colorscheme, Treesitter WASM, and better commenting will all make my config even simpler!
At some point I might even try LSP integration again!
I already had `K` set to LSP hover.
I just switched my comment plugin to get something LSP aware.
Hyperlinks can be a bit annoying. Because sometimes the line wraps so default terminal auto-linking doesn't work properly. Having explicit metadata will be excellent.
I already had inlay hints enabled, but they would appear at the end of the line. Having these in the right place will be fantastic.
`gx` open is not something that I was already using but I will probably start using this.
Immediate wins for current users. And hopefully these builtin QOL features will make nvim easier for new users.
This is a big deal! (it shouldn't be, but it is)
My main complaints about vim/emacs in the past was at the sheer complexity of getting something that should not even be a concern (clipboard integration) working properly, when other text/code editors did not have this problem at all.
Searching online, it seems like tmux has some nice documentation related to OSC 52 usage:
https://github.com/tmux/tmux/wiki/Clipboard
I will be playing around with this for a bit to understand it more. But honestly, this is the sort of thing that should "Just Work TM".
"VTE terminals (GNOME terminal, XFCE terminal, Terminator) do not support the OSC 52 escape sequence."
https://gitlab.gnome.org/GNOME/vte/-/issues/2495
That's a shame, but I'm not against using a different terminal emulator. Up until now I did not really have a good reason to.
What problems have you encountered? I have the following shortcuts in my .vimrc:
vnoremap <Leader>y "*y
noremap <Leader>p "*p
vnoremap <Leader>c "+y
noremap <Leader>v "+p
This... just works for me?
" System-agnostic setting making the unnamed clipboard register act like
" clipboard in any other editor. Copy with y commands, and paste with p or P.
if has('unnamedplus')
set clipboard=unnamedplus,unnamed
else
set clipboard+=unnamed
endif
Of course multicursor must be commonly requested for a reason. Just passing along some alternatives.
Multicursor (in other editors) is a lot better, because you don’t have to think about which exact motion to use as much (since you can see it as you do them).
On the other hand, macros and vim motions are a lot more general, but require you to think about the exact motions a lot more ahead of time.
I think substitution (and command) previews (vs not having these features when substituting) is a good parallel to what multicursor adds over just macros.
Neovim aims to be extensible and enable plugins to do amazing things, but also be minimal.
There are many projects that use the rich set of plugins to provide IDE experiences (LazyVim, AstroNvim, LunarVim, etc).
E.g.: the commenting feature in core. This could perfectly well be done by extensions, and it the kind of thing that doesn't feel like it should be in core at all.
In most every way it is a straight upgrade, but I find myself kind of bummed out that it is still so barebones on install. Really, I was hoping that something like Lazyvim would be the default because I would love a more "out-of-the-box" solution. I don't want to have to worry about keeping the LSP etc. up to date.
So instead, I've been looking more into Helix. Still not sold on the bindings, but what you get just by installing it is great.
I would still recommend spending some time understanding how the config generally works (e.g. by reading kickstart and watching TJs video or/and typecraft's videos). But then, I'd recommend to the person who just wants the best IDE experience to just use LazyVim (or other full blown distributions like AstroNvim). Great discoverability. Lots of features. I use LazyVim with LazyExtras. No customization except the color scheme and adding LSP and TS for Svelte and Rust. I got to work on my projects immediately.
My problem with Helix is that there're many for me important IDE features missing (which you get with LazyVim or AstrNVim or NVChad), decisions of the maintainers regarding the priorities and the that vim keybindings are ubiquitous.
Helix might be your cup of tea then.
(Though it will take awhile getting use to the inverted keybindings)
It just doesn't feel like a great solution for a variety of reasons. You're still a little on the hook for plugins and LSP configs. You're beholden to the distro e.g. if Lazy ever grows obsolete, Lazyvim could go too.
In a perfect world there would be a neovim core (what it is now) and a formal neovim distro.
All too often I create a macro that I want to execute many times, but it's hard to know how many. I've tried the guessing approach but that has a tendency to under- or overestimate.
Helix shows the way IMO but the Neovim guys are clearly not conservative.
Exciting to see the tree sitter and lsp improvements.
Neovim keeps getting better and better!
Emacs does it pretty well, one of the few things that makes me jealous of emacs as a vim user.
Of course there are plenty of Neovim GUI. Currently happy enough with VimR.
many broken things fixed automagically, like those meta keybinds that took years to implement, and also clipboards, then menus
then window management from resizing to switching with Alt-Tab and direct keybinds
then easier integration with external tooling since it's easier to detect the app in a dedicated window
Then freer keybindings not conflicting with the terminals'
Terminal is a poor restricting UI for any complex app such as the text editor
And I already use Neovide as a GUI pretty often.
Happened to have discovered neovim, and so far it’s been a delight to use. Much faster and much lighter on resource use.
Do any neovim veterans have recommendations on plugins to enable? Or even hidden features that would improve workflow.
nvim might be great for some but it's not a vim replacement, it's a different editor with different drawbacks.
There is already a ton of plugins. As for the ease of installation, the "traditional" plugin managers just require you to add one like to your config to install a plugin, which is pretty simple. But there's also a new plugin manager called Rocks.nvim, which installs plugins from Luarocks with a single command (eg ":Rocks install telescope")
these colors feel pastel, weak, and faded. I don't like them.
see https://github.com/neovim/neovim/pull/26334 and the comments in highlight_group.c
They have some script that executed on login, which tried to “upgrade” my connections to mosh by downloading a static mosh bin from some server they own (so, could contain anything) and it was opt out — and lately randomly some keys just stop working on the keyboard (like, the c key just doesn’t work at all in the app).
I jumped ship to Termius, shame. How’s your experience lately?
Just avoid upgrading plugins until necessary. I've no idea how old some plugins are; I only upgrade when necessary (e.g.: when neovim upgrades, or when I need some new feature).
Configuring the native LSP client is still too clunky to switch.
Is a great find and replace plugin for your repo.
so is quick fix list + `:cdo s//gc | :cdo update`
Depending on your use-case, that's what their Gateway product <https://www.jetbrains.com/remote-development/gateway/> is designed to solve: it runs (effectively) headless IJ in the VM, so indexing and analysis happens there, and then streams the GUI part over a custom protocol to your local IJ to handle the time-sensitive GUI bits
Currently, to the best of my knowledge, they actually do require ssh, so it won't work over AWS SSM nor kubectl exec or similar, but I have high hopes they're going to fix that glaring bug Any Minute Now ™
see also:
- https://www.jetbrains.com/help/idea/remote.html
- https://jetbrains.github.io/projector-client/mkdocs/latest/i...
- https://github.com/JetBrains/projector-docker#run-jetbrains-...
My problem isn’t with inconsistent development environments. I have trouble spinning up the IntelliJ ide locally. Thus the need for something more lightweight.
Also I have used this in the past and the experience wasn’t the greatest. Tried with a dev server with gateway hosted within intranet. Used an m1 Mac as thin client.
Issues with syncing state of client. Significant input lag in a large project. I remember trying to refactor a method in a 500K+ LoC and the UI would hang.
Syncing plugins was also an issue at the time.
I suspect these issues would likely be exacerbated over internet with tailscale
I'll give a shout-out to conform.nvim that gives you very solid format on save functionality that's also easy to setup:
All plugins are in one file + has a lot of comments to help you get started.
Configuring netrw right and having my vimrc load a side pane with it on load, combined with configuring my tab key to cycle between windows... Perfect.
https://flathub.org/apps/com.jetbrains.IntelliJ-IDEA-Communi...
I probably would pay them if they would add the Berkeley Mono font though ;)
In the same time, LazyVim and AstroNvim have built whole worlds of configuration and LSP integration because they are free to tinker, at a speed far outpacing core neovim. Because the core project wants/needs to cater to everyone. Even you said it was a straight upgrade (to Vim, I assume) and just keeping it that way is not easy.
That is my only concern, too. But I decided not to worry. Getting into LazyVim was very easy, so I'm not concerned potentially having to switch to another distro or IDE.
I am vi mode everywhere so I couldn't quite make the switch on the bindings but I loved the ideas in Helix. Truly a great project.
If it’s an inbuilt feature, the editor can definitely support undos.
I remember trying a terminal that didn't have fixed char widths and it mostly worked. The only real issue was line wrapping (as vim and the terminal would both wrap based on how long they considered the line to be). So maybe it would be possible! I would love to see solid support for variable-width fonts.
I know variable-width fonts are controversial, but I actually think they work well for coding but haven't had the chance to use them much due to Vim limitations. But especially for Markdown and similar mostly-text content they seem like a clear win.
It'd make markdown editing easier for me
https://sw.kovidgoyal.net/kitty/keyboard-protocol/
Modifiers are encoded as a bit field with:
shift 0b1 (1) alt 0b10 (2) ctrl 0b100 (4) super 0b1000 (8) hyper 0b10000 (16) meta 0b100000 (32) caps_lock 0b1000000 (64) num_lock 0b10000000 (128)
kitten show-key -m kitty
in a kitty terminal and pressing the left and right modifier keys.
So why are you talking about a key then??? Kitty doesn't support left/right modifiers unlike proper keybinding handling apps, the left/right presses for non-modifier keys aren't relevant
How would you bind LeftAlt-A to something different from RightAlt-A in Kitty?
You seem to be thoroughly confused about what is a modifier and what is a key. Left and right ctrl/alt/shift are KEYS not MODIFIERS. You can track whether they are held down or up by tracking their press and release events just like for any other key.
The only differentiator for a modifier state is that it... modifies! Here is a wiki common sense definition
> In computing, a modifier key is a special key (or combination) on a computer keyboard that temporarily modifies the normal action of another key when pressed together
So your limitations don't make conceptual sense, not only can you have LShift vs RShift modifier state, but also you can have an F modifier state when you hold down the F key to modify the behavior of other keys
> OS does not supply it
Unless it does?
> VK_LSHIFT VK_RSHIFT VK_LCONTROL VK_RCONTROL VK_LMENU VK_RMENU These left- and right-distinguishing constants are available to an application only through the GetKeyboardState, SetKeyboardState, GetAsyncKeyState, GetKeyState, and MapVirtualKey functions.
https://learn.microsoft.com/en-us/windows/win32/api/winuser/...
And lets apply some common sense to your common sense, follow up on it a little. If a modifier is defined by the fact that it modifies the actions of other keys, then left and right modifer keys modify the action in exactly the same way and thus are the same modifier. Common sense indeed.
And if you want to reference windows, a platform kitty does not support, here you go: https://developer.apple.com/documentation/appkit/nseventmodi...
no left and right modifier state on macOS. And neither does X11/Wayland have them, though I dont have a link handy, so I will just leave you with a couple of links to the documentation for cross platform toolkits instead:
https://doc.qt.io/qt-6/qt.html#KeyboardModifier-enum https://www.glfw.org/docs/latest/group__mods.html
And in case the common sense didnt make it past your mental barriers, a terminal keyboard protocol has to work on all platforms not just windows. The good lord alone knows what windows does, probably synthesizes that state based on press and release events.
> If a modifier is defined by the fact that it modifies the actions of other keys, then left and right modifer keys modify the action in exactly the same way and thus are the same modifier. Common sense indeed.
No, that's nonsense and factually wrong. Common sense is that a different modifier key is still a different modifier key even if the modification is the same. You have to do some logic twists not to make it so. Also, this is factually wrong: they don't modify the action in exactly the same way, that depends entirely on your config. In mine they act differently
> And if you want to reference windows, a platform kitty does not support, here you go:
But your overly confident overly broad statements weren't platform limited. So how are your links to the backward platforms / gui frameworks relevant? I've already acknowledged "state of bad defaults"
> a terminal keyboard protocol has to work on all platforms not just windows.
And if you turn your mental barrier off, it's pretty obvious how to make it work everywhere - you simply flag both left+right on getting the no-side flag info on a backward platform that doesnt differentiate. And only flag either left or right on a platform that does differentiate. Or differentiate it yourself by reading raw codes. So there are no good reasons to create yet another bad keyboard protocol when it works fine without blinders off
> The good lord alone knows what windows does, probably synthesizes that state based on press and release events.
Do tell me, what is the alternative magic of how Mac/Linux synthesize Shift state without press/release events?
Says you. And as you have abundantly demonstrated, you are a moron.
>No, that's nonsense and factually wrong. Common sense is that a different modifier key is still a different modifier key even if the modification is the same. You have to do some logic twists not to make it so. Also, this is factually wrong: they don't modify the action in exactly the same way, that depends entirely on your config. In mine they act differently
ROFL more idiotic assertions.
> But your overly confident overly broad statements weren't platform limited. So how are your links to the backward platforms / gui frameworks relevant? I've already acknowledged "state of bad defaults"
Nope my perfectly confident assertions were perfectly correct and shared by every framework under the sun. Because they are right. You coming up with nonsense use cases from under your overly small sized hat doesn't change that.
> And if you turn your mental barrier off, it's pretty obvious how to make it work everywhere - you simply flag both left+right on getting the no-side flag info on a backward platform that doesnt differentiate. And only flag either left or right on a platform that does differentiate. Or differentiate it yourself by reading raw codes. So there are no good reasons to create yet another bad keyboard protocol when it works fine without blinders off
The good reason is that modifiers are state. Left and right modifier keys modify that state in exactly the same way. You WANTING them to work differently doesn't make it so. And you bloviating about how it's a bad protocol just makes you look like the moron you are, No terminal emulator developer is going to agree to implement a keyboard protocol that requires bypassing how the platform the terminal emulator runs on handles modifier keys. Because you want it to be so. What a joke. Grow up. Or actually dont, keep on ranting on internet forums about your pet demand, all the grown ups are just going to ignore you and/or laugh at you. Good bye and good luck.
Except for the most popular OS in the world and the frameworks that support it (including those you linked, QT has a way to query Windows and get Right Shift key state)
> You WANTING them to work differently doesn't make it so.
Except it does, and your childish trolling and insults can't change this simple FACT that they DO work differntly precisely because I WANT that and I've set it up to work like that, not all software is as narrow-minded as you are. Live with it.