Problem:
Since right-click can now show a popup menu, we can provide messaging to
guide users who expect 'mouse' to be disabled by default. So 'mouse' can
now be enabled by default.
Solution:
Do it.
Closes#15521
- Return the menu properties, not only its children.
- If the {path} param is given, return only the first node. The "next"
nodes in the linked-list are irrelevant.
:menu should print sub-menu contents. E.g. this should print the
"File.Save" submenu:
nvim -u NORC
:source $VIMRUNTIME/menu.vim
:menu File.Save
Regressed in dc685387a3
Blocks #8173
menu_get() also was missing some results for some cases.
Hope this will make people using feed_command less likely: this hides bugs.
Already found at least two:
1. msgpackparse() will show internal error: hash_add() in case of duplicate
keys, though it will still work correctly. Currently silenced.
2. ttimeoutlen was spelled incorrectly, resulting in option not being set when
expected. Test was still functioning somehow though. Currently fixed.
menu_spec.lua yanks to the clipboard, but never pastes from it. This
can leave a child xsel process waiting around for something to paste the
content, causing the test process to hang.
Since the test isn't explicitly trying to exercise the clipboard, simply
use the default register.
It is otherwise impossible to determine which test failed sanitizer/valgrind
check. test/functional/helpers.lua module return was changed so that tests which
do not provide after_each function to get new check will automatically fail.
A menu item can have separate bindings for each Vim mode.
:emenu checks to see which binding it should execute. But, it assumes
it can only be called from Normal mode, so its mode detection is based
on some guesswork. For instance, it detects if you've just used C-O
and, if so, uses the Insert mode binding.
Now that :emenu can be called from any mode (via vim_command), this
commit has it check the actual mode we're in, and simply use the
binding for that mode if we aren't in Normal mode.
