"crr" default mapping does not emit ModeChanged after "c" about neovim

[justinmk]

If we can keep the behavior of c going immediately to operator pending mode while still allowing mappings under the c "namespace", that seems like the best path forward.

Yes, exactly. Solve that problem, rather than imposing this weird restriction on the entire unmapped space below c/y/etc.

One obvious, short-term, workaround is to implement cr as a c mapping which immediately fires ModeChanged, then waits with getchar() and handles "r" specially. Disadvantage is that :map cr won't show the expected mappings (but :map c would show something).

Another idea is to change the internal "keymap pending" logic to be smarter.

They use F2 and F4 (which I've seen others suggest in reddit) for rename and code action, which is rather unorthodox for Neovim but are the same mappings used by Windows file explorer.

This makes no sense. Hand-wringing over a cr mapping for a mode-change detail (historical purity), but no problem with a bunch of function-key mappings (historical impurity)?

And all of this because people don't want to unmap default mappings?

I do find crr and crn odd choices for LSP mappings given how important the c operator is.

The mapping isn't interfering with "c" at all. "c" was chosen precisely because these mappings are related to change.

The mode-change thing can be fixed.

[gpanders]

We reverted the default mappings in #28649. Until a solution is found to fundamentally solve the issues mentioned in this issue (in particular, avoiding conflicts with text objects/motions) we will avoid c prefixed keys for defaults.

[gpanders]

I do find crr and crn odd choices for LSP mappings given how important the c operator is.

@gpanders should we reconsider this?

These default mappings do not interfere with any c behavior though. The issue here is only that it interferes with the visual indication that the user is in operator pending mode in the specific (and unusual) case that the user presses only c and no other keys. I am not yet convinced that that is a problem that many users care about, or that outweighs the benefit of having default mappings for useful functionality. Most of the time when using c you will quickly enter a motion like cw or cb, etc.

If we need to revert these defaults then I am not optimistic that we will be able to find any default mappings that are satisfactory, and that is imo a worse outcome. People can always delete the mappings if they don’t want them.

[gpanders]

The OP mentioned a handful of plugins this directly affects. Predominantly reactive.nvim that provides visual feedback/highlights for operators. I think that's a pretty strong use case, especially given that the default value for timeoutlen is 1000ms. Some people are quite sensitive when their entire startup time exceeds 1/10 of that.

I'm sorry, but I still am waiting to hear how this affects any use case other than pressing c and sitting and waiting. Frankly, I don't think that is a use case that is common enough or important enough to warrant deleting defaults which are useful for a much larger portion of users.

I watched some of the demo videos in the reactive.nvim README (@rasulomaroff very cool plugin by the way, nice work!). The operator pending highlights are still applied when the user presses e.g. ci or ca.

reactive.nvim could change the default 'timeoutlen' to a smaller value. Or Nvim could consider changing the default to a smaller value. Or we can wait to see what idea @justinmk has to address this:

It's mostly a limitation of the current mappings behavior; we can have a default cr mapping while still emitting "op pending" after c. I have some ideas, but will save them for the separate issue.

If we can keep the behavior of c going immediately to operator pending mode while still allowing mappings under the c "namespace", that seems like the best path forward. The alternative is to impose a blanket prohibition on any default mappings that start with c which is needlessly restrictive.

The mappings defined by https://lsp-zero.netlify.app/v3.x/language-server-configuration.html seem quite good to me. They use F2 and F4 (which I've seen others suggest in reddit) for rename and code action, which is rather unorthodox for Neovim but are the same mappings used by Windows file explorer.

I think F keys are a non-starter with Justin, and frankly I agree. Plenty of keyboards don't have function keys at all, and on some that do (like a MacBook keyboard) they are inconvenient to type.

[echasnovski]

The mapping isn't interfering with "c" at all.

This is not 100% accurate and something that should be taken into account for possible future new mappings that start the same way as operator.

Having such Normal mode mapping introduces collisions for possible operator targets. In particular, at least three r, rr, and rn as motions/textobjects will work only if there is a 'timeoutlen' delay after single c. Those are implemented in Operator-pending mode so having it collide with Normal mode mapping can be confusing, thus making those choices a lot less appealing.

Suggesting users to delete the mapping is, of course, an option (another story is how good it is), but at least having these points in mind seems necessary.

[rasulomaroff]

@gpanders Although I don't necessarily like crr and crn mappings for what they're doing, because for me they're kind of not intuitive enough (I have <leader>ga and <leader>rn for those actions), I'm also not in the "revert and avoid" team, because if neovim continues to avoid those "collisions", it can end up choosing not sane defaults for those actions.

These default mappings do not interfere with any c behavior though. The issue here is only that it interferes with the visual indication that the user is in operator pending mode in the specific (and unusual) case that the user presses only c and no other keys.

I agree with you on the matter that this is a visual issue, but I also think it depends how you interpret it. For example I could say that for me, when I press c I expect ModeChanged event to be triggered right away, because I intend to change some text-object (maybe I have some callbacks set up or whatever) and that won't happen anymore.

Another thing is even though operator-pending mode will be triggered when I press the next key, for example i for ciw or a for caw (if new ci*/ca* aren't introduced in the future), I'm a type of a user who expects the editor to react to that when I press the very first key :) This is the reason I love neovim and I'm sure I'm not alone, as @lewis6991 mentioned here:

Some people are quite sensitive when their entire startup time exceeds 1/10 of that.

People can always delete the mappings if they don’t want them.

True, and this is what I and many other people will do in this case. But is it a good sign that a lot of people would prefer to remove the defaults because they somehow make the editor experience not good enough? I believe that defaults for sure need to be, but they shouldn't interfere your experience, in other words, you shouldn't notice them if you don't use them (my opinion). For now it's only 2 lines of vim.keymap.del, but in the future, when new mappings are introduced, it can become 5-10-n lines just to achieve/sustain the same behaviour you had before. I don't think this is a good indicator.

I watched some of the demo videos in the reactive.nvim README (@rasulomaroff very cool plugin by the way, nice work!). The operator pending highlights are still applied when the user presses e.g. ci or ca.

reactive.nvim could change the default 'timeoutlen' to a smaller value. Or Nvim could consider changing the default to a smaller value. Or we can wait to see what idea @justinmk has to address this:

Honestly I don't believe that changing 'timeoutlen' will solve anything in this case, it will just make the experience slightly not annoying :D

Thank you for the kind words, I really appreciate it!

I had some devs coming and saying that reactive is not working when using some operators and it always ended up having mappings from nvim-surround like ds, ys, cs or other plugins. I'm using <leader>s* for all surrounding mappings, but would switch back to its defaults if it didn't change this visual feedback. So, if @justinmk has a solution that would somehow fix this, it would be a massive win-win for everybody.

[echasnovski]

in my config to workaround that as mentioned in the docs. But from that experience, I would recommend backing out that one mapping in visual mode.

It is not set in Visual mode on latest master already after #28537.

[lewis6991]

I do find crr and crn odd choices for LSP mappings given how important the c operator is.

@gpanders should we reconsider this?

[lewis6991]

I interpreted the issue more being this interfering with the ModeChanged autocmd which I think is a pretty big problem.

If we need to revert these defaults then I am not optimistic that we will be able to find any default mappings that are satisfactory

Is c really the only good candidate for these mappings? To me it does seem problematic given how prominent c is used as an operator.

I do think this change was made way too late in the cycle (like other changes), and that it probably needed more thought and time to bake.

People can always delete the mappings if they don’t want them.

Sorry but I don't think this is a great response, especially since this is interfering with other built-in functionality. Plugins that depend on ModeChanged to detect when c is activated is perfectly valid and probably one of the main applications for ModeChanged.

[gpanders]

I interpreted the issue more being this interfering with the ModeChanged autocmd which I think is a pretty big problem.

The default mappings to do not interfere with the ModeChanged autocmd. For instance, pressing cw fires the ModeChanged event twice with patterns n:no and no:i, just as it does without any default mappings.

It sounds like the only "problem" the default mappings introduce is that pressing c alone (with no motion) means I have to wait a few extra milliseconds for the first ModeChanged event. But what actual, real world issues does that present? Are there any, or is this hypothetical?

Is c really the only good candidate for these mappings? To me it does seem problematic given how prominent c is used as an operator.

I don't know, perhaps not. I am not married to the specific mappings, but I do feel strongly about providing some defaults.

I do think this change was made way too late in the cycle (like other changes), and that it probably needed more thought and time to bake.

I am not totally opposed to this, although again I am still not convinced that this breaks any actual work flows. It all sounds hypothetical and abstract at the moment.

People can always delete the mappings if they don’t want them.

Sorry but I don't think this is a great response, especially since this is interfering with other built-in functionality. Plugins that depend on ModeChanged to detect when c is activated is perfectly valid and probably one of the main applications for ModeChanged.

You're right, I apologize for the glibness, it was not a good response. But in response to the second part of your sentence, I'll repeat that this does not impact the ModeChanged event.

[lewis6991]

It sounds like the only "problem" the default mappings introduce is that pressing c alone (with no motion) means I have to wait a few extra milliseconds for the first ModeChanged event. But what actual, real world issues does that present? Are there any, or is this hypothetical?

The OP mentioned a handful of plugins this directly affects. Predominantly reactive.nvim that provides visual feedback/highlights for operators. I think that's a pretty strong use case, especially given that the default value for timeoutlen is 1000ms. Some people are quite sensitive when their entire startup time exceeds 1/10 of that.

I don't know, perhaps not. I am not married to the specific mappings, but I do feel strongly about providing some defaults.

The mappings defined by https://lsp-zero.netlify.app/v3.x/language-server-configuration.html seem quite good to me. They use F2 and F4 (which I've seen others suggest in reddit) for rename and code action, which is rather unorthodox for Neovim but are the same mappings used by Windows file explorer.

[casr]

But what actual, real world issues does that present? Are there any, or is this hypothetical?

An example would be highlighting a selection of characters in visual mode, typing c and then having to wait timeoutlen for visual feedback. That is new behaviour for quite a common use case in my opinion.

I've added

vim.keymap.del('v', 'crr')

in my config to workaround that as mentioned in the docs. But from that experience, I would recommend backing out that one mapping in visual mode.

[justinmk]

Having such Normal mode mapping introduces collisions for possible operator targets. In particular, at least three r, rr, and rn as motions/textobjects will work only if there is a 'timeoutlen' delay after single c.

Any mapping removes potential alternative uses of that mapping. We are choosing to to decide that "r" is not a new text-object or motion, instead it's a "refactor" namespace. If we have concrete plans to introduce "r" as a new motion or text-object, that changes the story. Do we? Or is there a popular, existing motion/text-object that claims "r"?

[echasnovski]

Any mapping removes potential alternative uses of that mapping.

This is of course true for any mapping, but when Normal mode mapping start the same as some operator (c, d, y), it is slightly different. For example, crr Normal mode mapping removes possibility for all r and rr Operator-pending mode mappings that start with r. How bad this consequence is is another story, but that should be taken into account.

We are choosing to to decide that "r" is not a new text-object or motion, instead it's a "refactor" namespace.

Alternative suggestion might be to claim a bigger namespace for LSP itself. Which might be "gl", which is unclaimed in core but has some usages as "align" operator.

If we have concrete plans to introduce "r" as a new motion or text-object, that changes the story. Do we? Or is there a popular, existing motion/text-object that claims "r"?

Not sure how "popular" can be classified, but 'chrisgrieser/nvim-various-textobjs' claims "r" for "rest of the paragraph".