search

Timoses / vim-venu

Simple menu for vim
20 stars 2 forks source link

Limitation of single-digit menu points allows only 9 entries #7

Closed Timoses closed 5 years ago

Timoses commented 5 years ago

This limitation should be circumvented. Especially with the ability to import native menus #5 the control of how many items are in the venu are out of direct control of the user.

Options:

  1. If more than 9 items are in the list, items have to be selected with two digits, e.g.
    • 09 for item 9
    • 11 for item 11
  2. Paging: Item 8 and 9 present ability to go to "previous" and "next" page, respecitvely
  3. Use letters 'a', 'b', 'c', ... from items 10, 11, 12, ...
  4. Use 'j' and 'k' (vim line down and line up) to select items. Can also use '10j' to select the item 10 rows below the current one.

Other options?

ozars commented 5 years ago

Is it possible to allow custom keys to be provided by user and enumerate only those options without any shortcuts? This doesn't directly solve single-digit limitation, but it gives a way for user to control it to some extent.

Timoses commented 5 years ago

Could you give an example? What I understand from it, you'd like to give call something like

g:venu_selection_set = ['a','s','d','f',...]

and then the items would be selectable with a (first item), s (second item), ...?

ozars commented 5 years ago

Rather than same set of shortcuts for each menu screen, each menu/submenu/item has its own shortcut. Example:

let s:menu1 = venu#create('My first Venu', 'y')
call venu#addItem(s:menu1, 'Item of first menu', 'echo "Called first item"')
call venu#register(s:menu1)

let s:menu2 = venu#create('My second Venu', 'a')
call venu#addItem(s:menu2, 'Call a function ref', function("s:myfunction"), 'a')

let s:submenu = venu#create('My awesome subVenu', 'b')
call venu#addItem(s:submenu, 'Item 1', ':echo "First item of submenu!"', 'q')
call venu#addItem(s:submenu, 'Item 2', ':echo "Second item of submenu!"')

call venu#register(s:menu2)

This would be result in two menu items at root with shortcuts of 'y' and 'a'. For example a sequence of 'abq' on venu screen would run Item 1 from s:submenu where as 'aa' would call s:myfunction. Menu entries without shortcuts or those with ambiguous shortcuts (due to conflicting shortcuts provided by user or more likely by different plugins) can still be enumerated.

What do you think?

Timoses commented 5 years ago

I think it would get in the way of venu's purpose. Part of the idea is to create a menu so that one does not have to remember specific keystrokes or commands, but to be able to select the appropriate action from a textual representation of available options.

I agree however, that certain actions may be used very frequently, so that a user might know that, for example, to compile the current file the "key stroke" is 1 5. In this scenario it would make sense to allow the user to define custom key strokes. Then again, is a menu really necessary in that case? The user could simply use the vim Leader key and map that action to some key. Imagine a menu like this:

q. Quit
x. Quit and save
b. Build
c. Compile

I don't see any benefit here. I actually have a shortcut <Leader>x myself to quit and save. That is quicker than using venu.

Personally, I don't mind remembering a 1 5 sequence to do a specific action. I believe, when using custom key shortcuts for menu entries it could very quickly get messy. Of course that is up to the user's ability to keep it sane.

It could be a nice feature perhaps to allow the user to define a custom sequence (from when I misunderstood you previously: https://github.com/Timoses/vim-venu/issues/7#issuecomment-459953837).

E.g. a user could define a custom set: S1 = ['a', 's', 'd', 'f'].

Following scheme 1. (https://github.com/Timoses/vim-venu/issues/7#issue-403553149) A menu with more than 4 entries would look like this:

aa. first
as. second
ad. third
af. fourth
sa. fifth
ss. sixth

The same pattern applied to the "default" selection set ('1', '2', ... '9') would then be (in this case with more than 9 entries):

11. first
12. second
...
21. 10th
22. 11th

So far, this would be my favorite.

ozars commented 5 years ago

Well, clearly we think differently on this, which is okay and not an unexpected thing in vim context as well. Mapping a frequently used mapping such as Quit doesn't make sense to me either (though it's possible it makes sense to someone else), but placing shortcuts for plugins that I infrequently use definitely makes sense to me. I wouldn't prefer reserving and memorizing some mappings for those. I wouldn't prefer digging into my vimrc to edit/remember some infrequently used mappings either. I have such mappings with youcompleteme and po.vim that I would love to offload to a menu entry with my own shortcuts. There are also a bunch of other commands from different plugins I didn't map simply because I'm sure I would keep forgetting their mappings.

It's completely understandable that you don't want to code or maintain something that you don't really use or need. So, how about doing this with lightline.vim's approach, that is, in a modular way based on user callbacks so that custom implementations can be accommodated? In this way, you can set defaults for the repo as you think most convenient, taking a custom set as you mentioned. I can override default callbacks in my vimrc with those I think most convenient for me. They can even live in somewhere in this repo as alternative callbacks if you think they may be useful to others. Someone else can override default callbacks with their own to use whatever they think most convenient for themselves, such as using fzf.vim for selecting menu entries. This way users can try and customize different alternatives to see whichever best suits for their purposes as well.

More concretely, I propose venu#print to take three optional callback functions or perhaps a configuration dictionary which may include some or all of these options:

So, venu#print would call printCallback and readCallback to do its thing.

Additionally, menu entry structure can have a dictionary attribute that users can freely modify, something like attr. This way for example I can set/get menu.attr.shortcut for a menu. This option can be directly accessed through menu.attr or exposed with venu#setAttr(menu, key, value) and venu#getAttr(menu, key[, default]) functions, though exposing them through some functions is kinda redundant.

What do you think? This implementation would definitely keep me happy. Would it make you happy as well? :-)

Timoses commented 5 years ago

I really like the approach to make it flexible. I'll try to get my head into it a bit more soon and reply a bit more detailed then : ).

Timoses commented 5 years ago

I think we're getting a bit off-topic. However, I've created a small PR to try and implement your input. Take a look: https://github.com/Timoses/vim-venu/pull/11 Especially: https://github.com/Timoses/vim-venu/pull/11/commits/746f34a692f798791c75f0d30e7cc48c6685d33b#diff-b4fb7a932b16ae8081b16405f2c0f906R211

I think it makes sense to allow extensibility and customization. I feel allowing the user to customize the shortcuts used to navigate the menu is important. Above mentioned PR is a first step I suppose.

That said, this issue is about the default behaviour of Venu. Any requirements relating to extensions/pluggability should be discussed in separate issues. (Feel free to create one).