mini.clue append to triggers after calling setup function

[farzadmf]

Hi there,

In my setup, I lazy load all my plugins and some of them are activated using lazy.nvim's keys option.

Also, I have set up things in a way that I "append" to my which-key config when a plugin is setup/loaded (so that if I disable the plugin, I don't see the "empty" descriptions in which-key)

I want to achieve a similar thing with mini.clue. I checked the doc and I think all the examples show the configuration along with calling setup function.

But for me, I want to do things after my mini.clue's setup (which uses event = 'VeryLazy').

Is there a way I can update triggers after setup?

[echasnovski]

Hi!

This is possible, but not really what 'mini.clue' was designed for. Hence a bit awkward.

Currently used config of all modules is available as config field of module's global variable (as per general principles). So of 'mini.clue' it would be MiniClue.config.

So modifying triggers is as easy as directly modifying MiniClue.config.triggers. But with the following caveats:

• It has to be done after require('mini.clue').setup(), because it relies on the MiniClue global variable.
• Specifically triggers are implemented as buffer-local mappings. So in order for them to be up to date for already opened buffers, there needs to be a call to either ensure_all_triggers() or ensure_buf_triggers(). This would not have been a problem for modifying, say, clues.

So all in all, I guess the answer is "yes, but with caveats because 'mini.clue' is not really designed for this use case". I'd advise setting triggers in the single require('mini.clue').setup() and relying on the mapping's descriptions provided by the plugins (which automatically used as clues).

[farzadmf]

Thank you @echasnovski for the detailed answer.

The main reason I'm using this method is for something like this: let's say I load a plugin that adds its own "group" of key bindings, so I want that plugin to be in charge; if it loads, it brings in its keys (and their group), if not, no binding is in the list.

If I set up all the groups in mini.clue's setup, and that plugin is not loaded (for whatever reason), then I'll see an empty group with no bindings inside. (I use wk.register(...) to achieve this.

[echasnovski]

The main reason I'm using this method is for something like this: let's say I load a plugin that adds its own "group" of key bindings, so I want that plugin to be in charge; if it loads, it brings in its keys (and their group), if not, no binding is in the list.

Now, that is usually a bit different than registering triggers. I don't see any particular harm in registering common triggers (like <Leader>, g, etc.) inside require('mini.clue').setup().

If plugin adds its own mappings, they are picked up automatically based on their description. So here all there is needed to do is add them when making mappings.

Adding the "group" is as straightforward as table.insert(MiniClue.config.clues, { mode = 'n', keys = '<Leader>f', desc = '+Find' }). This still requires require('mini.clue').setup() to be called prior, but no need to ensure triggers.

[farzadmf]

Thank you @echasnovski for your answer. Let me elaborate a bit more maybe it would be more clear:

My use case:

• As I mentioned, I lazy load all my plugins, and I have a plugin that's loading on keys
• I have a "generic" group <leader>c for coding stuff.
• I want this new plugin to bring in, say, <leader>cd for "coding/debug".
• Then, inside of "coding/debug", I'll have individual mappings relted to the plugin.
• Now, I want <leader>cd to only be displayed if this specific plugin is loaded because, if it's not, it will be an empty list (which is not very useful).

Trying it now, I tried to print MiniClue in:

• init()
• opts (which I'm setting to a function() instead of a static Lua table)
• And also inside keys (which is also set to a function()).

And in all places, MiniClue is nil (although this plugin is loaded on keys, but mini.clue is loaded on VeryLazy). I tried to add mini.clue in dependencies, hoping to get a table for MiniClue, but it's still nil.

[echasnovski]

And in all places, MiniClue is nil (although this plugin is loaded on keys, but mini.clue is loaded on VeryLazy). I tried to add mini.clue in dependencies, hoping to get a table for MiniClue, but it's still nil.

Sorry, but this is more about how you load plugins. What I can say from 'mini.nvim' point of view, is that require('mini.clue').setup() should be executed prior to be able to use _G.MiniClue as global variable.

[farzadmf]

Hey @echasnovski , a follow-up on this:

As a "real world example" of what I'm hoping to achieve is this LazyVim commit, which, ironically, is done for mini.ai, done by a Neovim legend just like yourself, folke.

As you can see, some mappings are created dynamically and registered using require('which-key').register(...); if someone sets enabled = false for mini.ai in there (just for the sake of example), nothing will break and nothing needs updating; just that those mappings/descriptions won't be registered.

Following your guidance above, I managed to register some of my existing "groups" in mini.clue (by calling table.insert(MiniClue.config.clues, ...), but trying to adapt the LazyVim commit I mentioned to mini.clue doesn't seem to work.

I'm trying to use the i and a tables defined in there for mini.clue, with something like this:

for k, v in pairs(i) do
  table.insert(MiniClue.config.clues, { mode = 'x', keys = 'i' .. k, desc = v })
  table.insert(MiniClue.config.clues, { mode = 'o', keys = 'i' .. k, desc = v })
  table.insert(MiniClue.config.clues, { mode = 'x', keys = 'a' .. k, desc = v:gsub(' including.*', '') })
  table.insert(MiniClue.config.clues, { mode = 'o', keys = 'a' .. k, desc = v:gsub(' including.*', '') })
end

I've also set v as a trigger:

triggers = {
  -- ...
  { mode = 'n', keys = 'v' },
},

But, doing something like v in normal mode, I see this:

Which feels like none of my table.inserts above had any effect.

Also, I think mini.ai, by default, adds the Around/inside textobject descriptions to mappings, which don't seem to be picked up by mini.clue and my configured v trigger.

Sorry if it became long; tried to show that I'm actually trying things and not asking questions without anything on my side.

[echasnovski]

There are several issues with this, which need to be addressed first before investigating further:

• Adding { mode = 'n', keys = 'v' } as trigger is not a good idea. This implies that you want to show Normal mode mappings that start with v. Instead the goal (I think) is to show all Visual mode mappings. Unfortunately, 'mini.clue' doesn't work like that (show clues "across" modes) and it is a known limitation. The best attempt to show all mappings when mode changed was [WIP] (mini.clue) expose function to start a query #442, but it felt to introduce too much complication to the module.
  The best suggestion here is to use { mode = 'x', keys = 'i' } and { mode = 'x', keys = 'a' } to show clues after pressing "i" / "a" in Visual mode.
• Trying out 'mini.clue' features with 'which-key.nvim' enabled is also not a good idea. It seems to be the case here because of that strange symbol present in clues ('which-key.nvim' uses it for its internal purposes). Try completely disabling 'which-key.nvim' and take a look again.