Add new 'next-window' and 'previous-window' commands, which have immediate effect
#1883 (closed) and #2967 (closed) both described the same problem I have: when I type the (single) key I have bound to cycle-windows
I have to wait 1 second before I can start using the new window (or indeed do anything at all).
The former issue resulted in a way of manually instructing cycle-windows
to cease waiting and exit immediately, but that's not the nicest solution for the end user -- in the common case of switching between only two windows, it's literally doubling the number of keystrokes they need to use (if they want to avoid the timeout), and in any case the 'exit' key is liable to be physically distant from the 'cycle windows' key. When the goal is to make switching faster and easier, it's not very satisfying. Users should be able to press a key and immediately carry on in the new window.
IIUC from the prior issues, the reason this wasn't possible to do with cycle-windows
is that running that command enters a kind of "selection mode" within which the user then has to choose a window (possibly using multiple keystrokes) and then "confirm" that selection; and in the absence of a modifier key, the timeout (or extra keystroke) is how that confirmation step is achieved.
I'd like to propose a new pair of commands: next-window
and previous-window
which behave differently, switching immediately to the next or previous window in the sequence.
Some testing of cycle-windows
shows me that right away there's a (potential) problem with this: the window sequence used by cycle-windows
is modified when that command completes (moving the newly-selected window to the front of the list), and if that same data and behaviour was used for the next-window
command, you would actually bounce back and forth between only two windows (as was described in the earlier issues). (Cycling in reverse is a bit different... the sequence is still modified, but each successive usage is no longer moving you towards the window which was displaced by the previous call, so you actually do get to cycle through them all.)
My request might therefore require a secondary sequence to be stored; one which is not modified by window selections. I feel that this would be worth doing, because I find the current user-experience for this UI to be so clunky in practice. Alternatively, these new commands could use the existing data if either (a) window selections using next-window
and previous-window
did not cause the sequence to be re-ordered, or (b) the new commands cycled the entire sequence rather than just moving the new window to the front.
Not being able to quickly switch windows with a single keypress feels a bit crazy to me, so I hope that this sounds like a worthwhile feature to add.