261–270 of 271 posts
Earlier quoted context omitted.
I just let AI handle any and all debugging at this point, haven't had an issue where AI couldn't find out what the problem was, finding a solution on the other hand is a hit or miss still.
Can AI pause execution and step through the code line by line? Because that's what I think your parent comment is referring to.
Earlier quoted context omitted.
Doesn't seem like it if you can waste time learning all the keybinds just because you switched an editor, but also how does "can't do things since there are no plugins yet" rank higher vs "sometimes stops working" in importance?
It took me about 10 min to learn the keybindings. It does take longer to get familiar and efficient with them, but I wasn't a Vim master to begin with. (I can navigate efficiently and am proficient with a few combinations that I use the most, but that's about it.) > "can't do things since there are no plugins yet" Depending on what I am doing, I will probably go back to VSCode to get things done. Terminal editors are…
So not the red-herringly 10 min (and there are hundreds of keybinds, so the initial learning wasn't 10 min either)
> like to start with a commonly used setup, discover pain points and bottlenecks, and then optimize or find some other solutions.)
Which you've presumably already done at least twice with vim and VSCode, so again it's just a waste of time to start from scratch yet again instead of configuring for the things you know you need
Earlier quoted context omitted.
Remember that ` SK` does not show neovim built ins. Example ctrl-o which moves to older jumplist position is not show in it. I'd also suggest kickstart.nvim over Lazyvim as its leaner with a primary file for configuration it is not lacking power.
Unfortunately kickstart.nvim is no longer actively maintained.
Whats your source?
Earlier quoted context omitted.
Can AI pause execution and step through the code line by line? Because that's what I think your parent comment is referring to.
AI can use gdb.
Earlier quoted context omitted.
You haven't been using the LSP API then. There have also been multiple breaking changes over the last five years, including breaking compatibility with established default vim keybindings.
Changing default mappings is not a "breaking" change.
Earlier quoted context omitted.
You haven't been using the LSP API then. There have also been multiple breaking changes over the last five years, including breaking compatibility with established default vim keybindings.
A documented breaking change does not mean the application is unstable. The Neovim developers have been extremely clear that part of the process of getting to 1.0 is finalising the API, and that there will be breaking changes en-route.
To be clear, it's fine to have breaking changes. Especially if you're working towards something substantial.
But nvim and its plugin ecosystem seem to be altogether too keen to change absolutely everything and adopt all bleeding edge developments. Even when a mature system would serve the purpose just as well.
Earlier quoted context omitted.
AI can use gdb.
How do you achieve this behavior ? Sorry I haven't done researchs on it because so the answer might be super easy, but I'm curious what's your solution
Earlier quoted context omitted.
Changing default mappings is not a "breaking" change.
It is. And iirc, neovim themselves mark them as such.
Earlier quoted context omitted.
It is. And iirc, neovim themselves mark them as such.
We may mention them in `:help news-breaking` for visibility, but that's only because I don't care about pedantry. API breakage != UI changes (e.g. mappings).
But the UI is also an interface, and the user is part of the total system. That system interface is broken if you change default mappings.
It doesn't matter if the interfacing component is software or a user.
Earlier quoted context omitted.
Looking forward to multiple cursors… but Vim/Neovim can already do some of the common use-cases for multiple cursors, like prepending (or appending) text to a bunch of lines using visual block mode [1]. Here’s a video example [2]: [1]: https://neovim.io/doc/user/usr_10/#_visual-block-mode [2]: https://www.reddit.com/r/vim/comments/jai57c/the_usefulness_...
Yes, and I use those. But it would be nice if it could be generalized to cases where the places that need to be edited didn't line up nicely in a block.