Beta-testing 'mini.clue' #430
Comments
|
i am getting error after install 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(),
},
},
}, |
You are calling {'echasnovski/mini.clue',
version = false,
enabled=true,
lazy=false,
config = function()
local miniclue = require('mini.clue')
miniclue.setup(
-- Your config table
)
end,
}, |
|
The |
I am not sure what you mean. As far as I can tell, I've just tried commenting with 'Comment.nvim' and |
|
Hi, @echasnovski. 👋 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 |
Wow, thanks @echasnovski. It looks great. |
|
@echasnovski I'm having some trouble understanding the difference between clues and triggers. I promise that I've read the specs, but coming from |
So if I press So it looks like the |
|
@echasnovski what are your thoughts on creating a more comprehensive default setup? I understand (and love!) the simplicity of the |
|
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 |
|
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. |
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
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. |
@haoming-li-ling, I can not reproduce this behavior. Couple of questions:
|
|
@leaxoy, @farzadmf, it is possible to a certain degree by utilizing 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,
})
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. |
👋
@hbiel, you have at least two options here:
-- 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 ...
},
}
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). |
|
Hi @echasnovski, looks good so far! Thank you! Is it possible to show register contents (after |
|
@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 |
@jhermelink, for registers try using 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. |
The only way to emulate submode is by creating all mappings yourself and adding Having an I'll think about it, but there is no high hopes right now. |
|
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? |
|
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 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 |
Thank you for the careful reply |
Thanks for the reply and explaining the concept. I have a question about for I understand the |
It is a result of a relatively hard choice about what should have precedence: description from existing mapping or from For example, there is built-in 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)
endAnd then doing something like 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. |
The first one is the matter of missing clues. I believe that you test 'folke/which-key.nvim' with LazyVim? Because it explicitly adds items for 'mini.ai'. It comes from how 'mini.ai' implements its textobjects: it creates only mappings for The second one (after single
Probably not, as
I tried to think about indicating that some clues are not shown, but didn't come up with something both concise to implement and useful for users. Currently suggested approach is to use default automatic height and assume that there more lines if clue window takes maximum height (from tabline to statusline). If it is shorter than that, then there are no more clues. |
@simonmandlik This was a quick attempt at replicating how LazyVim registers textobjects explicitly. It can probably be implemented in a better way.
{
"echasnovski/mini.clue",
opts = function(_, opts)
---@type table<string, string|table>
local i = {
[" "] = "Whitespace",
['"'] = 'Balanced "',
["'"] = "Balanced '",
["`"] = "Balanced `",
["("] = "Balanced (",
[")"] = "Balanced ) including white-space",
[">"] = "Balanced > including white-space",
["<lt>"] = "Balanced <",
["]"] = "Balanced ] including white-space",
["["] = "Balanced [",
["}"] = "Balanced } including white-space",
["{"] = "Balanced {",
["?"] = "User Prompt",
_ = "Underscore",
a = "Argument",
b = "Balanced ), ], }",
c = "Class",
f = "Function",
o = "Block, conditional, loop",
q = "Quote `, \", '",
t = "Tag",
}
local a = vim.deepcopy(i)
for k, v in pairs(a) do
a[k] = v:gsub(" including.*", "")
end
-- Example of desired clues output:
-- { mode = "o", keys = "if", desc = "Inside Function" },
-- { mode = "o", keys = "af", desc = "Around Function" },
-- { mode = "o", keys = "inf", desc = "Inside next Function" },
-- { mode = "o", keys = "ilf", desc = "Inside last Function" },
-- { mode = "o", keys = "anf", desc = "Around next Function" },
-- { mode = "o", keys = "alf", desc = "Around last Function" },
local clues = {}
for key, name in pairs(i) do
table.insert(clues, { mode = "o", keys = "i" .. key, desc = "Inside " .. name })
end
for key, name in pairs(a) do
table.insert(clues, { mode = "o", keys = "a" .. key, desc = "Around " .. name })
end
for key1, name1 in pairs({ n = "Next", l = "Last" }) do
for key2, name2 in pairs(i) do
-- stylua: ignore
table.insert(clues, { mode = "o", keys = "i" .. key1 .. key2, desc = "Inside " .. name1 .. " " .. name2 })
end
for key2, name2 in pairs(a) do
-- stylua: ignore
table.insert(clues, { mode = "o", keys = "a" .. key1 .. key2, desc = "Around " .. name1 .. " " .. name2 })
end
end
local triggers = {
{ mode = "o", keys = "i", desc = "inside" },
{ mode = "o", keys = "a", desc = "around" },
}
for _, trigger in ipairs(triggers) do
table.insert(opts.triggers, trigger)
end
for _, clue in ipairs(clues) do
table.insert(opts.clues, clue)
end
end,
}, |
No no, I'm not using local root = vim.fn.fnamemodify("./.repro", ":p")
for _, name in ipairs({ "config", "data", "state", "cache" }) do
vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)
local plugins = {
{
"echasnovski/mini.clue",
version = "*",
config = function()
local miniclue = require('mini.clue')
miniclue.setup({
triggers = {
{ mode = "o", keys = "a" },
{ mode = "o", keys = "i" },
{ mode = "n", keys = "y" },
{ mode = "n", keys = "d" },
{ mode = 'n', keys = 'g' },
{ mode = 'x', keys = 'g' },
{ mode = 'n', keys = '<C-w>' },
},
clues = {
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(),
},
})
end
},
}
require("lazy").setup(plugins, {
root = root .. "/plugins",
})
vim.o.termguicolors = true
vim.cmd("colorscheme evening")The core of my question was about builtins. With the config above get no clues for clues = {
{ mode = "o", keys = "iw", desc = "test1" },
{ mode = "n", keys = "d$", desc = "test2" },
}and they show. Could these clues be collected and provided e.g. as |
That probably wasn't the best example, still neovim shows e.g. |
|
@echasnovski I just found an issue using this plugin with Screen.Recording.2023-09-02.at.3.36.11.PM.mov |
The cursor itself also disappears. If you use a submode with jumps (eg. with Mini.bracketed), you need to enable |
@simonmandlik, I don't think so. I'd rather err on the side of caution and not provide built-in clues for Operator-pending mode which 'mini.clue' can't support 100%. |
@MariaSolOs, I think this is how 'nvim-treesitter-context' works. Some of its autocommands closes context when there is a floating window opened. I can reproduce same behavior when floating window from 'mini.completion' is opened.
It does in the demo, but I can not reproduce this (on Neovim 0.9.1). Disappearing cursor (or rather "moving to command line" cursor) when |
|
I was on One issue that is still wonky is the following jump. When I trigger it, the cursor jumps to the command line on ~every other trigger. {
"lewis6991/gitsigns.nvim",
keys = {
{ "]e", function() require("gitsigns").next_hunk() end, desc = "Hunk backward" },
{ "[e", function() require("gitsigns").prev_hunk() end, desc = "Hunk forward" },
}
}The following change improved things, the cursor no longer jumps to the command line. {
"lewis6991/gitsigns.nvim",
keys = {
- { "]e", function() require("gitsigns").next_hunk() end, desc = "Hunk backward" },
+ { "]e", function() require("gitsigns").next_hunk({ navigation_message = false }) end, desc = "Hunk backward" },
- { "[e", function() require("gitsigns").prev_hunk() end, desc = "Hunk forward" },
+ { "[e", function() require("gitsigns").prev_hunk({ navigation_message = false }) end, desc = "Hunk forward" },
}
}The cursor still sometimes "overshoots" the hunk, but as soon as you exit the submode, the cursor will jump up to the correct position. I thought it maybe had something to do with tldr; submode is difficult to use alongside noice.nvim (as of time of writing) |
Interesting. I don't have that behaviour with |
Well, then the way we create floating window might differ. Or something else. But the fact that I see this not only with 'mini.clue' does point to some different (more systemic) reason. |
Well I found the explanation. Both |
Interesting. Yes, that might be it. |
@echasnovski I don't think you actually need to do anything here, since we can just add EDIT 1: Never mind, that's not a good solution since now the window isn't properly resized when typing the next character of a key sequence... EDIT 2: Adding Lines 1521 to 1526 in 3a3e19d I have a branch with the modification, but it seems like I don't have the permissions to open a PR... |
|
@echasnovski what are your thoughts about adding a setting for hiding mappings with no descriptions? |
Extremely against. Not only this is an extra setting, but also clues without description do provide information that there is some actual mapping without description. 'mini.clue' is designed around the idea of showing what is actually defined. |
That’s fair. In my defence I wanted this because of some builtin mappings from |
Sure. That is why there is an exported |
|
With the release of 0.10.0, 'mini.clue' is now out of beta-testing. Huge thanks to everyone for constructive feedback and participation! |
@MariaSolOs, this is now possible on latest local win_config = function(buf_id)
local max_width = 0
for _, l in ipairs(vim.api.nvim_buf_get_lines(buf_id, 0, -1, false)) do
max_width = math.max(max_width, vim.fn.strchars(l))
end
-- Choose your own maximum width instead of 20
return { width = math.min(max_width, 20), border = 'double' }
end
require('mini.clue').setup({
-- Place for your triggers and clues
window = { config = win_config },
}) |
@echasnovski Nice! Thank you for following up. Out of curiosity, which was the neovim change that provided this functionality? |
You might have been contributing to Neovim too much (just joking, no such limit exists) :). It was meant as 'mini.nvim' |
|
@echasnovski lol yeah, I had just reviewing echasnovski/mini.clue@97b881f. Thank you for the feature <3 |
The way I do this currently is to:
Not sure anything "cleaner" can be done without lower-level APIs from Nvim (unlikely?) |
and others
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):
Thanks!
The text was updated successfully, but these errors were encountered: