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

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).

Start with the mini.clue submode configuration and existing submode behavior, then compare the requested opt-in workflow with the hydra.nvim reference linked in the issue. Done means each submode can independently hide the clue window and exit on another key while executing that key's normal action; the optional indicator is separately scoped.