"gn" with [count] is useless

[justinmk]

"gn" is very useful. But to repeat it, user must press "." over and over. Repeating it with a [count] only applies to the count'th instance, instead of repeating the operation [count] times. This is not how f, t, and / work.

Because the current behavior of "gn" with [count] is not useful, I doubt changing the behavior of "gn" would break any plugins. Can the behavior be changed?

[chrisbra]

Other opinions?

[djjcast]

How about a command that could repeat single-repeats [count] times? Something like this:

function! s:RepeatSingleRepeat()
    for _ in range(v:count1)
        normal! 1.
    endfor
endfunction

nnoremap <silent> g. :<C-u>call <SID>RepeatSingleRepeat()<CR>

So after cgn, [count]g. would change the next [count] occurrences of @/. Although, [count]g. seems like it would only be useful after cgn.

[vim-ml]

On Wednesday, February 10, 2016 at 11:58:37 AM UTC-6, Justin M. Keyes wrote:

"gn" is very useful. But to repeat it, user must press "." over and over. Repeating it with a [count] only applies to the count'th instance, instead of repeating the operation [count] times. This is not how f, t, and / work.

Because the current behavior of "gn" with [count] is not useful, I doubt changing the behavior of "gn" would break any plugins. Can the behavior be changed?

I thought you were saying "3cgn" or "c3gn" would only edit the third occurrence, which I could see being useful and not necessarily surprising.

But then I experimented and you're saying "3." doesn't do the same thing as "...".

I agree that's unexpected and not very useful. But it's actually consistent with things like ">>". For example, ">>2." does not do what I'd expect, either; I need to do ">>..".

[vim-ml]

On Feb 11, 2016 2:16 PM, "Ben Fritz" fritzophrenic@gmail.com wrote:

On Wednesday, February 10, 2016 at 11:58:37 AM UTC-6, Justin M. Keyes
wrote:

"gn" is very useful. But to repeat it, user must press "." over and
over. Repeating it with a [count] only applies to the count'th instance,
instead of repeating the operation [count] times. This is not how f, t, and
/ work.

Because the current behavior of "gn" with [count] is not useful, I
doubt changing the behavior of "gn" would break any plugins. Can the
behavior be changed?

I thought you were saying "3cgn" or "c3gn" would only edit the third
occurrence, which I could see being useful and not necessarily surprising.

"I could see it being useful" applies to almost anything and adds no
information.
Have you ever used 3cgn intentionally, and been glad that the alternative
behavior is not implemented instead?

The major use case of gn is to apply an operation in batches. Why insist on
a default behavior which stymies that?

---

Justin M. Keyes

[vim-ml]

On Feb 11, 2016 1:29 PM, "Jerome Castaneda" vim-dev-github@256bit.org
wrote:

How about a command that could repeat single-repeats [count] times?
Something like this:

I can do all kinds of things with mappings. I am proposing improving user
experience for all users. Not the emacs way of building a private nest
full of twigs and yarn.

[bfredl]

speaking of >> I was always annoyed that 2>> and >2> mean exactly the same thing, when more usefully the first could mean repeat and the second line count (or vise versa, but I like to think of the second > as the motion) Not sure how well this applies to 2cgn vs c2gn because I haven't used it.

[vim-ml]

On Thursday, February 11, 2016 at 1:27:14 PM UTC-6, Justin M. Keyes wrote:

On Feb 11, 2016 2:16 PM, "Ben Fritz" fritzophrenic@gmail.com wrote:

On Wednesday, February 10, 2016 at 11:58:37 AM UTC-6, Justin M. Keyes wrote:

"gn" is very useful. But to repeat it, user must press "." over and over. Repeating it with a [count] only applies to the count'th instance, instead of repeating the operation [count] times. This is not how f, t, and / work.

Because the current behavior of "gn" with [count] is not useful, I doubt changing the behavior of "gn" would break any plugins. Can the behavior be changed?

I thought you were saying "3cgn" or "c3gn" would only edit the third occurrence, which I could see being useful and not necessarily surprising.

"I could see it being useful" applies to almost anything and adds no information.

Have you ever used 3cgn intentionally, and been glad that the alternative behavior is not implemented instead?

The major use case of gn is to apply an operation in batches. Why insist on a default behavior which stymies that?

If the interface was perfect for me, I'd expect "3cgn" to change the next 3 matches, and "c3gn" to change the 3rd match only, because that's something I'd do on purpose from time to time.

But to answer your question, no, I didn't realize [count]gn worked this way, especially when combined with the '.' repeat operator, so I've never done that on purpose so far.