Why does 'suggestbox' for comma (,) disappear after around a second?

Question

Hey.

The suggestbox for the comma (,) prefix disappears after about a
second or faster which is inconsistent with how it behaves in
case of other keywords such as d,z or q. The documentation
doesn't describe and option for such customization.

I am using the following default option:

set suggestoptions=normal,visual,view,otherpane,keys,marks,registers

vifm 0.12

Is this intentional? How to normalize it?

Answer 1

Hi.

Yes, this is how user mappings work in presence of a conflicting builtin mapping in Vim.

You can use <wait> map argument for your comma mappings to address this:

<wait>
In case of builtin mapping causing conflict for a user-defined mapping
(e.g., t builtin to a partially typed ta user-defined mapping), ignore
the builtin mapping and wait for input indefinitely as opposed to
default behaviour of triggering the builtin mapping after a delay defined
by 'timeoutlen'.

Comments

Thank you for helping out.

---

So if I got it right there are 3 possible ways to achieve a mapping with e.g. , or space:

1. <wait> to just ignore the builtin one
2. set timeoutlen=1000 to wait 1 second and if nothing happens, handle the built-in
   functionality
3. nnoremap <space> <nop> to unmap the built-in one

Especially for space I am interested in unmap the key, since I am using TAB instead.

---

Unfortunately there is something I maybe missing:

• my keymaps then also have to be triggered inside the timeoutlen=100 (which I prefer), because the built-in space key is not deactivated, it's just remapped
• So I add <wait> in front the map, but it's the same and has still a timeoutlen=100

in vifmrc:

" NOTE: <space> performs like the leader key, therefor we have to deactive the built-in functionality
nnoremap <space> <nop>
nnoremap <wait> <space>c :write | edit $MYVIFMRC | restart full<cr>

Playing around with timeoutlen=200 seems to be a compromise for me. But I would rather expect vifm to wait. Is that some sort of a bug?

---

Builtin mappings are always there, they can't be unmapped, only overridden.

The intend of <wait> is to resolve input ambiguity between user and builtin mappings and doing nnoremap <space> <nop> turns it into an ambiguity between two user mappings in which <wait> doesn't play a role.

Because Lua can register user mappings whose behaviour is closer to builtin mappings, a hacky workaround like this makes <wait> work (followedby is what makes it apply):

vifm.keys.add {
    shortcut = ' ',
    modes = { 'normal' },
    handler = function() end,
    followedby = 'keyarg'
}

I'll think about either extending the meaning of <wait> or introducing another flag that applies to user mappings in the next release.

---

I guessed that, but I had to override space, since it is conflicting with the built in, even if I add <wait>.
Pressing ESC to cancel the space binding is resulting in changing the pane, which is not intended. I remember an issue on GitHub (https://github.com/vifm/vifm/issues/475), where you mentioned that problem.

That's why I went for override.

---

There is tiny workaround for <space> single pressing cancellation.
This is from my vifmrc (vifmrc):

" <space>-group
" The issue is single <space> still works as default, because if remap
" single <space> to something, help messages will not appear anymore, and
" unmapping for builtin mappings also does not work (see above).
" Workaround is <space><esc> mapping, if you have pressed <space> and want to
" cancel it, just press <esc> and vifm will just do nothing (<nop>).
nnoremap <wait> <space><esc> <nop>
nnoremap <wait> <space><space> <c-w>w
qnoremap <wait> <space><space> <c-w>w