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!

[FilipHarald]

Awesome plugin @echasnovski , very nice that you've also added standard clues for common commands. One thing that I think is neat with which-key is that if you don't add a description it will just take the function name of the Vimscript-function. So that I don't have to populate all the descriptions. I attach a comparison between which-key and clue when I press <leader>, both of them have minimal config.

Is there some clever way in that this is possible?

which-key clue

[echasnovski]

Judging by your config, those are not the names of Vimscript-funcions, but rather a commands (like <Leader>b is :Buffers, etc.).

Currently I am not a fan of supporting any type of auto-guessing of mapping description. I honestly feel that relying on user/plugins setting proper desc field is a better overall approach. Although, it would require using Lua and vim.keymap.set() (or vim.api.nvim_set_keymap()). Take a look at this example.

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

@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 ...
  },
}

...

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

Thanks! That works perfectly. I don't even find it more complicated as I used the same approach previously with Which-Key.

I just needed the hint for using a buffer-local variable - i hadn't seen that part in the docs.

[simonmandlik]

Hi, thanks for the great plugin. I'm trying to decide between mini.clue and which-key, and one thing about which-key that I like is that it plays well together with lazy loading on keys (described here). Currently, such keys are not shown, until invoked for the first time and the plugin is loaded. Is there any way around this?

[echasnovski]

Hi, thanks for the great plugin. I'm trying to decide between mini.clue and which-key, and one thing about which-key that I like is that it plays well together with lazy loading on keys (described here). Currently, such keys are not shown, until invoked for the first time and the plugin is loaded. Is there any way around this?

I am not sure I fully understand you here. Do you want to lazy load on keys 'mini.clue' itself or some other plugins which creates mappings to be shown inside clue window?

If lazy load 'mini.clue' itself, then I don't think there is much to do from 'mini.clue' side: everything depends on 'lazy.nvim' here.

If lazy load some plugin which will create mappings, then it is slightly simpler: 'mini.clue' computes clue info from already existing mappings and user-supplied clues (favoring the former). If you want to postpone creation of any mapping but still for them to be available before the first press, manually supply necessary information in config.clues.

[simonmandlik]

I understand, thanks!

[hbiel]

I have got another question:

Would it be possible to show clues directly when entering operator pending (and perhaps other modes)? which-key does this and shows keys for motions / textobjects.

Maybe this proposal on which-key helps regarding a possible implementation: https://github.com/folke/which-key.nvim/issues/469

[echasnovski]

I have got another question:

Would it be possible to show clues directly when entering operator pending (and perhaps other modes)? which-key does this and shows keys for motions / textobjects.

Maybe this proposal on which-key helps regarding a possible implementation: folke/which-key.nvim#469

'mini.clue' works for all basic modes. I would advise to expect issues when using clues for Operator-pending mode.

If trigger is supplied for Operator-pending mode (like { mode = 'o', keys = 'i' }), it will already work the same way as in Normal mode: gather clues from existing mappings and user-supplied clues. If you are using 'mini.ai', this will need manual adding of clues, as it creates only mappings for a/i (possibly with their "next"/"last" counterparts).

There is no gen_clues.mini_ai because promoting Operator-pending mode triggers and clues is not something I'd like to do within 'mini.clue' as they don't work 100%. Plus, to show always fully relevant textobjects, it would need to be executable, which is the last reserve.

[hbiel]

I have got another question: Would it be possible to show clues directly when entering operator pending (and perhaps other modes)? which-key does this and shows keys for motions / textobjects. Maybe this proposal on which-key helps regarding a possible implementation: folke/which-key.nvim#469

'mini.clue' works for all basic modes. I would advise to expect issues when using clues for Operator-pending mode.

If trigger is supplied for Operator-pending mode (like { mode = 'o', keys = 'i' }), it will already work the same way as in Normal mode: gather clues from existing mappings and user-supplied clues. If you are using 'mini.ai', this will need manual adding of clues, as it creates only mappings for a/i (possibly with their "next"/"last" counterparts).

There is no gen_clues.mini_ai because promoting Operator-pending mode triggers and clues is not something I'd like to do within 'mini.clue' as they don't work 100%. Plus, to show always fully relevant textobjects, it would need to be executable, which is the last reserve.

I meant to show clues upon entering a new mode. Without pressing further keys.

For example pressing d or y enters o-p mode and I'd like to see clues for immediately possible keys. E.g. $ / w / etc. Same can be true for visual mode.

So I guess what I'm really asking for is to be able to define mode changes as additional triggers for showing clues.

Does that make sense?

[echasnovski]

So I guess what I'm really asking for is to be able to define mode changes as additional triggers for showing clues.

Does that make sense?

Ah, yes, it does clear things up! Thanks!

That is an interesting idea. I'll think about possible ways to do that, but my first instinct is that I don't really like this approach. Mostly because very close result can (in theory) be achieved by making keys for operators being triggers. Like, adding { mode = 'n', keys = 'd' }, { mode = 'n', keys = 'c' }, etc.

[hbiel]

Ah, yes, it does clear things up! Thanks!

That is an interesting idea. I'll think about possible ways to do that, but my first instinct is that I don't really like this approach. Mostly because very close result can (in theory) be achieved by making keys for operators being triggers. Like, adding { mode = 'n', keys = 'd' }, { mode = 'n', keys = 'c' }, etc.

That was my first idea too. But when I tried those triggers it didn't seem to work. I'll try it again later.

I thought that might be a limitation because the mode switches on those key presses.

[echasnovski]

That was my first idea too. But when I tried those triggers it didn't seem to work. I'll try it again later.

I thought that might be a limitation because the mode switches on those key presses.

Just actually tried myself: yes, it doesn't seem to work. And precisely for the reason you explained (mode has changed). For this approach to work, something like this needs to be inside setup():

miniclue.setup({
  clues = {
    { mode = 'n', keys = 'di', desc = 'Delete inside' },
    { mode = 'n', keys = 'da', desc = 'Delete around' },
  },

  triggers = {
    { mode = 'n', keys = 'd' },
  },
})

This is suboptimal to say the least. I'll keep that in mind (but still not really like how this approach might fit into the current design).

[hbiel]

Just actually tried myself: yes, it doesn't seem to work. And precisely for the reason you explained (mode has changed). For this approach to work, something like this needs to be inside setup():

miniclue.setup({
  clues = {
    { mode = 'n', keys = 'di', desc = 'Delete inside' },
    { mode = 'n', keys = 'da', desc = 'Delete around' },
  },

  triggers = {
    { mode = 'n', keys = 'd' },
  },
})

This is suboptimal to say the least. I'll keep that in mind (but still not really like how this approach might fit into the current design).

I played around a bit with that configuration and this way it behaves just like which-key. I actually built a function to generate clues of combinations of operator + motion / textobject which already works quite nicely.

And I also had an idea that might be a better fit:

The plugin could provide an API to show clues for a prefix of key sequences (or none).

This allows users to manually or programmatically start the key query process for a given set of keys (without actually pressing them). The prefix can be left empty so that the first set of available keys is shown.

I think this would be very flexible as the discussed trigger on mode changes could then be added to ones config via a simple autocommand. It would also avoid the need for an immense amount of clues for all the possible key combinations spread across different modes.

What do you think?

[echasnovski]

And I also had an idea that might be a better fit:

The plugin could provide an API to show clues for a prefix of key sequences (or none).

This allows users to manually or programmatically start the key query process for a given set of keys (without actually pressing them). The prefix can be left empty so that the first set of available keys is shown.

I think this would be very flexible as the discussed trigger on mode changes could then be added to ones config via a simple autocommand. It would also avoid the need for an immense amount of clues for all the possible key combinations spread across different modes.

What do you think?

This is interesting. My first thoughts:

• It might come with a significant amount of testing and documentation burden.
• Exporting a dedicated function might not be that easy because of some implementation details (like accounting for the fact that triggers need to be disabled during reproducing keys).
• Currently empty query is automatically stops process. This seems like a more intuitive approach when pressing <BS> after initial trigger. Allowing empty query for programmable start will add the friction.

This module is already quite large (even though around 400 lines come from gen_clues "batteries included" portion), so I am extra hesitant to adding new stuff. I'll think about it, but still don't have my hopes up.

[hbiel]

This is interesting. My first thoughts:

• It might come with a significant amount of testing and documentation burden.
• Exporting a dedicated function might not be that easy because of some implementation details (like accounting for the fact that triggers need to be disabled during reproducing keys).
• Currently empty query is automatically stops process. This seems like a more intuitive approach when pressing <BS> after initial trigger. Allowing empty query for programmable start will add the friction.

This module is already quite large (even though around 400 lines come from gen_clues "batteries included" portion), so I am extra hesitant to adding new stuff. I'll think about it, but still don't have my hopes up.

I see. I didn't get too deep into the code itself so I might have underestimated the work to do.

Maybe I'll take a deeper dive when I got more time.

Thank you for taking the time and consideration!

[haoming-li-ling]

I replaced <c-w> with <leader>w by mapping the latter to the former through vim.keymap.set("n", "<leader>w", "<c-w>") . Is there a way to show the clues originally meant for <c-w> for <leader>w?

[echasnovski]

I replaced <c-w> with <leader>w by mapping the latter to the former through vim.keymap.set("n", "<leader>w", "<c-w>"). Is there a way to show the clues originally meant for <c-w> for <leader>w?

Sure. All functions from MiniClue.gen_clue return an array of clues with this structure. Replacing <C-w> with <Leader>w in output of MiniClue.gen_clues.windows() should do the trick.

Try something like this:

local miniclue = require('mini.clue')
local ctrlw_clues = miniclue.gen_clues.windows()
local leaderw_clues = vim.tbl_map(function(x)
  x.keys = x.keys:gsub('^<C%-w>', '<Leader>w')
  return x
end, ctrlw_clues)

miniclue.setup({
  triggers = {
    { mode = 'n', keys = '<Leader>' },
    -- Your other triggers go here
  },
  clues = {
    leaderw_clues,
    -- Your other clues go here
  },
})

[thenbe]

Would it be possible to implement a submode that "holds ctrl for you"? i.e. I want to be able to do this:

1. Press <c-d>
2. Page is scrolled once. Also we are now in "scrolling submode": a. press d to scroll down b. press u to scroll up c. press anything else to abort the submode

The same submode should be accessible from <c-u>

If this is possible, how would you recommend approaching it?

On an related note, the fact that this plugin does not depend on timeout is a killer feature. Thank you.

[echasnovski]

Would it be possible to implement a submode that "holds ctrl for you"? i.e. I want to be able to do this:

1. Press `<c-d>`

2. Page is scrolled once. Also we are now in "scrolling submode":
   a. press `d` to scroll down
   b. press `u` to scroll up
   c. press anything else to abort the submode

The same submode should be accessible from <c-u>

If this is possible, how would you recommend approaching it?

Directly as described - no, I don't think so. This is mostly because Ctrl is not considered to be a separate key but a modifier and 'mini.clue' work for key presses.

I would suggest going the more usual "hydra"-like route by creating dedicated keymaps and using those to scroll. So something like this:

local nmap = function(lhs, rhs, desc) vim.keymap.set('n', lhs, rhs, { desc = desc }) end

local scroll_submode_keys = '<Leader>s'
nmap(scroll_submode_keys .. 'b', '<C-b>', 'Scroll up')
nmap(scroll_submode_keys .. 'd', '<C-d>', 'Scroll down half')
nmap(scroll_submode_keys .. 'f', '<C-f>', 'Scroll down')
nmap(scroll_submode_keys .. 'u', '<C-u>', 'Scroll up half')

require('mini.clue').setup({
  clues = {
    { mode = 'n', keys = scroll_submode_keys .. 'b', postkeys = scroll_submode_keys },
    { mode = 'n', keys = scroll_submode_keys .. 'd', postkeys = scroll_submode_keys },
    { mode = 'n', keys = scroll_submode_keys .. 'f', postkeys = scroll_submode_keys },
    { mode = 'n', keys = scroll_submode_keys .. 'u', postkeys = scroll_submode_keys },
  },
  triggers = {
    { mode = 'n', keys = scroll_submode_keys },
  },
})

On an related note, the fact that this plugin does not depend on timeout is a killer feature. Thank you.

:heart:

[thenbe]

I gave it a go and the submode keys behave as expected. However it seems this effectively disables smooth scrolling. Both mini.animate and neoscroll.nvim had the same behavior (no smooth scrolling). Is this known behavior? Or is there some sort floating window option I can pass to config.window.config to enable smooth scrolling in submode?

[debugloop]

Hi @echasnovski, thanks for another great module! I could replace my hydra configs easily and I like the new handling much better, there is however one issue: Some plugins do not update the main window (i.e. the only one in my case) correctly. One prominent example is in my git submode. A clue like { mode = 'n', keys = '<leader>gd', postkeys = '<leader>g' } with a mapping rhs <leader>gd to:

function()
  require("gitsigns").toggle_deleted()
  require("gitsigns").refresh()
end,

Will not toggle the deleted lines until I close the clue window. The same is true on a clue submode for debugging, where debugging start or steps are not rendered until I dismiss the clue window.

[echasnovski]

I gave it a go and the submode keys behave as expected. However it seems this effectively disables smooth scrolling. Both mini.animate and neoscroll.nvim had the same behavior (no smooth scrolling). Is this known behavior? Or is there some sort floating window option I can pass to config.window.config to enable smooth scrolling in submode?

@thenbe, Yeah, I noticed it too. I am not too sure, but afraid this is just a limitation of how 'mini.clue' works. It uses getcharstr() for its key query process which blocks any non-explicit redraw Neovim wants to do (including animated scroll).

This might be solvable via some dirty hacks (like make custom scrolling mappings which force redraws inside a timer for some time), or maybe not.

I might take a closer look, but to be honest, can't see this as a high priority right now.

[echasnovski]

Hi @echasnovski, thanks for another great module! I could replace my hydra configs easily and I like the new handling much better, there is however one issue: Some plugins do not update the main window (i.e. the only one in my case) correctly. One prominent example is in my git submode. A clue like { mode = 'n', keys = '<leader>gd', postkeys = '<leader>g' } with a mapping rhs <leader>gd to:

function()
  require("gitsigns").toggle_deleted()
  require("gitsigns").refresh()
end,

Will not toggle the deleted lines until I close the clue window. The same is true on a clue submode for debugging, where debugging start or steps are not rendered until I dismiss the clue window.

@debugloop, interestingly enough, this also seems to relate to my previous comment of getcharstr() not allowing to redraw. What seems to happen is that after <Leader>gd is executed, 'mini.clue' goes into listening for another key (as submode does) blocking redraw.

I tried this mapping right hand side which seems to work:

function()
  require('gitsigns').toggle_deleted()
  require('gitsigns').refresh()
  -- Force through 'mini.clue' blocking redraw
  vim.schedule(function() vim.cmd('redraw!') end)
end

[fabianpage]

Hi

I relly like mini.clue, it has a nice functionality.

On problem i have is when i set mapleader to . Then it will only work for the first leader sequence afterworks the leader mappings doesn't work anymore. With leader on " " i can use it several times without problems.

[echasnovski]

On problem i have is when i set mapleader to . Then it will only work for the first leader sequence afterworks the leader mappings doesn't work anymore. With leader on " " i can use it several times without problems.

Yeah, I can reproduce some issues when using <F*> key as trigger. Will investigate.

Edit: @fabianpage, I hope this should be fixed on latest main. Could you, please, try it? Side note: I really suggest you to reconsider using <F2> as your Leader key. Unless you have some very non-standard keyboard, using popular alternatives (such as <Space> and ,) is much more convenient.

[thenbe]

I'm seeing a bug where the characters from an expr map are entered literally into the buffer.

Repro:

-- mini.clue config
{
  triggers = {
    { mode = "i", keys = "<C-x>" },
  },
  clues = {
    miniclue.gen_clues.builtin_completion(),
  },
}

Create this keymap somewhere

-- Proper indentation on empty line
map("n", "i", function()
    if #vim.fn.getline(".") == 0 then
        return [["_cc]]
    else
        return "i"
    end
end, { expr = true })

0. Create an html file with the following content:

<html>
    <br/>

</html>

1. place cursor on 3rd (empty) line
2. press i. you should now be insert mode. your cursor should also be indented automatically.
3. press <c-x><c-v>
4. observe that the characters "_ are literally inserted into the buffer

[echasnovski]

I'm seeing a bug where the characters from an expr map are entered literally into the buffer.

Thanks for noticing this! Should be fixed on latest main.

[fabianpage]

@echasnovski Thanks for working on that! For me with "rev": "ff00eec0fe5e897aab3b88d3499c4eb7a8cd9ad8" I still get the same behaviour on F2 but if it's working for you maybe there is something wrong with my config.

I have a small split keyboard which I can program freely, and I am trying out what I can do with the F-Keys.

[debugloop]

@debugloop, interestingly enough, this also seems to relate to my previous comment of getcharstr() not allowing to redraw. What seems to happen is that after <Leader>gd is executed, 'mini.clue' goes into listening for another key (as submode does) blocking redraw.

I tried this mapping right hand side which seems to work:

function()
  require('gitsigns').toggle_deleted()
  require('gitsigns').refresh()
  -- Force through 'mini.clue' blocking redraw
  vim.schedule(function() vim.cmd('redraw!') end)
end

I've tried for some time now but redraw does not cleanly work on all cases. While gitsigns works tolerably well, I still rather disabled the submode on that (It's gimmicky anyways 😅).

Where it really does not work great is on nvim-dap stepping, and I'm kinda unwilling to ditch the submode for this functionality as well. I think the redraw does not work too well because it does not wait for the external debugger it's adapting. I could go for a explicit and scheduled redraw hook on dap operations maybe, but at this point I might go back to hydra for debugger operations 🤔

[echasnovski]

Where it really does not work great is on nvim-dap stepping, and I'm kinda unwilling to ditch the submode for this functionality as well. I think the redraw does not work too well because it does not wait for the external debugger it's adapting. I could go for a explicit and scheduled redraw hook on dap operations maybe, but at this point I might go back to hydra for debugger operations 🤔

Thanks for reminding me of the redraw issue. I am working on another module that has similar issue but it is more noticeable right away. I managed to solve this similarly as you described by making timer which repeatedly redraws with certain delays. I think I'll add this in 'mini.clue' also.

@debugloop, I've pushed the clue-redraw branch which should now force redraws (not immediately per se, but good enough). I've tested with your original code (without manual redrawing) and it works. Could you, please, test it on your side both for 'gitsigns.nvim' and your DAP use case?

[echasnovski]

@echasnovski Thanks for working on that! For me with "rev": "ff00eec0fe5e897aab3b88d3499c4eb7a8cd9ad8" I still get the same behaviour on F2 but if it's working for you maybe there is something wrong with my config.

@fabianpage, how do you set up your leader and 'mini.clue'. The way I tested it (and which is recommended) is by setting vim.g.mapleader right away and then used '<Leader>' string inside 'mini.clue' config.

I've tested with this minimal config and it works for me (i.e. pressing <F2> and waiting leads to showing clue window; later pressing a prints message):

vim.g.mapleader = vim.api.nvim_replace_termcodes('<F2>', true, true, true)

vim.keymap.set('n', '<Leader>a', '<Cmd>echo "This is <Leader>a"<CR>')

require('mini.clue').setup({
  triggers = { { mode = 'n', keys = '<Leader>' } },
})

[fabianpage]

@echasnovski Thanks for your help! I used let mapleader = "<F2>", with he lua config from you (especially nvim_replace_termcodes) the config runs perfectly 👍

[mhanberg]

Trying this out now, seems to function as expect.

Clarity question: how long is the window supposed to take to appear? is that dependent on a neovim global setting?

I notice if i hit <space> it takes almost 2 seconds for it to appear and about a second when hitting other triggers (like leader and ctrl-w)

edit: this plugin is really highlighting how many of my keymaps are lacking a desc 😂

[echasnovski]

Clarity question: how long is the window supposed to take to appear? is that dependent on a neovim global setting?

I notice if i hit <space> it takes almost 2 seconds for it to appear and about a second when hitting other triggers (like leader and ctrl-w)

It should exactly config.window.delay milliseconds when functioning properly. What you describe is a symptom of a buffer-local mapping that starts with <Space> and is made after 'mini.clue' makes its mapping for trigger. See this note for more details. Unfortunately, I don't see a better way to resolve this.

If you happen to indeed have buffer local mappings that is created after <Space>, I'll see if it is reasonable to account for that in 'mini.clue' (similar to accounting for LspAttach event where several mappings starting from g is common to be made).

[farzadmf]

I have a couple of issues which are somehow related to each other.

Background: I have some bindings (using vim-abolish) for cr... bindings in normal mode, and I have something like this in my config:

-- vim.notify('there!', vim.log.levels.INFO)
vim.list_extend(MiniClue.config.triggers, {
  { mode = 'n', keys = 'c' },
})
vim.list_extend(MiniClue.config.clues, {
  { mode = 'n', keys = 'cr', desc = '+coerce' },
  { mode = 'n', keys = 'cr-', desc = 'to dash-case' },
  -- and other ones
})
MiniClue.enable_all_triggers()

But, the issue I have is that once I press c, no desc is shown for r:

(for the subsequent letters, say cr-, I do see the clue.

---

Now, my second issue arising from above is this: I'm using vim-visual-multi, and when I go to multi-cursor mode, c is supposed to act similar to a visual c (change: delete text and go to insert mode), but when I press c, I see the mini.clue window, which breaks everything: I'm out of multi cursor mode, but the multi-cursor highlight is still there, so I have to start from scratch :laughing:

I hope I could describe the issue clearly. If not, please let me know, and I can clarify

---

Side: in the screenshot I posted, would you be able to help me to know what that last entry is (the weird character that I know what's called). I see that character in basically all mini.clue windows :stuck_out_tongue_closed_eyes:

[echasnovski]

But, the issue I have is that once I press c, no desc is shown for r:

Most probably, you have cr as an actual mapping without description. If there is mapping and clue with the same mode-keys pair, description from mapping is preferred. Either remove mapping or update its description as described in the link.

To see if this is true, execute :nmap c and see if there is an entry for cr.

Side: in the screenshot I posted, would you be able to help me to know what that last entry is (the weird character that I know what's called). I see that character in basically all mini.clue windows 😝

This looks like coming from 'folke/which-key.nvim' which does create these kind of mappings to be able to display its window. To confirm, execute :nmap c. Removing/disabling 'folke/which-key.nvim' should remove that character.

Now, my second issue arising from above is this: I'm using vim-visual-multi, and when I go to multi-cursor mode, c is supposed to act similar to a visual c (change: delete text and go to insert mode), but when I press c, I see the mini.clue window, which breaks everything: I'm out of multi cursor mode, but the multi-cursor highlight is still there, so I have to start from scratch 😆

I hope I could describe the issue clearly. If not, please let me know, and I can clarify

I am kind of tempted to say that 'vim-visual-multi' mappings are not supported in 'mini.clue'. It does quite magic stuff under the hood, so I don't really want to dig into it.

[echasnovski]

@debugloop, I've pushed the clue-redraw branch which should now force redraws (not immediately per se, but good enough). I've tested with your original code (without manual redrawing) and it works. Could you, please, test it on your side both for 'gitsigns.nvim' and your DAP use case?

@debugloop, the automated redraw functionality is now in main branch.

[farzadmf]

It does quite magic stuff under the hood, so I don't really want to dig into it.

Totally makes sense @echasnovski ; I already appreciate the time you take for these replies.

Was just wondering if there could potentially be a workaround or something like what you suggested in #448 ; maybe to temporarily disable the c clue for mini.clue and re-enable it or something

[debugloop]

@debugloop, the automated redraw functionality is now in main branch.

Ah sorry, I must've read your comment before your edit. I'll test it out tomorrow, thank you! 🌟

[echasnovski]

Was just wondering if there could potentially be a workaround or something like what you suggested in #448 ; maybe to temporarily disable the c clue for mini.clue and re-enable it or something

@farzadmf, well, there are disable_buf_triggers() and enable_buf_triggers(), which were exported specifically for users to workaround unexpected tricky tasks. You can start by trying similar modification as in #448 with prepending <Cmd>lua MiniClue.disable_buf_triggers()<CR> at the start and <Cmd>lua MiniClue.enable_buf_triggers()<CR> at the the end.

[farzadmf]

@echasnovski so I'm doing something like this (from #448 along with the new lines) (the function to remap my <C-n>):

_G.remap_with_ignore_winscrolled = function(mode, lhs)
  local rhs = vim.fn.maparg(lhs, mode)
  local new_rhs = table.concat({
    '<cmd>lua MiniClue.disable_buf_triggers()<cr>',
    '<cmd>let g:eventignore = &eventignore | set eventignore=WinScrolled<cr>',
    rhs,
    '<cmd>let &eventignore = g:eventignore<cr>',
    '<cmd>lua MiniClue.enable_buf_triggers()<cr>',
  })
end
_G.remap_with_ignore_winscrolled('n', '<C-n>')

It seems like it does disable mini.clue, but a bit too late somehow.

When I press C-n and go to visual-multi mode, the first time I press c, it shows mini.clue, but not on the subsequent ones.

I tried to write a lua version of it:

local rhs_func = function()
  MiniClue.disable_buf_triggers()
  vim.cmd([[let g:eventignore = &eventignore | set eventignore=WinScrolled]])
  -- vim.cmd(rhs) <---- can't figure this out
  vim.cmd([[let &eventignore = g:eventignore]])
  MiniClue.enable_buf_triggers()
end
vim.keymap.set(mode, lhs, rhs_func)

rhs seems to be <Plug>(VM-Find-Under), which I'm not sure how to call in Lua :slightly_frowning_face:

---

Moreover, I don't think the last two lines are being called because mini.clue remains disabled, and I need to manually call :lua MiniClue.enable_buf_triggers() to re-enable it

[debugloop]

@echasnovski builtin redrawing works much better than the schedule hack, thanks! 🚀

[echasnovski]

rhs seems to be <Plug>(VM-Find-Under), which I'm not sure how to call in Lua 🙁

@farzadmf , that makes at least two of us. That huge Vimscript command approach was the only way I could find (with help of some other more knowledgeable people). As 'vim-visual-multi' doesn't seem to officially export any actual functions for its actions, I don't know the other way.

Sorry, but I won't dig deeper in 'vim-visual-multi' stuff. Better wait for multicursors to be in Neovim core (or #452 is resolved ;) ).

[abeldekat]

Thanks for this great plugin!

Would it be possible to add a configuration option specifying the ordering of items? Specifically, I would like to have the leader list ordered, having single items on top and group items below.

[echasnovski]

Thanks for this great plugin!

Would it be possible to add a configuration option specifying the ordering of items? Specifically, I would like to have the leader list ordered, having single items on top and group items below.

I've thought about that a bit, but didn't come up with simple enough interface for people to use. It should allow sorting by both key and/or description, so maybe an array with { key, desc } fields as input and similar as output?

'mini.nvim' is on feature freeze right now before the 0.10.0, so I'll create an issue for that. Edit: #454.

[farzadmf]

Sorry, but I won't dig deeper in 'vim-visual-multi' stuff. Better wait for multicursors to be in Neovim core (or #452 is resolved ;) ).

@echasnovski those are really good alternatives, but seems like both/each will take a while :wink:

I just remembered that a while back, I opened an issue in vim-visual-multi about an issue in which-key that I'm suspecting was along the same lines as this one I'm having with mini.clue, and VM's author created a PR to fix it.

Do you think this could be something useful that can be integrated into mini.clue?

[echasnovski]

@echasnovski those are really good alternatives, but seems like both/each will take a while 😉

I just remembered that a while back, I opened an issue in vim-visual-multi about an issue in which-key that I'm suspecting was along the same lines as this one I'm having with mini.clue, and VM's author created a PR to fix it.

Do you think this could be something useful that can be integrated into mini.clue?

If this is indeed a one line if addition which makes 'vim-visual-multi' work ok, then sure, it is reasonable to add. But I won't look into it. Feel free to tweak it yourself and then creating PR (with steps on how to reproduce the issue that is being fixes).

[farzadmf]

Sure, I can take a look (time allowing). Can you point me to where this might be useful to add to make it work, so that I can check once I get the time?

[echasnovski]

Sure, I can take a look (time allowing). Can you point me to where this might be useful to add to make it work, so that I can check once I get the time?

Somewhere in the 'mini.clue' file. Judging by the PR itself, good first places to look are in how triggers are mapped or how state is advancing.

[MariaSolOs]

@echasnovski sorry to ping you, but have you given a deeper thought at my request of having a dynamic but bounded width? I had initially suggested setting window.config.width = 'auto' and another field for setting max_width, but what do you think of allowing window.config.width to be a table of minimum and maximum widths? I'm just trying to address your concerns regarding maintainability.

I'm also happy to help with the contribution of such a feature :)