What's New in Neovim 0.10
gpanders.comWhen I first started to learn how to program I was following along a basic tutorial by Jeffrey Way and his first sentence was "We're going to use vim."
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.
I love watching others use Neovim and that's how I learned more about the LSP / treesitter integration. I still find that VS Code is my recommendation for new contributors to an existing codebase because of how intuitive it is to resolve problems solo. If I want to debug a change in an existing project I will almost always reach for VS Code due to the integration with build systems (CMake for example) or other tools. That said, I find that I do "real work" in neovim: thinking, exploring, or writing this reply.
If I were to teach someone from the beginning I would still recommend (neo)vim.
> because he used emacs and wanted to argue with someone about emacs in the office
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.
It was always good natured and I enjoyed the comradery that came from it. He also taught me a lot about vim and command line tools in general.
> When I first started to learn how to program I was following along a basic tutorial by Jeffrey Way and his first sentence was "We're going to use vim." That tutorial, whose topic I can't even remember now, set me on a path for my professional career.
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.
back in the early 1990's i worked for a commercial training company (The Instruction Set) and the first day of our "Programming In C" course normally went something like this:
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
Wow, I love that so much stuff is coming to core!
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!
> 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...
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).
My vim config is generated by nix, if I don’t break it, it does not break.
Have you tried using an nvim distribution? They take care of all the plugin loading, config and testing. They stay reasonably updated too.
I tried using LazyVim, but I didn't put much effort customizing it so I missed my custom config and I found it somewhat janky
I think they are a good middle ground, but you're still left with some of the busy work. Further, you're a bit more at the mercy of the maintainer. Likely, Lazyvim isn't going anywhere, but it isn't out of the realm of possibilities either.
What distribution would you recommend?
I recently started with Kickstart paired with this video, it's really easy and beginner friendly.
I think lazyvim is one of the more successful/dependable ones
I just use CoC for all LSP functionality, and everything just works with almost no issues.
Configuring the native LSP client is still too clunky to switch.
this is why I only update once a year or so around the beginning of the year. I mean "bit rot" is a real phenomenon but not in a year's time. If it fails. I just go back to my old config that is backed up in the cloud. If it fails, I can try again in a month. I'm too old to constantly be tinkering every week or two and hoping it doesn't break.
I haven't used it, but vscode-neovim might give you the best of both worlds.
The ultimate proof that Neovim has a healthy team of contributors, is that they successfully agreed on a new default color scheme. I am now convinced they can succeed with anything.
The proposal from a brave soul: https://github.com/neovim/neovim/pull/26334
Next up, tabs vs spaces!!!
Wow. Almost all of these are things that I will be using right away. It's not often that a release, especially one for software that has lineage back decades, is so relevant to my use cases.
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.
I feel exactly the same - I've never been so pleasantly surprised by release notes.
Immediate wins for current users. And hopefully these builtin QOL features will make nvim easier for new users.
"Nvim 0.10 can now use the OSC 52 escape sequence to write to (or read from) the system clipboard."
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.
> 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
What problems have you encountered? I have the following shortcuts in my .vimrc:
Space + y/p is the copying/pasting from/to the "primary selection" (the mouse middle click). Space + c/v is copying/pasting from/to the regular ctrl+c/ctrl+v clipboard.vnoremap <Leader>y "*y noremap <Leader>p "*p vnoremap <Leader>c "+y noremap <Leader>v "+pThis... just works for me?
My solution is to have this snippet in my vimrc. Don't ask me why this works. It's been years, and I had no issues with it.
Beside this, there is also the issue of setting paste when pasting in insert mode." 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
Neovim is great and is my daily driver for a couple of years now. I was really looking forward to 0.10 because the roadmap said "multicursor", and that's the only thing that sometimes make me open Sublime Text, but it seems like it was more complex to implement than originally estimated and so it was now pushed to 0.12 (https://neovim.io/roadmap/).
I used to want multicursor as well. But I heard a recommendation that multicursor is not "the vim way", and instead to use macros or regex search-and-replace or visual-block mode. That's worked for me.
Of course multicursor must be commonly requested for a reason. Just passing along some alternatives.
I think multicursor vs macro is basically a case of whether the feedback is instant, rather than delayed.
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.
Doesn’t multicursor also require thinking about the exact motion, since if you do it wrong, there is no way to undo?
I’m fairly sure VS Code supports undo whilst using multicursor? Why do you say that undo is not possible?
If it’s an inbuilt feature, the editor can definitely support undos.
I meant undo for motions, not edits. I’m pretty sure Neovim does not have that. (There is <c-o>, but only for large motions.)
What's the difference between multicursor and visual block? Genuinely curious, is it that things don't have to be vertically aligned? What's the ux expectation in a pure keyboard based workflow?
Yeah I think that's it. You can place the cursors arbitrarily with Ctrl+mouse3 in editors like VSCode, ST3, IIRC. Multiple cursors in one line is a scenario I don't think visual block would be great for. I say this as an nvim user who uses macros and will occasionally copypaste a block into VSCode just if i'm feeling lazy and want to multicursor something.
Noticed this also. Truly the only reason I still open up vscode. And repo find / replace. Otherwise Switched to nvim full time about 5 months ago, can do everything and more ha
https://github.com/nvim-pack/nvim-spectre
Is a great find and replace plugin for your repo.
so is quick fix list + `:cdo s//gc | :cdo update`
I’ve played enough games where you control multiple characters with the same controls that I don’t comprehend how someone can like multi-cursor.
For everyone asking for more IDE features...that's literally a non-goal for Neovim:
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).
I like those goals, and some of the new features seem to contradict that mentality.
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.
As a decade long vim user, I just gave nvim a try this year, and I really wanted to like it.
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've settled on LazyVim after many happy years with Jetbrain IDEs and very few unhappy years with VS Code. I have the impression that most Neovim users are building their own config, which is great, if you have the knowledge and personal resources.
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.
The goal of neovim is to be a minimal, extensible base editor. If you want something with all the bells and whistles, you probably want one of those distributions like lazyvim (disclaimer: haven't tried that one; I just know that it's a popular one).
> bummed out that it is still so barebones on install.
Helix might be your cup of tea then.
(Though it will take awhile getting use to the inverted keybindings)
you should use neovim distributions like LazyVim.
I did use Lazyvim. It was definitely better (though I spent a fortune in time modularizing is plugins).
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.
There's just a lot more innovation and development in the offshoot projects than in the big projects. The main project is gradually agreeing on /some/ default key bindings for lsps, as seen in this release (core does a great job on neovim no offense meant there.)
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.
> You're beholden to the distro e.g. if Lazy ever grows obsolete, Lazyvim could go too.
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.
Release Notes (Neovim 0.10):
Q or @ to execute a macro over all visually selected lines is a feature I didn't know about but sounds amazing.
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.
My general approach for macros that I want to execute many times is to end by going down a line (for sequential lines) or to end with a search for the next place that the macro can run. Then I can easily review the targets and run or skip on each.
I'll often visual select ("v" and motion) and then ":norm @a" to run the macro on all the selected lines.
You might find relative line numbers useful. `set relativenumber`
I already use relative line numbers but they don't help when the lines continue below the window.
Pretty much exactly what is needed.
Helix shows the way IMO but the Neovim guys are clearly not conservative.
Exciting to see the tree sitter and lsp improvements.
Including more basic (as of 2024) features in the core like Helix would indeed be a good idea but would go against the existing culture of vim with many plugins competing.
That's why I went with LunarVim, I was tired of maintaining my own plugins and configs, and wasn't quite ready to fully jump ship to Helix (though I do like the direction Helix is going, it'd be an easier sell if shells and everything had Helix keymaps).
Main main gripe about Helix is that helix-like keybindings in VSCode are not working well for the times I need to use that :)
Me too.
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.
Support for inlay LSP hints is the big one for me here. That’s mainly what’s kept me from switching over from vim so far.
How does it keep you from switching from vim when vim does not have it?
It does have it though. Been using it for at few years already with coc.
Coc works with Neovim too if that's the logic.
I know, but previously, the inlay hints would be displayed at the end of the line in Neovim, making them near useless.
Huh, does it work inline in Vim with Coc?
Yes that’s right!
Vim has had inlay hints for a while now, whereas neovim has had it for like 3 days. I think that this is what GP was referring to. Both vim and neovim have LSP support (the former via plugins).
Fantastic release. The neovim project is one of the best recent projects I have seen. It tries to make things look hot by default instead of trying to look "open source".
Awesome release! Ditching my colorschemes and going for the default one. Looks like i can drop even more deps like vim-commentary, and i can remove some keybindings that now come as default!
Neovim keeps getting better and better!
We need proper Neovim gui that is officially maintained
What's the use case for a separate GUI for neovim? I remember using macvim for a few days maybe 8 years ago, but I never "got it". It felt like the benefits of having my editor in my terminal were thrown out for little return.
If neovim had a proper gui, you could move away from some of the limitations of the terminal. The biggest being using fixed width characters for drawing UI elements.
Emacs does it pretty well, one of the few things that makes me jealous of emacs as a vim user.
IIUC fixed widths is more than just a UI problem. Lots of internal code is assuming that. But maybe it works well-enough that it isn't a real issue.
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.
And input limitations can be resolved by non-terminal UIs (for example like Ctrl+i and Tab being mapped to the same control character in old terminals - that one is solved by newer protocols, but the problems don't end there.)
Neovim already supports these keys as long as you are using a terminal that supports the Kitty keyboard protocol (Kitty, wezterm, alacritty, foot, ghostty)
also even the newer protocols fail to support modifier sides (left vs right shift)
Kitty keyboard protocol does indeed support modifier sides.
No it doesn't, and the author rejected the proposal to add them
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)
Yes modifiers are a state, not a key. The kitty keyboard protocol does indeed send events for left and right modifier key press/releas as you can easily see for yourself by running
kitten show-key -m kitty
in a kitty terminal and pressing the left and right modifier keys.
> Yes modifiers are a state, not a key
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?
There is no such thing as a left or right modifier STATE in ANY application. All applications, including kitty track only CTRL, SHIFT, ALT, ETC modifier states. left and right alt and control are key events and can be bound in any application supporting the kitty keyboard protocol as key events. If some application tracks a left and right modifier state it has to do so manually using key press and release events, the OS does not supply it any such state.
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.
This rigid simplistic attitude is precisely why we can't have nice keyboard things and have been stuck in the same state of bad defaults for decades
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/...
ROFL you are saying that kitty the program that finally broke the keyboard logjam with terminals of preventing you from having nice things!! Good luck to you.
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.
I'm not saying that, it's something you've made up for your inner rofls.
> 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?
> I'm not saying that, it's something you've made up for your inner rofls.
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.
> Nope my perfectly confident assertions were perfectly correct and shared by every framework under the sun.
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.
I'd really like image support in a Neovim GUI.
It'd make markdown editing easier for me
Seems more likely to be something you implement with e.g. kitty/iterm/sixel escape codes than moving to a GUI app. Actually probably is something that could be implemented in neovim today. Maybe even by a plugin, not sure what control they have over stuff like that.
see 3rd/image.nvim on github. There might be others
Just basics like fonts and window sizing make the gui version of Vim a better experience for me.
I mostly work on macOS nowadays, and I like macvim.
Of course there are plenty of Neovim GUI. Currently happy enough with VimR.
+1 for VimR
proportional fonts
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
I don't get it, why do we need that?
And I already use Neovide as a GUI pretty often.
I've been using neovide for a few months now, and my biggest gripe is that there's not an easy way to automagically open a new file in an existing neovide window as a tab. With macvim I could do `--remote-tab-silent` and it was handled, but neovide seems to want me to use some kind of background server and a bunch of other hoops to jump through.
that would be nice, currently neovide works pretty well for me. I've heard some who like VimR a lot as well but it's a bit cluttered for me, I just want a fast minimal GUI
neovide is a nvim gui that feels good
I have been transitioning my workflow from macOS to Linux. Discovered it’s kind of pain in the ass to get a gui based editor like Intellij to work correctly, especially within a VM.
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.
> Discovered it’s kind of pain in the ass to get a gui based editor like Intellij to work correctly, especially within a VM.
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-...
But I still need to have the gui app installed correctly with opengl/hardware acceleration enabled , right?
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
There are many great plugins. Telescope, nvim-cmp, treesitter are standard recommendations.
I'll give a shout-out to conform.nvim that gives you very solid format on save functionality that's also easy to setup:
I usually recommend new users to check out Kickstart. It contains a set of plugins and nice to haves so you don't have to discover them your self.
All plugins are in one file + has a lot of comments to help you get started.
Yep, I followed this recommendation, but when I was about to use Neovim in "production" I checked out LazyVim and AstroNVim and chose LazyVim by purely personal taste. Thanks to having learned how the config works with kickstart I don't feel lost, but still benefit from the big efforts and deep knowledge of the distro maintainers by assembling a sound full featured package.
I second Kickstart! The single-file and comments make it easy to learn and configure yourself.
This isn’t neovim specific but this was one of the more delightful and impactful discoveries https://shapeshed.com/vim-netrw/
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.
Btw, while I use Neovim myself and love it, Intellij Idea is available as a Flatpak, which should just work™
https://flathub.org/apps/com.jetbrains.IntelliJ-IDEA-Communi...
I'm doing the same on an old macbook. Off topic, but any idea on how you remap command + left/right? On a mac it is the equivalent of Home and End. I tried xmodmap but it doesn't seem to work with those types of combinations... but maybe I'm missing something obvious?
Love neovim, great to see more parts already in my config coming to core. Maybe one day most of us won't even bother with plug-ins :)
I tried to switch to nvim but quickly discovered that there are breaking changes that just don't work for me, like system() not being interactive and having to use term.
nvim might be great for some but it's not a vim replacement, it's a different editor with different drawbacks.
Its a fantastic vim replacement for most people I think. My Vim -> Neovim migration was simply using the new binary with the same vimscript config, I was really impressed.
Is `!` still broken? Last I looked there seemed to be resistance to fixing it.
Yes, ! has the same issues as system() which I'd need to integrate with lf.
Exciting to see Neovim 0.10 bringing so many core features! And although I don't use it daily now, I believe it's a game-changer for many. Kudos to the team for keeping it evolving!
I love seeing the development of an amazing modern replacement for Vim. I look forward to the moment where it has tons of plugins that are as easy to install as VSCode extensions are.
That's pretty much already possible today with nvim distros like lazyvim.
> I look forward to the moment where it has tons of plugins that are as easy to install as VSCode extensions are.
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")
Am I the only one who doesn't like the new color scheme that much? It seems that it just plainly removes all the syntax highlighting more or less.
Functionally it's good - adapts to both light and dark background, adapts to both 256 and truecolor terminals. I think I miss some of the color even if bright color in light background themes is often detrimental. Only real dislike is the too gray tinted background. Should be more towards white for light background, to be more neutral.
I like bright and bold colors, vibrant and flavorful.
these colors feel pastel, weak, and faded. I don't like them.
you might want to try linking @variable to Identifier, i think the original author decided to keep @variable unhighlighted to keep the color diff between having `termguicolors` on/off to a minimum (Identifier assumes `termguicolors` is enabled, but for default colorscheme it's likely not always the case).
see https://github.com/neovim/neovim/pull/26334 and the comments in highlight_group.c
This sounds like a really awesome release, well done!
Every ~6 months I try to switch from vim to nvim, but somehow it never sticks. Not sure why but in my use cases it is slower than vim, the terminal is imo still worse than vim and it s harder to copy and paste to the terminal: in vim I yank and than C_W"0 (or whatever register I need) in nvim I didn't find a solution yet. Nvim always feels more clunky.
I am curious if any of the termsync options can make neovim play nicely with mosh. My dream setup is to be able to spin up preconfigured dev environments in docker containers, and use blink shell on my iPad for on the go coding. Unfortunately mosh and neovim always end up with display corruption.
I used to use blink quite a lot on my iPad and I’ve noticed it really going “weird” lately.
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?
I refuse to pay a subscription for a terminal app.
The subscription just seems to be for teams features like a shared address book and whatever a “vault” is — I’ve not paid them anything.
I probably would pay them if they would add the Berkeley Mono font though ;)
Does wezterm work on iPad? I used to use mosh+tmux for remote coding, but a couple years ago switched to wezterm which includes some builtin mosh+tmux like capabilities directly in the term so it's truly first-class remote terminal functionality.
For some reason vim-airline in combination with neovim 0.10 has really bad performance when scrolling large files. This doesn't happen with neovim 0.9 and regular vim.
Is there a modern equivalent of MacVim on Linux ? Gvim is OK though the Ux (tabs etc) looks dated.
neovide.dev ?
LSP inlay hints is so nice. Instant upgrade just for that :D
Thank you Mr. Anders.