Beta-testing 'mini.clue'

[echasnovski]

Please leave your feedback about new mini.clue module here. Feel free to either add new comment or positively upvote existing one.

Some things I am interested to find out (obviously, besides bugs):

• Are configuration and function names intuitive enough?
• Are default values of settings convenient for you?
• Is documentation and examples clear enough?

Thanks!

[Aneeqasif]

i am getting error after install

.config/lvim/lua/plugins.lua:725: module 'mini.clue' not found:\n\tno field package.preload['
mini.clue']\n\tno file './mini/clue.lua'\n\tno file '/build/neovim/src/neovim-0.9.1/.deps/usr/share/luajit-2.1.0-beta3/mini/clue.lua'\n\tno file '/usr/l
ocal/share/lua/5.1/mini/clue.lua'\n\tno file '/usr/local/share/lua/5.1/mini/clue/init.lua'\n\tno file '/build/neovim/src/neovim-0.9.1/.deps/usr/share/lu
a/5.1/mini/clue.lua'\n\tno file '/build/neovim/src/neovim-0.9.1/.deps/usr/share/lua/5.1/mini/clue/init.lua'\n\tno file './mini/clue.so'\n\tno file '/usr
/local/lib/lua/5.1/mini/clue.so'\n\tno file '/build/neovim/src/neovim-0.9.1/.deps/usr/lib/lua/5.1/mini/clue.so'\n\tno file '/usr/local/lib/lua/5.1/loada
ll.so'\n\tno file './mini.so'\n\tno file '/usr/local/lib/lua/5.1/mini.so'\n\tno file '/build/neovim/src/neovim-0.9.1/.deps/usr/lib/lua/5.1/mini.so'\n\tn
o file '/usr/local/lib/lua/5.1/loadall.so'" file="[C]", line=-1

lazy config

{'echasnovski/mini.clue',
    version = false,
    enabled=false,
    lazy=false,
    config = require('mini.clue').setup{
      triggers = {
        -- Leader triggers
        { mode = 'n', keys = '<Leader>' },
        { mode = 'x', keys = '<Leader>' },

        -- Built-in completion
        { mode = 'i', keys = '<C-x>' },

        -- `g` key
        { mode = 'n', keys = 'g' },
        { mode = 'x', keys = 'g' },

        -- Marks
        { mode = 'n', keys = "'" },
        { mode = 'n', keys = '`' },
        { mode = 'x', keys = "'" },
        { mode = 'x', keys = '`' },

        -- Registers
        { mode = 'n', keys = '"' },
        { mode = 'x', keys = '"' },
        { mode = 'i', keys = '<C-r>' },
        { mode = 'c', keys = '<C-r>' },

        -- Window commands
        { mode = 'n', keys = '<C-w>' },

        -- `z` key
        { mode = 'n', keys = 'z' },
        { mode = 'x', keys = 'z' },
      },

      clues = {
        -- Enhance this by adding descriptions for <Leader> mapping groups
        miniclue.gen_clues.builtin_completion(),
        miniclue.gen_clues.g(),
        miniclue.gen_clues.marks(),
        miniclue.gen_clues.registers(),
        miniclue.gen_clues.windows(),
        miniclue.gen_clues.z(),
      },
    },
  },

[echasnovski]

i am getting error after install

You are calling require() for the module before making it "visible" for Neovim. Try making config a function. Something like this:

{'echasnovski/mini.clue',
    version = false,
    enabled=true,
    lazy=false,
    config = function()
      local miniclue = require('mini.clue')
      miniclue.setup(
      -- Your config table
      )
    end,
  },

[haoming-li-ling]

The gcc keymap of Comment.nvim will not work unless it is triggered through mini.clue's menu at least once. Why is this happening?

[echasnovski]

The gcc keymap of Comment.nvim will not work unless it is triggered through mini.clue's menu at least once. Why is this happening?

I am not sure what you mean. As far as I can tell, gcc in 'Comment.nvim' is a separate mappings, same as in 'mini.comment' (which does work right away, as even visible in demo).

I've just tried commenting with 'Comment.nvim' and g as Normal mode trigger and it works as if without 'mini.clue'. So can not reproduce.

[farias-hecdin]

Hi, @echasnovski. 👋 Would it be possible to truncate the description of the keybinding. I.e., show three dots (...) if the number of characters of the description is greater than the size of the window?

PD: Congratulations! Your plugin is just simply amazing.

[echasnovski]

Hi, @echasnovski. wave Would it be possible to truncate the description of the keybinding. I.e., show three dots (...) if the number of characters of the description is greater than the size of the window?

PD: Congratulations! Your plugin is just simply amazing.

Thanks!

That is a great suggestion! I don't know why I didn't think about it myself. I'll look into it.

Edit: @farias-hecdin, done. This should be present on latest main. Thanks again for the idea!

[farias-hecdin]

Thanks!

That is a great suggestion! I don't know why I didn't think about it myself. I'll look into it.

Edit: @farias-hecdin, done. This should be present on latest main. Thanks again for the idea!

Wow, thanks @echasnovski. It looks great.

[MariaSolOs]

@echasnovski I'm having some trouble understanding the difference between clues and triggers. I promise that I've read the specs, but coming from which-key I'm finding the distinction confusing :/

[haoming-li-ling]

The gcc keymap of Comment.nvim will not work unless it is triggered through mini.clue's menu at least once. Why is this happening?

I am not sure what you mean. As far as I can tell, gcc in 'Comment.nvim' is a separate mappings, same as in 'mini.comment' (which does work right away, as even visible in demo).

I've just tried commenting with 'Comment.nvim' and g as Normal mode trigger and it works as if without 'mini.clue'. So can not reproduce.

So if I press gcc quickly enough so that mini.clue's menu does not show up at all, nothing happens (the current line is not commented). If I press gcc more slowly so that mini.clue's menu is visible in the process, the current line is commented. And after once triggering gcc this latter way, it will work afterwards regardless of how quickly I press the gcc keys; the current line is commented whether the mini.clue is visible or not.

So it looks like the gcc mapping is inactive (though recognized by mini.clue itself) unless triggered once through mini.clue.

[MariaSolOs]

@echasnovski what are your thoughts on creating a more comprehensive default setup? I understand (and love!) the simplicity of the mini plugins, but I feel like 99% of users will end up copy-pasting this non-trivial config, which could potentially be made into a simple preset.

[leaxoy]

Is there a way to place popup window in the center of editor? Placed in the four corners on a big screen would be a distraction.

[farzadmf]

Is there a way to place popup window in the center of editor? Placed in the four corners on a big screen would be a distraction.

+1 on this, I saw on Reddit, someone mentioned that they've done it, but, from the config, I only see anchors pointing to the 4 corners

[hbiel]

Hi @echasnovski!

Thank you for another great plugin. It looks very intriguing!

One question: Is it possible to have conditional clues? I want to show some clues only on specific buffers, for example only show the lsp group when an lsp is connected.

[echasnovski]

@MariaSolOs

@echasnovski I'm having some trouble understanding the difference between clues and triggers. I promise that I've read the specs, but coming from which-key I'm finding the distinction confusing :/

Here is the quick example:

require('mini.clue').setup({
  -- Information about when to start the special key query process.
  -- Starts the timer for clue window.
  triggers = {
    { mode = 'n', keys = '<Leader>' },
  },

  -- Information about key combinations: `desc` will be shown in clue window
  -- while `postkeys` may define "submodes".
  clues = {
    { mode = 'n', keys = '<Leader>a', desc = 'Leader a' },
    { mode = 'n', keys = '<Leader>b', desc = 'Leader b' },
  },
})

When you press <Leader> in Normal mode, it triggers the special key query process which takes over the standard procedure of typing the mapping. It looks at all available key combinations (from mappings and config.clues) to see if there are any that start with <Leader> in the Normal mode. In this case it waits for the next key, because there are more than 1 such key combinations. Here "clues" are essentially "information about key combinations".

@echasnovski what are your thoughts on creating a more comprehensive default setup? I understand (and love!) the simplicity of the mini plugins, but I feel like 99% of users will end up copy-pasting this non-trivial config, which could potentially be made into a simple preset.

At the moment I believe that 'mini.clue' config should be as explicit as possible in terms of triggers because it might lead to confusion an unexpected behavior.

[echasnovski]

So if I press gcc quickly enough so that mini.clue's menu does not show up at all, nothing happens (the current line is not commented). If I press gcc more slowly so that mini.clue's menu is visible in the process, the current line is commented. And after once triggering gcc this latter way, it will work afterwards regardless of how quickly I press the gcc keys; the current line is commented whether the mini.clue is visible or not.

So it looks like the gcc mapping is inactive (though recognized by mini.clue itself) unless triggered once through mini.clue.

@haoming-li-ling, I can not reproduce this behavior.

Couple of questions:

• Do you, by any chance, lazy load 'Comment.nvim' on certain keys? Like "lazy load it after pressing gc"? It might shed some light, but still won't fully explain the behavior you experience.
• What other mappings do you have starting with gc? You can execute the following command, copy lines from the start of the current buffer, and paste it here:

  lua vim.fn.append(0, vim.split(vim.api.nvim_exec2('nmap gc', { output = true }).output, '\n'))

[echasnovski]

@leaxoy, @farzadmf, it is possible to a certain degree by utilizing config.window.config which defines the properties of floating window (as opts in vim.api.nvim_open_win()).

Here is the most reasonable way to do it I can think of right now:

local make_win_config = function()
  local width = 40
  -- Stick to the top side at center
  return {
    anchor = 'NW',
    width = width,
    -- Height is computed automatically
    row = 'auto',
    col = math.max(math.floor(0.5 * (vim.o.columns - width)), 0),
  }
end

require('mini.clue').setup({
  window = { config = make_win_config() },
  -- The rest of config, including `clues` and `triggers`
})

-- Make sure that the window config is updated when Neovim is resized
vim.api.nvim_create_autocmd('VimResized', {
  group = vim.api.nvim_create_augroup('clue-resize', { clear = true }),
  callback = function() MiniClue.config.window.config = make_win_config() end,
})

---

Placed in the four corners on a big screen would be a distraction.

The reasoning for placing it in one of the four corners was precisely for it to not be a distraction. I think the user is already distracted if they want to look at clues, so positioning should be done for the user which doesn't want to look at clues and just taking the time to type whole mapping. The bottom right corner seemed like the best place for this.

[echasnovski]

Hi @echasnovski!

:wave:

Thank you for another great plugin. It looks very intriguing!

One question: Is it possible to have conditional clues? I want to show some clues only on specific buffers, for example only show the lsp group when an lsp is connected.

@hbiel, you have at least two options here:

• Use buffer-local variable vim.b.miniclue_config. For example, you can have it defined when LSP is attached (in on_attach()). So add something like this:

  -- Use `vim.b[buf_id].miniclue_config` if you have explicit buffer id
  vim.b.miniclue_config = {
  clues = {
  { mode = 'n', keys = '<Leader>y', desc = 'My buffer-local clue' },
  -- And so on ...
  },
  }

• Use callable (a.k.a. function) clue, as config.clues allows this specifically for this reason. So you can have something like this:

  
  local conditional_clues = function()
  -- Your logic goes here
  
  -- Should return an array of clues
  return {
  { mode = 'n', keys = '<Leader>x', desc = 'My callable clue' },
  -- And so on ...
  }
  end

require('mini.clue').setup({ clues = { conditional_clues, -- Your other clues go here }, })

Although a bit more complicated, I'd prefer the first approach with buffer-local variable because callable clues will be evaluated after **every trigger** (even if it doesn't match the conditional clues).

[jhermelink]

Hi @echasnovski, looks good so far! Thank you!

Is it possible to show register contents (after ") and marks in use (after ' and `) like which-key does?

[michaeladler]

@echasnovski This plugin is excellent; thank you. Replacing 'which-key' was simple, but I am struggling to replace some Hydras. Specifically, I'm missing hooks (functions) that execute when a sub-mode is activated. For instance, Hydra Git employs on_enter to activate Git signs, which highlight the changed lines. Is this functionality already available with mini.clue? If not, it would be a fantastic addition.

[echasnovski]

Hi @echasnovski, looks good so far! Thank you!

Is it possible to show register contents (after ") and marks in use (after ' and `) like which-key does?

@jhermelink, for registers try using miniclue.gen_clues.registers({ show_contents = true }) (see its help). It shows all possible registers, which is plenty. To show only non-empty registers, it can return callable which is not great because it will be executed on every trigger. Possible to do manually, though, and not that complicated: here is a helper function (basically, call vim.fn.getreg() and check if it is non-empty).

There is no such functionality for marks as I genuinely don't find it useful to have line number shown (not much useful information). Again, can be done manually, though.

[echasnovski]

@echasnovski This plugin is excellent; thank you. Replacing 'which-key' was simple, but I am struggling to replace some Hydras. Specifically, I'm missing hooks (functions) that execute when a sub-mode is activated. For instance, Hydra Git employs on_enter to activate Git signs, which highlight the changed lines. Is this functionality already available with mini.clue? If not, it would be a fantastic addition.

The only way to emulate submode is by creating all mappings yourself and adding postkeys to their clues. It is not (currently) possible to have any hooks, mostly because it doesn't quite align with the design of showing clues and directly executing mappings. At the moment I think that having separate hooks is quite complex while leaving it to the user to include in their mappings is more straightforward.

Having an on_exit hook is more complicated because exiting key query process doesn't depend on the current clue...

I'll think about it, but there is no high hopes right now.

[leaxoy]

Another question, does triggers support desc field.

[echasnovski]

Another question, does triggers support desc field.

No, because they are implemented as regular mappings and have their description auto generated.

Do you have any particular use case in mind for triggers to have description field?

[gj86]

Mini.Clue window doesn't show in special buffers Neo-tree, Aerial etc. Is this intentional? Since which-key does work in this special buffers I expected Mini.clue will too.

Example use case: Use of localleader mappings for specific buffers or Main leader mappings or C-w mappings etc.

Edit: Forgive my mistake. Many thanks for very useful plugins. I use several of them daily.

[echasnovski]

Mini.Clue window doesn't show in special buffers Neo-tree, Aerial etc. Is this intentional? Since which-key does work in this special buffers I expected Mini.clue will too.

Example use case: Use of localleader mappings for specific buffers or Main leader mappings or C-w mappings etc.

Edit: Forgive my mistake. Many thanks for very useful plugins. I use several of them daily.

Right now 'mini.clue' creates triggers only for listed buffers. Some "special" buffers might not be listed, so that is what you are experiencing.

The idea is that there is MiniClue.enable_buf_triggers() if user wants to also enable them in non-listed buffers.

[MariaSolOs]

@MariaSolOs

@echasnovski I'm having some trouble understanding the difference between clues and triggers. I promise that I've read the specs, but coming from which-key I'm finding the distinction confusing :/

Here is the quick example:

require('mini.clue').setup({

  -- Information about when to start the special key query process.

  -- Starts the timer for clue window.

  triggers = {

    { mode = 'n', keys = '<Leader>' },

  },

  -- Information about key combinations: `desc` will be shown in clue window

  -- while `postkeys` may define "submodes".

  clues = {

    { mode = 'n', keys = '<Leader>a', desc = 'Leader a' },

    { mode = 'n', keys = '<Leader>b', desc = 'Leader b' },

  },

})

When you press <Leader> in Normal mode, it triggers the special key query process which takes over the standard procedure of typing the mapping. It looks at all available key combinations (from mappings and config.clues) to see if there are any that start with <Leader> in the Normal mode. In this case it waits for the next key, because there are more than 1 such key combinations. Here "clues" are essentially "information about key combinations".

@echasnovski what are your thoughts on creating a more comprehensive default setup? I understand (and love!) the simplicity of the mini plugins, but I feel like 99% of users will end up copy-pasting this non-trivial config, which could potentially be made into a simple preset.

At the moment I believe that 'mini.clue' config should be as explicit as possible in terms of triggers because it might lead to confusion an unexpected behavior.

Thank you for the careful reply ♥️

[gj86]

Mini.Clue window doesn't show in special buffers Neo-tree, Aerial etc. Is this intentional? Since which-key does work in this special buffers I expected Mini.clue will too. Example use case: Use of localleader mappings for specific buffers or Main leader mappings or C-w mappings etc. Edit: Forgive my mistake. Many thanks for very useful plugins. I use several of them daily.

Right now 'mini.clue' creates triggers only for listed buffers. Some "special" buffers might not be listed, so that is what you are experiencing.

The idea is that there is MiniClue.enable_buf_triggers() if user wants to also enable them in non-listed buffers.

Thanks for the reply and explaining the concept.

I have a question about clue = {} config. For example I have this in the Mini.clue config option.

clues = { 
    { mode = 'n', keys = 'zb', desc = 'Bottom this line' },
    { mode = 'n', keys = 'zt', desc = 'Top this line' },
    { mode = 'n', keys = 'z%', desc = 'Go to inside [count]th nearest block' },
    { mode = 'n', keys = 'g%', desc = 'Cycle Next/Prev match' }

}

for vim-smoothie and vim-matchup plugin. But Mini.clue seems to ignore this and doesn't show any desc for this keys. For reference this plugins doesn't set any desc property for the keymaps.

I understand the clues config option provides information about the keymaps to Mini.clue. But why Mini.clue not using this.

[echasnovski]

I have a question about clue = {} config. For example I have this in the Mini.clue config option.

clues = { 
    { mode = 'n', keys = 'zb', desc = 'Bottom this line' },
    { mode = 'n', keys = 'zt', desc = 'Top this line' },
    { mode = 'n', keys = 'z%', desc = 'Go to inside [count]th nearest block' },
    { mode = 'n', keys = 'g%', desc = 'Cycle Next/Prev match' }

}

for vim-smoothie and vim-matchup plugin. But Mini.clue seems to ignore this and doesn't show any desc for this keys. For reference this plugins doesn't set any desc property for the keymaps.

I understand the clues config option provides information about the keymaps to Mini.clue. But why Mini.clue not using this.

It is a result of a relatively hard choice about what should have precedence: description from existing mapping or from config.clues entry. Initially I thought that config.clues should have higher precedence to allow user to "patch" mappings without descriptions. But that might lead to a hard to debug behavior: clue shows one thing, but different actual action is done.

For example, there is built-in ga mapping for which there is an entry in gen_clues.g() ("Print ascii value"). But it then can't be used along with the 'mini.align' because it will override its description ("Align").

That is why I decided that clue window will always show the description from the source that will actually be executed. In your example - mapping without description.

This was also motivated by the fact that user can add description to already created mapping. Using function like this:

_G.add_mapping_desc = function(mode, lhs, desc)
  local map_data = vim.fn.maparg(lhs, mode, false, true)
  map_data.desc = desc
  vim.fn.mapset(mode, false, map_data)
end

And then doing something like _G.add_mapping_desc('n', 'g%', 'Cycle Next/Prev match').

To be honest, I forgot about adding all of this to the documentation. I think I'll add this function directly to 'mini.clue' with motivation and instructions on how to use it. But not until tomorrow.

[gj86]

It is a result of a relatively hard choice about what should have precedence: description from existing mapping or from config.clues entry. Initially I thought that config.clues should have higher precedence to allow user to "patch" mappings without descriptions. But that might lead to a hard to debug behavior: clue shows one thing, but different actual action is done.

For example, there is built-in ga mapping for which there is an entry in gen_clues.g() ("Print ascii value"). But it then can't be used along with the 'mini.align' because it will override its description ("Align").

Even though I understand the logic, I still think user provided Clues should be prioritized. But for the builtin Clues the logic should be applied.

[ElectronSutra]

I have added s as a trigger like so:

local clue = require("mini.clue")
clue.setup({
  triggers = {
    { mode = "n", keys = "s" },
    ...
  },
})

so that I can prompt for the mini.surround actions. However, this has resulted in the following behavior using mini.starter:

As a result, I cannot select an element starting with s with a query. Since Clue doesn't pop up on other nofile buffers, I don't think this is supposed to block selecting an s... query.

[MariaSolOs]

Is there a way to have a dynamic but bounded width? I would like to set window.config.width = 'auto' but set a maximum width.

[farzadmf]

I lazy load my plugins, and for my which-key setup, I defer some keys to be added when the plugin is loaded.

which-key provides and nice utility function register(), which can be called multiple times without overriding things.

For example, in my "main" which-key setup, I have this:

require('which-key').register({
  mode = { 'n' },
  ["<leader>''"] = 'blah blah',
  -- and other ones
})

And then, in another plugin's config function, I do:

require('which-key').register({
  mode = { 'n' },
  -- other keys associated to this plugin
})

Is there a way to achieve this in mini.clue?

[MariaSolOs]

So if I press gcc quickly enough so that mini.clue's menu does not show up at all, nothing happens (the current line is not commented). If I press gcc more slowly so that mini.clue's menu is visible in the process, the current line is commented. And after once triggering gcc this latter way, it will work afterwards regardless of how quickly I press the gcc keys; the current line is commented whether the mini.clue is visible or not. So it looks like the gcc mapping is inactive (though recognized by mini.clue itself) unless triggered once through mini.clue.

@haoming-li-ling, I can not reproduce this behavior.

Couple of questions:

• Do you, by any chance, lazy load 'Comment.nvim' on certain keys? Like "lazy load it after pressing gc"? It might shed some light, but still won't fully explain the behavior you experience.
• What other mappings do you have starting with gc? You can execute the following command, copy lines from the start of the current buffer, and paste it here:

lua vim.fn.append(0, vim.split(vim.api.nvim_exec2('nmap gc', { output = true }).output, '\n'))

I'm experiencing the exact same issue that @haoming-li-ling described. The output I obtain is:

n  g           *@<Lua 448: ~/.local/share/nvim/lazy/mini.clue/lua/mini/clue.lua:1175>
                 Query keys after "g"
n  gcA         * <Lua 343: ~/.local/share/nvim/lazy/Comment.nvim/lua/Comment/api.lua:218>
                 Comment insert end of line
n  gch         * <Lua 342: ~/.local/share/nvim/lazy/Comment.nvim/lua/Comment/api.lua:179>
                 Comment insert above
n  gcl         * <Lua 341: ~/.local/share/nvim/lazy/Comment.nvim/lua/Comment/api.lua:182>
                 Comment insert below
n  gcc         * <Lua 339: ~/.local/share/nvim/lazy/Comment.nvim/lua/Comment/init.lua:103>
                 Comment toggle current line
n  gc          * <Plug>(comment_toggle_linewise)
                 Comment toggle linewise

And I do not lazy-load Comment.nvim with a key map or anything. Here's my configuration:

{
  'numToStr/Comment.nvim',
  event = 'VeryLazy',
  opts = {
    extra = { above = 'gch', below = 'gcl' },
  },
},
{
  'echasnovski/mini.clue',
  event = 'VeryLazy',
  config = function()
    local miniclue = require 'mini.clue'

    miniclue.setup {
      triggers = {
        { mode = 'n', keys = '<Leader>' },
        { mode = 'x', keys = '<Leader>' },
        { mode = 'n', keys = 'g' },
        { mode = 'x', keys = 'g' },
        { mode = 'n', keys = '`' },
        { mode = 'x', keys = '`' },
        { mode = 'n', keys = '"' },
        { mode = 'x', keys = '"' },
        { mode = 'i', keys = '<C-r>' },
        { mode = 'c', keys = '<C-r>' },
        { mode = 'n', keys = '<C-w>' },
        { mode = 'n', keys = 'z' },
        { mode = 'x', keys = 'z' },
      },
      clues = {
        miniclue.gen_clues.g(),
        miniclue.gen_clues.marks(),
        miniclue.gen_clues.registers(),
        miniclue.gen_clues.windows(),
        miniclue.gen_clues.z(),
      },
      window = {
        delay = 300,
      },
  }
  end,
}

[leaxoy]

Another question, does triggers support desc field.

No, because they are implemented as regular mappings and have their description auto generated.

Do you have any particular use case in mind for triggers to have description field?

@echasnovski That's a bad news, but any way, this is a awesome plugin and I will try replace which-key for performance.

[BenjaminKern]

So if I press gcc quickly enough so that mini.clue's menu does not show up at all, nothing happens (the current line is not commented). If I press gcc more slowly so that mini.clue's menu is visible in the process, the current line is commented. And after once triggering gcc this latter way, it will work afterwards regardless of how quickly I press the gcc keys; the current line is commented whether the mini.clue is visible or not. So it looks like the gcc mapping is inactive (though recognized by mini.clue itself) unless triggered once through mini.clue.

@haoming-li-ling, I can not reproduce this behavior. Couple of questions:

• Do you, by any chance, lazy load 'Comment.nvim' on certain keys? Like "lazy load it after pressing gc"? It might shed some light, but still won't fully explain the behavior you experience.
• What other mappings do you have starting with gc? You can execute the following command, copy lines from the start of the current buffer, and paste it here:

lua vim.fn.append(0, vim.split(vim.api.nvim_exec2('nmap gc', { output = true }).output, '\n'))

I'm experiencing the exact same issue that @haoming-li-ling described. The output I obtain is:

n  g           *@<Lua 448: ~/.local/share/nvim/lazy/mini.clue/lua/mini/clue.lua:1175>
                 Query keys after "g"
n  gcA         * <Lua 343: ~/.local/share/nvim/lazy/Comment.nvim/lua/Comment/api.lua:218>
                 Comment insert end of line
n  gch         * <Lua 342: ~/.local/share/nvim/lazy/Comment.nvim/lua/Comment/api.lua:179>
                 Comment insert above
n  gcl         * <Lua 341: ~/.local/share/nvim/lazy/Comment.nvim/lua/Comment/api.lua:182>
                 Comment insert below
n  gcc         * <Lua 339: ~/.local/share/nvim/lazy/Comment.nvim/lua/Comment/init.lua:103>
                 Comment toggle current line
n  gc          * <Plug>(comment_toggle_linewise)
                 Comment toggle linewise

And I do not lazy-load Comment.nvim with a key map or anything. Here's my configuration:

{
  'numToStr/Comment.nvim',
  event = 'VeryLazy',
  opts = {
    extra = { above = 'gch', below = 'gcl' },
  },
},
{
  'echasnovski/mini.clue',
  event = 'VeryLazy',
  config = function()
    local miniclue = require 'mini.clue'

    miniclue.setup {
      triggers = {
        { mode = 'n', keys = '<Leader>' },
        { mode = 'x', keys = '<Leader>' },
        { mode = 'n', keys = 'g' },
        { mode = 'x', keys = 'g' },
        { mode = 'n', keys = '`' },
        { mode = 'x', keys = '`' },
        { mode = 'n', keys = '"' },
        { mode = 'x', keys = '"' },
        { mode = 'i', keys = '<C-r>' },
        { mode = 'c', keys = '<C-r>' },
        { mode = 'n', keys = '<C-w>' },
        { mode = 'n', keys = 'z' },
        { mode = 'x', keys = 'z' },
      },
      clues = {
        miniclue.gen_clues.g(),
        miniclue.gen_clues.marks(),
        miniclue.gen_clues.registers(),
        miniclue.gen_clues.windows(),
        miniclue.gen_clues.z(),
      },
      window = {
        delay = 300,
      },
  }
  end,
}

Same problem here. I am using mini.comment. On mobile right now, so I can not paste the exact output as above but basically, g-> from clue.lua, gcc-> from mini/comment.lua and gc -> from mini/comment.lua (with vim-plug as plugin loader)

[echasnovski]

so that I can prompt for the mini.surround actions. However, this has resulted in the following behavior using mini.starter:

@ElectronSutra, yeah, it is a bug. I assume you call require('mini.clue').setup() after 'mini.starter' buffer is shown? Right now 'mini.clue' still creates triggers for not listed buffers during setup(). I'll push a fix later today. Thanks for noticing!

---

Is there a way to have a dynamic but bounded width? I would like to set window.config.width = 'auto' but set a maximum width.

@MariaSolOs, not at the moment, no. That would need something like max_width (along with max_height) extra config fields. Or allowing width/height to be callable (which I don't really like). I'll think about it.

---

I lazy load my plugins, and for my which-key setup, I defer some keys to be added when the plugin is loaded. ... Is there a way to achieve this in mini.clue?

@farzadmf, you can directly modify MiniClue.config and it will take effect. Although after modifying MiniClue.config.triggers you might want to call MiniClue.enable_all_triggers() to make sure that those are updated in already present buffers.

So something like this:

vim.list_extend(MiniClue.config.triggers, { { mode = 'n', keys = '<Leader>m' } })
MiniClue.enable_all_triggers()

---

@MariaSolOs, @BenjaminKern: I'll take a closer look at the gcc issue. If it happens with 'mini.comment', then I'd guess this is a plugin initialization thing. Most likely coming from lazy loading.

[grierson]

Another awesome plugin! Thank you!

As some others have noted the mini.comment's keybinding gc has stopped working since trying mini.clue.

On first opening nvim and pressing gc the keybinding gets interpreted at g@ and nothing happens. If I press g let mini.clue open then gcc it comments out the line and every run of gcc works correctly without needing mini.clue to open.

[echasnovski]

@grierson, I was able to reproduce using your config (a nice, simple, one file config :+1: ).

I believe the reason is that there are other buffer-local mappings that get created after 'mini.clue' trigger is created. In your case they come from LSP's on_attach() and nvim-treesitter's incremental selection. If they are disabled, everything works as expected.

The reason, it is "fixed" after waiting for window to open and executing is because triggers get disabled and enabled again, which makes them the latest mapping and make them work again.

I remember testing scenarios like this, but apparently missed something. Will take a look.

[grierson]

Yeh I disabled those features too and mini.comment keymapping worked again. Thank you for taking a look @echasnovski.

[BenjaminKern]

@grierson, I was able to reproduce using your config (a nice, simple, one file config 👍 ).

I believe the reason is that there are other buffer-local mappings that get created after 'mini.clue' trigger is created. In your case they come from LSP's on_attach() and nvim-treesitter's incremental selection. If they are disabled, everything works as expected.

The reason, it is "fixed" after waiting for window to open and executing is because triggers get disabled and enabled again, which makes them the latest mapping and make them work again.

I remember testing scenarios like this, but apparently missed something. Will take a look.

Ah now that you are mentioning it, i have a couple of bindings in lsp on attach defined as well

[farzadmf]

@echasnovski do you think it makes sense to have some kind of "indication" in the mini.clue window when all the items cannot fit in the current height and we'd need to scroll to see more?

[echasnovski]

@echasnovski do you think it makes sense to have some kind of "indication" in the mini.clue window when all the items cannot fit in the current height and we'd need to scroll to see more?

Not against this, just don't see an easy and informative way to do so. The best way I can this of is to change border highlight if there are not visible lines.

Plus this is only possible (with defaults) if window is maximum height, in which case chances are there is a need to scroll.

I'll think about it.

[farzadmf]

Plus this is only possible (with defaults) if window is maximum height

Yeah, that's true. I've personally hard-coded the height (I'm playing with the plugin and its options right now)

I'll think about it.

Thank you :slightly_smiling_face:

[ElectronSutra]

@ElectronSutra, yeah, it is a bug. I assume you call require('mini.clue').setup() after 'mini.starter' buffer is shown? Right now 'mini.clue' still creates triggers for not listed buffers during setup(). I'll push a fix later today. Thanks for noticing!

Yes, this is correct -- I was invoking mini.clue's setup after the mini.starter buffer was already created. I changed the sequencing to load mini.clue first and the starter menu filtering now works as expected, so you were spot-on. Just to confirm what you probably already knew 😆

[echasnovski]

I've just pushed several updates.

---

@ElectronSutra, the issue with 'mini.starter' should be gone: triggers now can only be created for listed buffers.

---

@gj86, I still stand by the choice of having mapping description take precedence over user-supplied clues. To mitigate the issue for non-user created mappings, there is a MiniClue.set_mapping_desc() helper along with notes about the behavior.

---

@haoming-li-ling, @MariaSolOs, @BenjaminKern, @grierson. Regarding "gcc issue".

Unfortunately, the issue indeed is that triggers have to be the latest created buffer-local mappings. Here is a full description of the problem. I don't think there is a full proof solution to this, only on a case by case basis.

Here is what I ended up doing:

• Created a huge note describing the issue.
• Exported ensure_buf_triggers() for users to call after new buffer-local mapping is created overshadowing some trigger.
• Ensure proper trigger mappings on LspAttach event which should solve the issue of many people using LSP's on_attach() to create buffer local mappings like gd/gD (thus messing with g trigger).

There is also the case of gnn mapping from 'nvim-treesitter' for incremental selection, but I haven't (yet) found a way to automatically run MiniClue.ensure_buf_triggers() after 'nvim-treesitter' made its mapping. Running that function sometime after that should be enough. Not sure about the best approach here, though.

[ElectronSutra]

Works like a charm! Thank you for your excellent work.

[degnbol]

Thanks for the great plugin. I found two things so far to note. 1: After pressing leader it lists everything well but adds an entry for a key I don't have on the keyboard (Þ, icelandic thorn). I don't recall mapping this, but assuming it is mapped somehow then I think a way to manually disable some clues would be a feature request. 2: I can't replace the description of the thorn by setting clues={{ mode = 'n', keys = '<leader>þ', desc = "hello" }}. or couldn't do it for gc (go comment), gcc (go comment line) or any other combination that has already been set somewhere else.

[echasnovski]

1: After pressing leader it lists everything well but adds an entry for a key I don't have on the keyboard (Þ, icelandic thorn). I don't recall mapping this, but assuming it is mapped somehow then I think a way to manually disable some clues would be a feature request.

'mini.clue' takes description from all present keymaps and user-supplied clues. Most probably, the source of <Leader>Þ is 'folke/which-key.nvim' which uses this as a way to activate the window. Disabling 'follke/which-key.nvim' should fix the situation.

'mini.clue' will always show all present keymaps and configured clues as to avoid confusion of "why there is no clue when it should be?". It is left to the user to manage their keymaps.

2: I can't replace the description of the thorn by setting clues={{ mode = 'n', keys = '<leader>þ', desc = "hello" }}. or couldn't do it for gc (go comment), gcc (go comment line) or any other combination that has already been set somewhere else.

Yes, if clue is taken from existing mapping, its description takes precedence over user-supplied clue. This is done to show as relevant as possible clue.

Here is a suggested approach to handling this.

[degnbol]

Thanks for the quick reply.

Yes, if clue is taken from existing mapping, its description takes precedence over user-supplied clue. This is done to show as relevant as possible clue.

In that case I think an exception could be considered for when the existing mapping has an empty description, e.g. in my case for gc and gcc.

[echasnovski]

Yes, if clue is taken from existing mapping, its description takes precedence over user-supplied clue. This is done to show as relevant as possible clue.

In that case I think an exception could be considered for when the existing mapping has an empty description, e.g. in my case for gc and gcc.

I don't think this is a good idea as it contradicts "show as relevant information as possible" principle. If pressing next key will lead to executing a mapping without description, then user should know about it. To add description to an existing mapping, use MiniClue.set_mapping_desc().