select.lua: add keep_open option to select-binding and select-track#18030
select.lua: add keep_open option to select-binding and select-track#18030pakhromov wants to merge 1 commit into
Conversation
|
DOCS/man/select.rst needs to be updated. |
|
I think it can be positioned first in the script-opts so it's not grouped with the context menu ones. |
Makes sense, do you think it's fine to not apply this option to other menus of select.lua (like select-playlist, select-chapter, etc)? |
|
Yeah I don't see a use case for keeping the other menus open. |
| Default: no | ||
|
|
||
| Whether to keep the menu open after a selection in ``select-binding`` | ||
| and ``select-track``. |
There was a problem hiding this comment.
Why only those two select-* are special?
There was a problem hiding this comment.
The other ones do not benefit from it, like if the user wants to switch to a different chapter or a different playlist entry - that is a one and done operation and leaving the menu open after it is not beneficial, but this is just my thought process, I can see the argument for making it behave the same way across all select menus.
There was a problem hiding this comment.
I'm just thinking that having such oddly specific option is not flexible.
Maybe there should be separate binidng for "keep open" open. In which way user can adjust different menus individually in their input.conf.
Don't get me wrong, I don't see this as a bad change, but generally we aim to make mpv configurable as possible, to avoid having issues like this one.
I can give counterargument to chapters for example, when user wants to search for a chapter, they might keep open the menu and jump through few of them before closing.
There was a problem hiding this comment.
I can make keep_open as a global option for all select menus then. That way it is easier to explain what it does, if it is true - then every select menu will not be closed after a selection is made. I think per-select-menu overwrites is overthinking it, just giving an option to keep all of them opened should be enough?
|
script-binding already supports custom argument. 0874f81 # do not keep open
g-t script-binding select/select-track
# keep open
g-t script-binding select/select-track keep-openmp.add_key_binding(nil, "select-track", function (t)
if t.event == "up" or t.event == "repeat" then return end
local keep_open = t.arg == "keep-open"
-- ......
end, { complex = true }) |
Adds an optional keep-open argument to all select.lua script bindings that prevents the menu from closing after a selection. Menus that display selection state (tracks, audio device) or a current position indicator (playlist, chapter, edition, subtitle line) are wrapped in a recursive function so the list is rebuilt after each selection and the indicators remain accurate. default_item is passed to preserve the cursor position on the last selected item. The history confirmation dialog reopens the history menu when No is selected, and closes when Yes is selected as there is nothing to show anymore.
Agree, this is a better way, I squashed the previous commits into one to keep it clean |
Adds a keep_open script-opt (default: false to keep the original behavior) that prevents the menu from closing after the selection is made in select-binding and select-track.
Not closing the select-binding menu after a selection allows users to perform the action again (e.g. if the video is too bright - it is highly unlikely that a single brightness decrease step will be enough and if the user did not memorize the keybind (or prefers using a menu instead) - they will have to open the menu again to search for it).
For select-track, chances are that the user will want to switch the subtitle track as well when they switch an audio track (switching to a different language and activating a different subtitle language or turning them off). The handler is wrapped in a recursive function to rebuild the list on each selection and keep the active/inactive indicators up to date. The default_item is passed to preserve the cursor position on the last selected item.
Other modes of the select menu do not benefit from adding this feature as they are not repeatable or include multi-select options (as far as I can see).
This contribution was developed with AI assistance (Claude Sonnet 4.6). I have full understanding of the changes and take complete responsibility for the code.