[curriculum]

I'm most excited for the treesitter integration and its potential to amplify Vim's "killer feature": text editing as a language.

Vim's editing language feels most powerful when I'm using its text objects: "ciw" means "change in word", "cis" means "change in sentence", and so on. But Vim's built-in text objects are not always a perfect match for the code you're editing. Suppose you want to change the first argument of a function, for example; there's no built-in "first-argument" text object. But Treesitter integration makes it easy to create text objects that understand the AST. Without much effort, users will be able to make mappings like `cia1` to "change in argument 1", and these mappings will work across all languages with Treesitter support.

[alpaca128]

I'm excited about it because Vim's usual syntax highlighting is rather fragile. As far as I understand it Vim does the highlighting in the same thread, and to ensure good performance it enforces a time limit for the file parsing. In larger files this frequently leads to weirdly flickering highlighting when scrolling.

Going from that to actual syntax parsing is a dream come true.

[bisby]

That explains a lot. I often have a syntax highlighting quirk where it thinks that a fold has an open quotation mark in it. And will highlight everything below the fold as if it's a part of a string. I unfold, and clears it all up. but it's annoying in the moment.

I look forward to all of this

[alpaca128]

You can often fix it with `:syntax sync fromstart`, but Vim's syntax highlighting just keeps being a bit weird.

[nucleardog]

I usually just keep space bound along the lines of:

    :noremap <silent> <Space> :silent noh <Bar>echo<cr>:syn sync fromstart<cr>

This recalculates syntax highlighting as well as removes highlighting on search results/etc.

Basically, whenever stuff "looks weird", just mash space in normal mode and it fixes it. The fact that I have this bound to something like space should tell you how often I end up using it. :)

[alpaca128]

I recently gained a liking to search result highlighting, it's much more useful than I originally thought. The problem is not the highlighting itself but its persistence. I added a few autocmds to automatically hide it in certain events and a manual shortcut. Works better for me now, though it is annoying that `:noh` has some weird special status that makes it nonfunctional in autocmd.

[ajitid]

I evaluated few plugins around this and this one I liked the most: https://github.com/romainl/vim-cool

[kbenson]

I added 'autocmd BufEnter * syntax sync minlines=4000' to my .vimrc to make it buffer more of large files initially, so it gets less confused when you reopen a file and it resumes at a prior location deep inside and has no syntax highlighting.

I guess fromstart would work as well, but is probably best manually run like you do so a very large file doesn't bring the system to a halt.

[OJFord]

That's why that happens, and a fix - thanks!

[azinman2]

Do you find your brain can actually work that way? My issue with all of these relative jump points, repeat this N times, etc of VIM is by the time I’ve calculated in my mind what the command should be I’d have already done it with just standard navigation/mark/yank/repeat. But perhaps you have galaxy brain ;)

[diegocg]

The way vim works is actually the opposite of what your brain wants, this is one of the reasons why learning vim tricks is hard.

The vim model is "action-object" (eg dw, delete word). A more natural, friendly and interactive model is the opposite, "object-action": first you select the text, your editor highlights the text, then you apply actions to the selection, one by one, and see what happens after each one. Because the text is highlighted beforehand and you see the effect of each action in real time, building chains of commands is much easier and friendly for novices. If you make a mistake, you see its effects and correct it immediately. In vim you have to build the command chain beforehand and calculate in your head what will happen. If you memorize the commands its fine, but if you don't, it's painful.

This "object-action" model is used by kakoune (https://kakoune.org/why-kakoune/why-kakoune.html), along with native multicursor support I have found it to be a great alternative after years of not being able to memorize vim commands. Documentation is scarcer at this point, though.

[chipotle_coyote]

You've oddly crystallized why Kakoune has so far failed to grab me!

The description you gave of the actions one takes in editing makes sense: in most non-modal editors, you select the text you want to take actions on, then choose the action to take. But, I can do that in literally every modeless editor! That's the way essentially all of them work.

But when people write of "Vim as a text editing language" as many comments here do, the action -> object model -- again, at least for me -- fits the pattern. We say "I'm going to the store," not "store I'm going to," unless Yoda we are. And, most programming languages that aren't purely object-oriented tend to follow a rough pattern of "action(parameter)". So in editors like Sublime Text (or VSCode or BBEdit or...) I tend to do editing in an entirely visual way, Vim approaches editing in a more language-based way, and when you describe edits in language, "[verb] the [noun]" is pretty natural.

[OJFord]

In English, sure. Not in Hindi for example (मैं खाना खाता हूँ - 'I food eat') or in .. object-oriented methods of many programming languages.

I don't think there's anything special about that mapping, whichever way around. I'm not inclined to think I'd perceive things or act any differently if my main way of describing things (English) had a different grammar - a rose would smell just as sweet.

I can see some value, especially for beginners, in 'highlight while object selecting, then act' (which you can do in vim with visual select and then action, e.g. instead of c2w do v2wc - or v2w -wait no that's not what I want-).

I do prefer it as it is though, probably just because I'm used to it, but I think of it as 'up to' rather than 'define the object', since it is always anchored (at least, without any plugins doing differently like is being discussed with Treesitter here, adding context awareness) by the cursor position. So I'm thinking 'change from here to..'. I suppose if one wants to think about 'object first' you could argue vim already is that anyway - you move to the object before typing any of the command.

[dsego]

Some languages use both orders, and the difference is more of a stylistic choice.

[javier10e6]

Indeed, in Spanish we say "lava la ropa" do the laundry. I am pretty sure that is what my brain wants, action object. Once in object-oriented training I was told that In Cantonese the person does not act on objects but the objects act on themselves: "The deck of cards shuffles itself"

[claudiawerner]

Latin has an extremely flexible word order (some of which Old English had too) which allows all kinds of fun stuff for style and communicating status/education. Japanese with its particle system also allows some good flexibility.

[bombela]

I tend to pick and measure a piece of wood before turning my saw and cutting.

I say that I am cutting the wood. But I select it first before marking it and cutting it.

I noticed that I use the visual mode of vim a lot. With easy motion to highlight words or other object boundaries to quickly jump to.

I tried kakoune and liked it. But after 15y of (neo)vim it's hard to change. That plus how good You completeMe is for vim.

[addicted]

Well, the reality is that WYSIWYG editing of all sorts is object oriented. You first select the object and then the action.

So it’s not clear whether being more comfortable with selecting an object and then performing an action on it is innately easier for humans, or just what we’ve been conditioned to from using word processors, spreadsheets, or even GUI based file explorers.

But if you look at command line usage, it’s the opposite. Every command first requires you to stare the command, and then the object to act on.

I first type cd and then the folder I want to change directory to, compared to selecting the folder and then hitting enter/CMD+O/double clicking ont he GUI.

But people who have used both the GUI and CMD line rarely ever find the order of operation to be a concern for them, so I suspect the object-verb verb-object difference in vim is just a matter of convenience.

[bombela]

I do woodworking and construction work. In real life, I always must select first. Apply action second. So to me this feels more natural.

[bashinator]

I have an almost entirely non-visual imagination and internal narrative. Vi and then vim were pretty easy to adopt, and it’s still easy for me to learn new editor-as-a-language functionality. I started using it in the 90s and only figured out the visual stuff in the past few years (for block editing).

[bombela]

That is maybe the key point here. I am the total opposite of you. A friend of mine is like you and he thrives in vim.

[greydius]

> "[verb] the [noun]" is pretty natural

For an English speaker. There are many human languages that put the verb at the end of clauses. Japanese is one example.

[joppy]

It is pretty common nowadays in functional programming languages to find operators which reverse the order of application or composition, so rather than writing f(g(h(x))) one can instead write “x |> h |> g |> f”. This style is quite popular, which leads me to believe that many people prefer object-action over action-object in same way. (Although perhaps this is more a critique of action-object-object vs object-action-action)

[themulticaster]

While you didn't refer to any explicit programming language (so your example is correct by definition), I think you may have mixed up something. The order is reversed, but typically not in the way you describe. For your example of f(g(h(x))), you would write (f . g . h) x in Haskell. So for this particular example, the syntactical order is not reversed.

However, you could say the natural order of reading is reversed: The naive way to read (f . g . h) might be "first f, then g, then h", opposite the actual order of execution.

[nextaccountic]

This x |> h |> g |> f syntax is Elixir (and F# perhaps? and surely other langs). In Haskell this is written

  x & h & g & f

And in shell script, this is written

  echo x | h | g | f

This operator is sometimes called the pipeline operator

Anyway, here is some ghci session exemplifying the usage of the & operator

  $ ghci
  λ import Data.Function((&))
  λ a f g h x = x & h & g & f
  λ b f g h x = (f . g . h) x
  λ c = f g h x = f (g (h x))
  λ a (+ 1) (* 2) (+ 3) 1
  9
  λ b (+ 1) (* 2) (+ 3) 1
  9
  λ c (+ 1) (* 2) (+ 3) 1
  9

It's unfortunate that this is named & in Haskell and not |>. And what's worse, it's not in the prelude.

[losvedir]

I'm assuming they were talking about Elixir, which uses that syntax to pipe the result of the left side into the first argument of the function on the right side. The transformation was correct in Elixir, and I can confirm that I at least do think that way.

[cnasc]

“Go to the store” is the action and “I’m” is the object, so your example supports the Kakoune case not the Vim case

(These are also English-specific justifications)

[0x98]

Lots of Asian languages have the nouns before verbs.

[mcepl]

Whenever you say words “natural”, or “friendly” you actually mean “what I am used to”. As the saying goes “Basically, the only ‘intuitive’ interface is the nipple. After that, it's all learned.” (Usenet discussion about Apple Macintosh).

So, no, I spent couple of years struggling with non-modal editors, where I had that feeling all the time “I have no idea how to do it effectively in this $EDITOR, while I know five keypresses which would do it for me in vim.” Finally, I have liberated myself and switched back to vim.

[NateEag]

Irrelevant nit, but:

> “Basically, the only ‘intuitive’ interface is the nipple. After that, it's all learned.”

The nipple is not intuitive for everyone.

One of our children struggled mightily with the nipple and we had a miserable two or three months of breastpumping and finger-feeding before he finally figured it out.

[ajitid]

He later corrected it by saying:

> There is no intuitive interface, not even the nipple. It's all learned.

[kerneis]

Following-up on irrelevancy: what made you stick? We had the same experience, but gave up after 6 weeks because breastpumping was exhausting, and switched to bottles and artificial milk which our daughter loved immediately.

[NateEag]

I think the belief (based on what evidence we're aware of) that breast milk is genuinely better for babies.

My wife and I are both sort of gluttons for punishment if we're convinced something is the right path.

[dotancohen]

Yeah, just wait until he gets to VIM in a few years.

[cycomanic]

Just an FYI Kakoune is a modal editor. I've actually tried it and OP has a point, for many of the things that you would use visual mode in vim things are very natural in Kakoune. It's also surprisingly accessible to someone used to vim. That said, it's difficult to leave the huge community behind vim behind.

[bla3]

If your brain prefers that order, you can emulate it in vim by doing v-movement-action, for example viwd to first select an inner word and then delete it.

[b0rsuk]

I tend to do that whenever I'm unsure what my action will actually affect. Pressing one more key is a price I can pay.

[JoshTriplett]

I do exactly this when I'm doing complex commands and want to select-verify-run. Most commonly, something like vi(c where I want to confirm how the parentheses are nested before the operation.

[oconnor663]

I found that over the years, my Vim habits have naturally moved in an "object-action" sort of direction using visual mode. I think a lot of other Vim users end up doing the same.

When I tried Kakoune for a few days, I found it difficult to adapt to the differences, but that's probably to be expected no matter what. One thing I particularly missed was g-v ("restore previous visual mode selection"), which I use constantly in Vim. There's a good chance it's doable, though, and I just didn't figure it out.

[omaranto]

Vim uses both models, it uses the object-action model in visual mode.

[pera]

> The way vim works is actually the opposite of what your brain wants, this is one of the reasons why learning vim tricks is hard.

Do you mean that you think "word change" instead of "change word"? To me this sounds like you have been programming in Java-like languages for too long :)

[robertlagrant]

Strategy Pattern Change Factory get instance word

[jsjohnst]

You forgot the factory that builds the factory that builds the factory to call get on. I’m sure you’ll need a StringBuilder or two too! ;)

[benhurmarcel]

So Kakoune is like RPN (Reverse Polish Notation), and Vim is like Polish Notation then?

For sure any user of RPN would agree that it makes more sense to type the operation after the object. Not sure how that translates to modal text editing though.

[meepmorp]

Are you making a general claim that the brain prefers object-action syntax vs action-object, or just in text editor commands?

[Firadeoclus]

I think the only general claim that could be made is that the brain prefers to be certain of what's going to happen/what did happen. To get that you either need to have a good feel for where a motion is going to end up (which is harder the more inexperienced you are, and the more complex/farther the motion), or to get feedback.

Personally, I also struggle with a relatively high rate of accidental (or mis-registered) key presses, or being in the wrong mode, which means that even if I have high confidence in constructing the right command in my head, my confidence in the right command being executed is significantly lower, and direct, always-on feedback thus feels enormously helpful to me.

[nandhinianand]

I suspect your hunch about object-action way brains work is very narrow and will not hold if extrapolated outside the western culture. My suspicion is based on a belief in [Sapi-Whorf hypothesis](https://en.wikipedia.org/wiki/Linguistic_relativity#:~:text=....). The need to reach of the object first is a very English specific language constraint afaik.

[b0rsuk]

Before I finished reading your first sentence, I knew you are a Kakoune evangelist.

object-action may be a more natural order in some languages. I use a language which permits both. So I think you're overstating how much of a deal it is. That said, Kakoune has controversial design choices in a couple of areas:

  * no explicit select mode means not only you're selecting text all the time as you move your cursor (which can be annoying). More importantly, it means there are very few keys left on the keyboard for user defined commands. This comes up all the time on the forums whenever someone asks for a new function or an unused leader key. "Fewer modes" is not a virtue in itself, because modes have other benefits like taking the weight off keyboard.
  * Shell as a scripting language. Really. It's completely awful for maintainability.
  * I continue to argue that multi-cursors are a poor man's search&replace. It doesn't show off-screen matches by default, so you don't know if you're matching anything off-screen or not.

There are Kakoune features I like very much, for example improved integration with commandline utilities. You can more easily use them to process the text inside editor.

[curriculum]

No galaxy brain here ;)

I generally don't use counts. If I want to go down a few lines, I don't count the number of lines and use 4j or whatever, I instead use / to search for the exact place I want to move to. This feels more natural and preserves the jump-list, so I can ctrl-o back to where I was.

Same if I want to delete a few words. I don't count how many I want to delete and do 4daw, instead I do daw and press . until I've deleted everything I want gone.

And I make heavy use of text objects when available. If I want to move to the next function, I use the keybinding for that instead of searching or counting lines.

[vulcan01]

Instead of counting, you can use :set relativenumber (vim/neovim builtin) to quickly see how far away lines are.

(see https://jeffkreeftmeijer.com/vim-number/)

[curriculum]

In my opinion the real downside of using <count>j and <count>k to move isn't the counting part, it's the fact that <count>k isn't a jump. That means it doesn't go into the jump list.

[tjdevries]

You can do something like this:

``` " Does: " For wrapped lines, does gj/gk " For large jumps, adds a spot on the jump list function! tj#jump_direction(letter) let jump_count = v:count

  if jump_count == 0
    call execute(printf('normal! g%s', a:letter))
    return
  endif

  if jump_count > 5
    call execute("normal! m'")
  endif

  call execute(printf('normal! %d%s', jump_count, a:letter))

endfunction ```

and map j and k to this

[nobleach]

I tried to get into that for awhile. I tend to look at the line number where I want to jump, and do <number>gg instead. It has the benefit of allowing me to look at a file and get an idea of what's on lines 400 through 425 (for example).

[anon946]

I just use a fixed count, like 5j5j5j or whatever to get me close, then jjj or whatever.

[unrealhoang]

I use ctrl + u/d to scroll up and down half screen to get near where I want to go.

[bombela]

Try the plugin easy motion. It changed my life.

[Jenk]

+1 easy motion makes the default jump-by-search feel really clunky. Typically it is mapped to double-tap leader then object, and it will then highlight those objects with a short-code to jump right to it.

Examples:

\\w -> will highlight all words after \\b -> all words before \\e -> ends of words after \\ge -> ends of words before \\fe -> all occurences of the char 'e' after \\Fe -> 'e' before \\se -> 'e' in both directions \\j -> lines after \\k -> lines before etc.

but can even use it with traditional search:

\\n -> will highlight all search-matches found by a previous "/" or "?" search after current pos. \\N -> will highlight all search-matches before.

mega useful.

[dundarious]

For me, learning about . was what made learning many of (neo)vim’s motions and text objects worthwhile. I use . constantly.

[knuthsat]

Yeah, just recently I had to edit text like this

  'name1',
  'name2',
  'name3',

to:

  'name1': Enum.Name1,
  'name2': Enum.Name2,
  'name3': Enum.Name3,

by the time I figured out a sequence of keyboard commands I'm pretty sure I could have multicursored it pretty easily, go to name1, create 2 cursors, select word & copy, start typing : Enum., paste selected word, select word, capitalize, type ,

In vim it was something like qdyi'f,i: Enum.<Esc>pbvlUq and then repeat macro.

I found it very slow to even recall.

For some reason the multicursor solution feels faster to me most times.

[vukgr]

I'm surprised everyone's forgetting vim already has a proto-multicursor mode. Go into Visual Block mode (Ctrl-V) select all the lines then it's just A<delete ,>: Enum.Name0,

After that you can just select it again in visual mode and g Ctrl-A to get the right numbers.

If anything the g Ctrl-A part makes Vim way better than most multicursor editors.

[cassepipe]

So the second time, you're entering Visual Block mode or plain Visual mode? What does the g Ctrl+A do?

[vukgr]

g Ctrl-A increments all the numbers, but every instance gets incremented by one than the previous. First line would be Enum1, second Enum2, third Enum3. It's a really neat feature imo.

Though I did make a mistake, if you selected everything it'd catch the name numbers too, so you'd have to go into visual block mode and only select the enum parts, then do g Ctrl-A.

That said the numbers probably weren't supposed to be taken seriously now that I think about it.

[cassepipe]

Thanks

[addicted]

Or, you could have hit qt, recorded your commands for the first change, and then replicated it for every other line with a simple @t, instead of redoing all the changes each time.

You don't have to learn command. You simply need to know how to edit with VIM.

And multi cursors only work for tabular data. The macro recordings can work for the entire document where you call a macro on a word/regex you searched for, for example.

[devnonymous]

I always find it strange that people recommend a different letter for the register when recommending macros. Why not just use `qq` and `@q` (with the added advantage that clearing the register is `qqq`) ?

[addicted]

The reason I don’t use q is it’s far too easy for me to accidentally hit a 3rd q when I didn’t intend to and not even realize it.

This was a bigger problem when Apple decided to go with those butterfly keys.

[michaelmior]

> multi cursors only work for tabular data

There are several plugins which allow for more complex use of multiple cursors.

* https://github.com/mg979/vim-visual-multi

* https://github.com/terryma/vim-multiple-cursors

[knuthsat]

I did record it with qd...q and repeated it with @d @@

[isaacremuant]

Visual select and normal@t (assuming you saved it in t) is a good way to do it once for every line.

[continuational]

Nope, you can do find > select all to get multiple selections and edit those simultaneously.

[ThatGeoGuy]

This can be done in (neo)vim too, and with a bit better precision and less typing.

:g/<regex>/<command>

is the general form for [g]rabbing lines that match a regex and applying a command over them. You can also chain the command:

:g/<regex1>/g/<regex2>/<command>

I'll admit this isn't exactly something you intuit as easily as a drop-down menu, but (neo)vim does have tools for all these things out of the box.

[chrismorgan]

Huh, somehow it’s never occurred to me to get binary logic by chaining :g and :v in this way—I’ve always done things in more complicated ways to make up for the lack.

[Scarbutt]

Multiple cursors is for quick small editing tasks where you don't bother with a macro.

[JamesSwift]

You probably are familiar, but for some newer folks: I almost always add a "go to beginning of next line" as the end of the macro so that I can e.g. 10@t to repeat it 10 times. Makes it much quicker than @t on each line once you have more than a few.

[mFixman]

This looks like the sort of thing you would intuitively solve with visual selection and a regex.

```

    Vjj:s/\v'(.*)',/'\1': Enum.\u\1,/

```

This is all just muscle memory. It seems impossible until you get used to it, and then it's the most natural thing in the world.

[chrismorgan]

TIL s/\u, thanks!

I know I’ve read that part of the documentation before, but probably not for over five years. In cases where I’ve wanted something like that, I’ve tended to reach for macros, visual block editing, and s/\=. A few days ago I did a somewhat more complicated one that s/\U wouldn’t be sufficient for:

  :'<,'>s/.*/\="    pub const ".substitute(toupper(submatch(0)), "[^A-Z0-9]\+", "_", "g").": &'static str = \"".submatch(0)."\";"

[mFixman]

Vim's documentation is complete and very well-written. I've been using the editor for over 10 years and I still learn new things when perusing :help.

[ARandomerDude]

Yes! When I first came from Sublime 2 I thought Vim was irritatingly difficult but hoped it would be worth it. Now I wouldn't program without it.

[chousuke]

I think I would've used something like :s/'\(.*\)',/'\1': Enum.\1,/g and then ctrl-v to block-select all the first characters and U to uppercase them.

Vi's not always about finding the most efficient way to do something, but having a composable language to do tricks like these comfortably builds up into your own dialect over time.

[heatmiser]

I’m often fallback on the sed match-replace strategy for things like this.

[mpalmer]

For me it's been a matter of practice, and forcing myself to use macros for things even when I was too slow with them to justify it in the moment. It pays off eventually and you can get a nice facility with it.

I also like using

  :g/^/norm $normal_commands

to apply anonymous macros across all lines. It works with visual selections too:

  :'<,'>g/^/norm $normal_commands

And naturally you can replace the ^ with any regex to selectively apply the macro to only lines that match!

[lelanthran]

Column editing in vim: https://youtu.be/dYDu9Hrg7yM?t=639

I saw a colleague doing the same thing (turn column of #defines into structs in an array) with multiple cursors in an IDE, took him much longer.

I paused to take a drag from my smoke while doing that.

[williamdclt]

Sorry but column editing is a stripped-down multicursor mode. I use vscode-vim (so, VSCode with Vim mode) and never use column editing because the IDE multicursor is much more powerful. Without being any sort of editing wizard, I'm finding your video example slow and mildly painful to watch

[layer8]

I would have used visual block mode to duplicate the 123 column and insert the remaining content for all three lines simultaneously. If the situation is a bit more complex, I sometimes use regex replace applied to a line range.

[chrismorgan]

> vlU

I think you meant just vU, as you were only capitalising the letter under the cursor.

You can actually also achieve this without entering visual mode: gU{motion} changes to uppercase, so gUl uppercases the letter under the cursor.

[br3akaway]

Text like that should work well with block selection/block insert mode.

[malwrar]

Like vim in general it’s not natural, but with practice you slowly start to pick up muscle memory around it. I try to shoot for easy-to-eyeball tricks, a good one is jumping to the place you want to edit with f + the first char. If there’s duplicates in between, you can use ; to go to the next occurrence of the char on that line. There’s plenty of other tricks like that that, in aggregate, makes it feel like you’re talking to your text editor vs leaving home row to click stuff.

[JamesSwift]

Exactly. The best approach is layering, in my opinion. Learn the basics, maybe a couple of tricks, and then deliberately add one more thing to your toolbox which would improve your productivity. Then incorporate that new trick into your flow until it sticks, then repeat. Eventually your toolbox is getting full and you are able to recall all the things naturally.

[ZeroGravitas]

I don't use relative jumps or N times repeats, but I do love moving by or dealing with semantic units of things at a time, whether that is a character, w/Word, quoted string, bracket contents, line, paragraph, function, xml tag content etc. and treesitter expands and standardises that across languages, which is nice.

[dkersten]

I got relatively good at vim N times counting some years back (but forgotten it now as I don't use vim as much these days). It was a practice thing. I made a point to never repeat a command more than twice and after a while it became second nature. I even got really good at guessing how many lines away things were (but nowadays I just use relative line numbers).

I never became fully fluent, but I also didn't try too hard over the "don't repeat commands" thing. And I got lazy after about a year (but also used other editors a lot more, due to team members using them and such) and over time lost the ability. Some day perhaps I'll make a point to learn again, but for now I mostly use VSCode without vim mode...

[SkyMarshal]

For many commands you’ll only have to make that calculation once, and will remember it going forward. Only commands that are extremely rarely used you may forget and have to reconstruct with the calculation again later.

[tgb]

I never use the counts (repeat N times) except for the very simple 55G to go to line 55. It's not useful. But the rest of vim is. I think of it like a chess board. A queen has more moves available than a king. Does that make it harder to move to a certain square with the queen than with the king? Not really, they're both pretty straight forward, if you're not trying to achieve the minimal edit distance to do so. You make big edits when it's obvious and just do smaller edits when it's not. The only commands I have to plan out are search-and-replaces.

[crubier]

Don't worry, you're not alone. 100% of the people I've ever saw using Vim / Neovim spend much longer "calculating" their next command than they would spend just doing in with CMD-D in VSCode.

It's frustrating to see. CMD-D in VSCode does 95% of what's needed, with no mental burden.

But hey, you can't "brag" that you "know VIM" if you use VSCode...

[nickjj]

> 100% of the people I've ever saw using Vim / Neovim spend much longer "calculating" their next command than they would spend just doing in with CMD-D in VSCode.

Right, there is mental overhead to calculate moves but often times you can extract out patterns into intuitive key mappings once you've solved the problem once.

For example, this is taken my vimrc:

    nnoremap <silent> s* :let @/='\<'.expand('<cword>').'\>'<CR>cgn
    xnoremap <silent> s* "sy:let @/=@s<CR>cgn

The basic idea here is I can either move the cursor on top of a word or select some text, hit s*, type what I want to change that text to and then hit dot (.) as many times as I want to repeat the change to the next match. It's like being able to use multiple cursors except without needing multiple cursors and I also get to see the result applied once before I start applying it to multiple things. It's also possible to skip matches using existing Vim mappings (n).

I use the above all the time to make changes in spots where I would have used multiple cursors with VSCode.

[crubier]

You prove my point. You had to create this insane macro to solve something that cmd-d does automatically in VSCode. And cmd-d is much more versatile, since the same concept applies to many other use cases.

And sorry I say insane, but not knowing the language, your macro looks absolutely absurd and as obscure as a sample of brainf*ck.

I refuse to learn such a complicated language just to create a macro that replaces cmd-d and cmd-z, just so I can brag that I use Vim.

[leephillips]

Clever! I think I might steal these, or make something based on your idea.

Kind of wild: in taking apart your command, I learned three things about Vim that I didn’t know, each one of which is massively useful. And I use it every day!

[nickjj]

> I think I might steal these, or make something based on your idea.

Sure thing, if you can improve it let me know.

Here's an even wilder thing. I set those s* mappings up about 2 weeks after using Vim and I still don't know how they work in perfect detail but I was able to find them by Googling. There's definitely a stigma that you need to be some crazy wizard to use Vim but with a bit of repetitive learning and Google you can get pretty far.

Here's a link to my vimrc around a few mappings associated to finding / replacing and multi-cursor-like things: https://github.com/nickjj/dotfiles/blob/085c4ac827290bc7aeea...

[CarelessExpert]

Keep in mind, even if you don't use motions, text objects, and counts during interactive editing (my own repertoire is pretty limited for the exact reason you mention here), they can be enormously powerful when used with macros.

[erfgh]

You can't calculate those commands because you're not meant to calculate them: They are meant for macros and scripting.

[konart]

plugins like https://github.com/phaazon/hop.nvim help a lot in cases where it may be hard to tell how to jump to point X

[discardable_dan]

I believe integrating visual mode into your usage flow can help with this a lot.

[mFixman]

You could ask the same question to anyone who touch types.

Muscle memory is a marvellous thing.

[mjlbach]

Have you tried https://github.com/nvim-treesitter/nvim-treesitter-textobjec...?

[curriculum]

Not yet! I just moved to 0.5 this weekend. But thanks for the link!

[frederikvs]

I just have vim-angry installed. It gives me "cia" and friends, though without the count you mention.

Sounds like treesitter will have more flexibility, but for now the vim-angry plugin does what I need it to :-)

[staticshock]

Seconded. vim-angry is an excellent plugin that exposes args as text objects.

In an expression such as (foo, ba|r, baz), where | is the cursor, it does the following:

via - (foo, |bar|, baz)

vaa - (foo|, bar|, baz)

vaA - (foo, |bar, |baz)

[SavantIdiot]

Aren't these features are subject to external configuration to behave properly? For example, C/C++ and #defines. The user has to configure yet another file for this to work properly. If the build system/tree is so complicated that I can't figure out what the final #defs are (like building MBED programs with literally a thousand #defs), I end up shutting off this feature entirely. This kills me with VSCode & Sublime, but Eclipse derivatives are usually more tightly coupled. What about neovim?

[Asooka]

You make your build system emit a compile-definitions.json file that has all the compiler flags for every file you compile and feed it to a language server (rtags or clangd usually, either standalone or part of another plugin like YouCompleteMe). CMake has a flag to do that as part of its configuration step (and remembers it), for other build systems you can use something like bear: https://github.com/rizsotto/Bear .

[samus]

For future reference, as I found this information to be difficult to find: the flag for CMake is `CMAKE_EXPORT_COMPILE_COMMANDS=YES`. In out-of-source builds, the output file will be in the build directory, therefore one has to create a symlink to ensure the language server finds it in the project root.

[ampdepolymerase]

I just wish Vim had proper S-expression structural editing support. Many editors have vim support but very few have smartparens/paredit with good integration. If Vim can extend its language to include some basic structural editing, then writing any type of tag based code e.g. JSX would become much more pleasant. For example in VS Code's Flutter plugin there is support for "delete surrounding widget" and "wrap child widget in new widget". They just need better keybinding integration.

[SpaceNugget]

Vim uses text objects for that kind of thing, t being the tag text object. `dat` deletes the JSX tag enclosing the cursor, `cit` deletes the contents of the tag and leaves you in insert mode, etc. Matchit (included in neovim) can also be configured to have % match tags as well as the default brackets/parens. LSP text objects are also available for more language specific structural editing.

[emidln]

vim-sexp is very very good and IMO better than smartparens/paredit. I'm not a fan of the paredit-style keybindings by default, but the way it integrates into vim's model is IMO perfect.

[ampdepolymerase]

But it is not supported in other editors (VS Code, Intellij etc.), it is not like vim-surround or easymotion where almost every major third-party vim implementation supports it.

[Kaze404]

Are there really no plugins for that? In Doom Emacs "cia" deletes an argument normally, which I assume is done by an evil mode plugin, so I thought there was one for Vim as well.

[sophacles]

Various plugins can do it on a per language basis, but tree sitter is a nice abstraction that allows such commands to be done with a simple mapping - then tree sitter (with a per-language plugin) will parse to the same ASTish thing, so any language that has function arguments will have the same commands working the same way.

I'm actually kind of excited about tree-sitter - it's not a neovim feature, it's an independent project that can be used a lot of places. I think the effect will be similar to how LSP changed the landscape from "every editor does some parts of handling language X well, but the parts each editor does are different from each other" to "all the editors get this feature when the language server does", just for syntax highlighting and syntax aware edition.

[e-v]

The plugin you are referring to is evil-args (https://github.com/wcsmith/evil-args), which is included in Doom Emacs by default.

[ashton314]

Thank you! I tried this out on my setup, but was disappointed when it didn’t work. I’m new to evil and I’m constantly impressed with how big the ecosystem is!

[curriculum]

There are, but they usually rely on regex or other brittle approaches, making it difficult to write well. And currently you'll need to use different plugins for different languages (e.g., jedi for python).

Treesitter builds the AST, making it easier to create robust text objects. And it provides a unified interface for a bunch of different languages, meaning that I don't need to have 10 different plugins, one for each language, just to get access to text objects.

[markus_zhang]

Damn this looks cool. I always want this kind of flexibility. I'm using both Jetbrain products and VS right now, and one pain point is that it's difficult to define new short-key combinations and assign a key to it.

[alpaca128]

This is one of the biggest strengths of Vim imho. Defining new keybindings is so intuitive and flexible you wonder why it's usually done differently.

With Vim you basically just tell it to map any sequence of inputs to any other sequence of inputs. If you know how to do something in Vim you can define a keybinding for it. And because Vim is 100% controllable via the keyboard you can bind anything to a shortcut.

[ponyous]

I can never remember what all those different maps do: ':map', ':map!', ':nmap', ':vmap', ':imap', ':cmap', ':smap', ':xmap', ':omap', ':lmap', etc. do. There are bunch of questions on StackOverflow about different mapping options so I wouldn't say it's intuitive at all.

[alpaca128]

The differences that actually matter are self explanatory: map is for all modes, imap for insert mode, nmap for normal mode and vmap for visual mode (& tmap for terminal mode in NeoVim). The rest can be safely ignored as far as I can tell.

Little confession: I have no idea what e.g. the difference between "nmap" and "nnoremap" is. But after years of randomly mixing them in hundreds of bindings without a noticeable difference it doesn't seem to matter. Just use map, nmap, imap and vmap, avoid duplicates and everything will be fine imho.

[Omni5cience]

You're right, for most simple use cases it doesn't matter. But I once spent an hour on a weird bug that turned out to just be some plugin applying a map that I didn't know about and that I didn't know about map expansion. So I might be biased, but I think a loose understanding is helpful.

The default behavior is to recursively expand and apply your mappings and "noremap" disables this recursion. For example if you do something like

  :map j k
  :map q j
  :noremap w j

q is expanded to k, but w is expanded to j

[alpaca128]

Thanks for this example, now I get it. It never really clicked for me when I read explanations on SO etc.

[apocolyps6]

nnoremap is "non-recursive remap" since I think its possible to chain nmaps (`nmap A B, nmap B C` will map A to C)

[ptato]

I find that I never want "map" functionality, so I do the opposite, always use "noremap".

[devenvdev]

Please someone clean that tpope searchlight! Na na na na na na na na tpope!

I would actually pay (although relatively small amount) for better programming text objects. It would feel so much more natural than the currently burned in muscle memory workarounds...

[jarbus]

What treesitter module does this fall under? I'm having a hard time finding this in the documentation. Or do users have to add this functionality themselves? Are there reference implementations for what you are describing?

[b3morales]

Right, Treesitter just gives the client program a syntax tree; it will be up to Neovim to map that to editing commands. (And the fidelity will depend on the quality of the specific language's Treesitter parser.)

[je42]

treesitter was the reason why i installed the git version of neovim ;) it is very good. so happy with with it;)