4 ms·
The comments in this post remind me why I use an IDE. Breakpoints, debuggers, auto formatting aren't things I make decisions on every day, they're just built in
by maccard 3y ago
The comments in this post remind me why I use an IDE. Breakpoints, debuggers, auto formatting aren't things I make decisions on every day, they're just built into the tool I use. (I recently moved from visual studio to intellij and friends, and the biggest feature I miss are https://learn.microsoft.com/en-us/visualstudio/debugger/using-tracepoints?view=vs-2022 https://learn.microsoft.com/en-us/visualstudio/debugger/usin... tracepoints. They're like runtime configured logging for compiled languages)
That said, I do use vi bindings for navigation. Stuff like "replace all instances of X with Y" are semantic, and my editor handles them for me. Doing "insert at the end of this quoted string is something I _do_ use. I have gripes with Vi's defaults (hjkl shouldn't be the default because the author had a keyboard with those defaults half a century ago), but overall it's an improvement on arrow keys and a mouse. The best comparison to me is it's like touch typing Vs hunt and peck typing for text editing. I'm not wildly more productive because I can use a handful of shortcuts, but it does remove friction.
What I do want is semantic vim. I spend my day writing code, and despite the fact that I edit text I think in semantics. No, I probably don't care what the next word is, and I don't care to guess how vim is going to interpret `w` when I give it:
macro_rules! foo {
($l:tt) => { bar!($l); }
}
macro_rules! bar {
(3) => {}
}
foo!(3);
What I really want is something that interacts with tree sitter (or the likes) and navigates my code. I want to delete this current block, or this function. I want to jump to the next argument, not the comma in a hard coded string. I want change the last argument of this function, not up until the closing bracket of the first function call in foo(bar(), baz(), 3);
- matwood 3y agoSame. In just Intellij and VSCode with vi bindings and rarely use vi/vim unless I'm on the server or doing something quick at he CLI.
- maccard 3y agoAll our apps are containers, so being on the server is a rarity. Quick CLI edits, I use vscode for these days (but am investigating switching to fleet as per the last time it came up here!)
- williamdclt 3y ago100% agree, I use vim integrations all the time and it annoys me to no end that I cannot act on a function, an identifier, a block. Text editing is powerful but it is definitely not a seamless interface to my brain when I have to think of how to map what I want to do (eg delete a function) to how I can do it given the specific layout of the text (delete the indentation level with daI but the signature was over several lines so I need a few extra dd).
- maccard 3y agoYeah these sorts of inconsistencies are exactly what Im talking about.
- xigoi 3y agoWith Neovim, you can configure bindings for Treesitter-based actions.
- nequo 3y agoDo you have a tutorial or a documentation link to show how to do this? Or is there a plugin that you recommend specifically?
- xigoi 3y agoI personally don't use this functionality so I can't recommend a specific plugin, but if you search for “treesitter”/“tree-sitter” in this list, you will find several of them: https://github.com/rockerBOO/awesome-neovim https://github.com/rockerBOO/awesome-neovim
- maccard 3y agoThis is the equivalent of saying rsync + a VPS plus some scripts is an equivalent for Dropbox, IMO. See the start of my original comment for why I don't want to use neovim (Im not spending hours configuring plugins and choosing between three subtly different LSP and treesitter plugins, then choosing a client and server for each). Setting that up involves (first changing editors), learning the details of my editors scripting language, the details of tree sitter, and coming up with a unique set of bindings that don't conflict with neovim's - no thanks.
- mikl 3y ago> hjkl shouldn't be the default because the author had a keyboard with those defaults half a century ago hjkl are still a pretty good choice for a modal editor. If you’ve learnt standard touch typing, your right hand will be resting on jkl;, so it’s extremely convenient. The Vi(m) philosophy is to reduce how much you have to move your hands about, so everything is put as close to the “home row” (asdf + jkl;) as possible. This is why Vim-spinoffs like Helix and Kakoune, while turning the whole keybinding system on its head, are both keeping hjkl. Not for historical legacy, but because it’s actually a good choice.
- maccard 3y agoI disagree that they're a good choice. A good choice is jkl; > This is why Vim-spinoffs like Helix and Kakoune, while turning the whole keybinding system on its head, are both keeping hjkl. Not for historical legacy, but because it’s actually a good choice. I had a look this morning and I couldn't find anything to back this claim up. My claim would be it's the opposite, it's what the authors are used to, it reduces friction for other people who might change, but it's objectively inferior than having the keys be the same as the home row keys themselves.