Allow submodes without the clue window and exiting a submode with any key

[dpomykala]

Contributing guidelines

• I have read CONTRIBUTING.md
• I have read CODE_OF_CONDUCT.md

Module(s)

mini.clue

Description

Hi there!

First of all, thank you for your work and amazing plugins! 👏

Feature request

I would like to ask about a functionality specific to the mini.clue module and the submodes feature. Basically, my request consists of two main parts (and one extra):

1. Allow (via configuration, per each clue/submode) to change the default behavior, so that the clue window is not shown when inside a submode.
2. Allow (via configuration, per each clue/submode) to exit the current submode without the need for pressing Esc. Any key different than the submode key should result in ending the submode and executing the default action for that key.
3. (optional / nice to have) Allow (via configuration) to show some minimal indicator for the current submode only (e.g. in a small unobtrusive window or as a status line component).

Rationale

Currently, when using a submode, the window containing clues is always visible. This is great for many scenarios, but sometimes it might not be ideal. When repeating actions for mappings that are often used, there is no benefit with showing all the possible clues.

A good example would be the mappings from the mini.bracketed module. When switching buffers with [b / ]b I don't necessarily need to see all possible mappings for the entire [ / ] group (which is quite a lot) when I am already inside a submode. The reasons for this are as follows:

• This is a mapping I use very often, so I know exactly what it does and I don't need a reminder while already inside a submode.
• There is a very little chance that I would want to use some other [ / ] mapping while in a buffer-switching submode.
• The clue window in this case is visual noise and it distracts from the actual goal (which is to switch to the target buffer).

Note that I am talking here about not showing the clue window inside a submode only. The sequence would be something like:

] -> the clues for the ] group are displayed -> b -> the mapping executed (next buffer), the clues are hidden, entered the submode (if defined for this key) -> bbbbbb -> switching buffers without the clue window visible

On the similar note (the second part of this feature request), when exiting a submode it would be great if any other key would allow to break from a submode (not only Esc). So, for the above example, any other key than b. E.g. ]bbbbbbbj -> the j key ends the submode and moves the cursor down (so j is immediately executed).

This scenario can be replicated for many other common mappings where the clue window can restrict visibility, e.g.:

• Jumping between git hunks in a file e.g. ]hhhhh.
• Jumping between diagnostics e.g. ]dddddd.
• Jumping between conflicts e.g. ]qqqqqq.
  etc.

I think the described behavior is implemented in hydra.nvim:
https://github.com/nvimtools/hydra.nvim

To quote their README:

Once you summon the Hydra through the prefixed binding (the body + any one head), all heads can be called in succession with only a short extension.

The Hydra is vanquished once Hercules, any binding that isn't the Hydra's head, arrives. Note that Hercules, besides vanquishing the Hydra, will still serve his original purpose, calling his proper command. This makes the Hydra very seamless.

I don't know if this is something you would consider to add, but I think it would be great to support (with opt-in) more "hydra-like" workflows in mini.clue. Configuring both mini.clues and hydra.nvim seems like overkill. Especially since mini.clue already has very similar features (submodes).

[echasnovski]

Thanks for the suggestion and kind words!

1. Allow (via configuration, per each clue/submode) to change the default behavior, so that the clue window is not shown when inside a submode.

In this exact form it would probably won't happen, but I think adding something like postkeys_window_delay value to any clue (with default 0 which is essentially what is used now) might be reasonable. Then setting it to a very big value (like 10000000) will essentially stop window from appearing if it is not already shown. It would still keep window shown if it was already shown (which seems reasonable to me, as it is a more general rule in 'mini.clue').

2. Allow (via configuration, per each clue/submode) to exit the current submode without the need for pressing Esc. Any key different than the submode key should result in ending the submode and executing the default action for that key.

This is already partially the case, but with a caveat. Submodes are "emulated" with postkeys, which are treated exactly as the name implies: sequence of keys that are "executed" (more like pretended to be executed by the implemented key query process). Pressing any key that does not have registered clue/mapping will end the submode, but it will still be treated as pressing postkeys + any key.

Following the later example, here is the sequence of events:

• Press ]. As it is a trigger, 'mini.clue' starts its key query process.
• Press b. As it is "terminal next key" with registered postkeys, two things happen:
  • 'mini.clue' emulates pressing ]b.
  • 'mini.clue' pretends that another ] is pressed.
• Pressing b any number of times acts as previous step.
• Pressing something like e will lead to 'mini.clue' emulate pressing ]e and stop the key query process (because it doesn't have a registered clue with postkeys). While pressing j instead of e will lead to executing ]j (which is "forward jump" from 'mini.bracketed') and also stopping key query process (as there is no postkeys).

3. (optional / nice to have) Allow (via configuration) to show some minimal indicator for the current submode only (e.g. in a small unobtrusive window or as a status line component).

Sorry, this is out of scope. The main design of 'mini.clue' is to have postkeys like functionality and that postkey being displayed via the window with its title.

---

All in all, I'll take a look at whether adding custom window delay for postkeys (either local to clues or more global delay_postkey) is feasible here. Everything else will probably stay as it is now.

[dpomykala]

Thanks for the reply and the explanation of the key query process!

I understand if you don't want to go "full hydra" with this. Something like postkeys_window_delay could potentially be a workaround to support this use case (at least partially).