History log of /openbsd-src/usr.bin/tmux/input-keys.c (Results 26 – 50 of 107)
Revision Date Author Comments
# 090e14ef 08-Apr-2021 nicm <nicm@openbsd.org>

Log the key written to the terminal as well as tmux's idea of what it
is.


# dce21a56 17-Nov-2020 nicm <nicm@openbsd.org>

Log missing keys when extended keys is on rather than fatal().


# cf415ead 18-Sep-2020 nicm <nicm@openbsd.org>

Some other warnings, GitHub issue 2382.


# cd4ae116 01-Jun-2020 nicm <nicm@openbsd.org>

Try without cursor/keypad flags if a key doesn't exist, and limit ctrl
key translation to ASCII keys. Fixes send-keys, GitHub issue 2247.


# 6852c63b 25-May-2020 nicm <nicm@openbsd.org>

Use the internal representation for UTF-8 keys instead of wchar_t and
drop some code only needed for that.


# 5aab9092 19-May-2020 nicm <nicm@openbsd.org>

Some other ctrl keys need to be translated with extended keys on.


# dcf80b09 16-May-2020 nicm <nicm@openbsd.org>

Add a terminal feature for enable/disable extended keys (supported by
xterm and mintty) and add an option to make tmux send it. Only forward
extended keys if the application has requested them, even

Add a terminal feature for enable/disable extended keys (supported by
xterm and mintty) and add an option to make tmux send it. Only forward
extended keys if the application has requested them, even though we use
the CSI u sequence and xterm uses CSI 27 ~ - this is what mintty does as
well.

show more ...


# a16e511e 16-May-2020 nicm <nicm@openbsd.org>

Send CSI u sequences for any keys that do not have a defined sequence
already - this should only be similar sequences sent by the terminal
outside tmux if enabled.


# 5416581e 16-May-2020 nicm <nicm@openbsd.org>

Separate key flags and modifiers, log key flags, make the "xterm" flag
more explicit and fix M- keys with a leading escape.


# 6a385b80 16-May-2020 nicm <nicm@openbsd.org>

Rename KEYC_ESCAPE to KEYC_META.


# 9265d1ac 16-May-2020 nicm <nicm@openbsd.org>

xterm-keys has been on by default for five years and all other modern
terminals use these key sequences by default. Merge the code into the
main tty and input tree processing (converting the latter t

xterm-keys has been on by default for five years and all other modern
terminals use these key sequences by default. Merge the code into the
main tty and input tree processing (converting the latter to use a tree
rather than a table at the same time) and make the option a no-op.

show more ...


# 57d747ee 07-Apr-2020 nicm <nicm@openbsd.org>

Do not send mouse events if the program has not requested them.


# 29724ccb 01-Apr-2020 nicm <nicm@openbsd.org>

Support mouse in popups.


# 29ebed37 19-Mar-2020 nicm <nicm@openbsd.org>

Change input path so it doesn't require a pane.


# 13e036e4 16-Mar-2020 nicm <nicm@openbsd.org>

Send mouse down event immediately rather than waiting for double click
to finish which would now mean it was out of order. Reported by Mark
Kelly.


# de7a415f 13-Jan-2020 nicm <nicm@openbsd.org>

Treat plausible but invalid keys (like C-BSpace) as literal like any
other unrecognised string passed to send-keys. Reported by Anthony
Sottile in GitHub issue 2049.


# 4c8b1ab8 18-Nov-2019 nicm <nicm@openbsd.org>

Keep modifiers on backspace when translating it.


# fdd8dc91 14-Nov-2019 nicm <nicm@openbsd.org>

Add an option to set the key sent by backspace for those whose system
uses ^H rather than ^?. GitHub issue 1969.


# a02c6cc0 09-Jul-2019 nicm <nicm@openbsd.org>

Add a -H flag to send-keys to send literal keys given as hex numbers
(needed for control clients to send mouse sequences). Also add some
format flags for UTF-8 and SGR mouse mode. Requested by Bradle

Add a -H flag to send-keys to send literal keys given as hex numbers
(needed for control clients to send mouse sequences). Also add some
format flags for UTF-8 and SGR mouse mode. Requested by Bradley Smith in
GitHub issues 1832 and 1833.

show more ...


# 7b470e93 18-Oct-2018 nicm <nicm@openbsd.org>

Support for windows larger than visible on the attached client. This has
been a limitation for a long time.

There are two new options, window-size and default-size, and a new
command, resize-window.

Support for windows larger than visible on the attached client. This has
been a limitation for a long time.

There are two new options, window-size and default-size, and a new
command, resize-window. The force-width and force-height options and the
session_width and session_height formats have been removed.

The new window-size option tells tmux how to work out the size of
windows: largest means it picks the size of the largest session,
smallest the smallest session (similar to the old behaviour) and manual
means that it does not automatically resize windows. The default is
currently largest but this may change. aggressive-resize modifies the
choice of session for largest and smallest as it did before.

If a window is in a session attached to a client that is too small, only
part of the window is shown. tmux attempts to keep the cursor visible,
so the part of the window displayed is changed as the cursor moves (with
a small delay, to try and avoid excess redrawing when applications
redraw status lines or similar that are not currently visible). The
offset of the visible portion of the window is shown in status-right.

Drawing windows which are larger than the client is not as efficient as
those which fit, particularly when the cursor moves, so it is
recommended to avoid using this on slow machines or networks (set
window-size to smallest or manual).

The resize-window command can be used to resize a window manually. If it
is used, the window-size option is automatically set to manual for the
window (undo this with "setw -u window-size"). resize-window works in a
similar way to resize-pane (-U -D -L -R -x -y flags) but also has -a and
-A flags. -a sets the window to the size of the smallest client (what it
would be if window-size was smallest) and -A the largest.

For the same behaviour as force-width or force-height, use resize-window
-x or -y, and "setw -u window-size" to revert to automatic sizing..

If the global window-size option is set to manual, the default-size
option is used for new windows. If -x or -y is used with new-session,
that sets the default-size option for the new session.

The maximum size of a window is 10000x10000. But expect applications to
complain and much higher memory use if making a window excessively
big. The minimum size is the size required for the current layout
including borders.

The refresh-client command can be used to pan around a window, -U -D -L
-R moves up, down, left or right and -c returns to automatic cursor
tracking. The position is reset when the current window is changed.

show more ...


# 0f99bcbc 28-Jun-2017 nicm <nicm@openbsd.org>

Apply the xterm key flag when needed for send-keys, fixes problem
reported by Franky Spamschleuder.


# b99601f2 12-Jun-2017 nicm <nicm@openbsd.org>

Add explicit keys for the bracketed paste sequences, both to avoid mix
ups with other keys and to make logs clearer.


# 28dafa00 07-May-2017 nicm <nicm@openbsd.org>

Up to now, tmux sees \033\033[OA as M-Up and since we turned on
xterm-keys by default, generates \033[1;3A instead of
\033\033[OA. Unfortunately this confuses vi, which doesn't understand
xterm keys

Up to now, tmux sees \033\033[OA as M-Up and since we turned on
xterm-keys by default, generates \033[1;3A instead of
\033\033[OA. Unfortunately this confuses vi, which doesn't understand
xterm keys and now sees Escape+Up pressed within escape-time as Escape
followed by A.

The issue doesn't happen in xterm itself because it gets the keys from X
and can distinguish between a genuine M-Up and Escape+Up.

Because xterm can, tmux can too: xterm will give us \033[1;3A (that is,
kUP3) for a real M-Up and \033\033OA for Escape+Up - in fact, we can be
sure any \033 preceding an xterm key is a real Escape key press because
Meta would be part of the xterm key instead of a separate \033.

So change tmux to recognise both sequences as M-Up for its own purposes,
but generate the xterm version of M-Up only if it originally received
the xterm version from the terminal.

This means we will return to sending \033\033OA instead of the xterm key
for terminals that do not support xterm keys themselves, but there is no
practical way around this because they do not allow us to distinguish
between Escape+Up and M-Up. xterm style escape sequences are now the de
facto standard for these keys in any case.

Problem reported by jsing@ and subsequently by Cecile Tonglet in GitHub
issue 907.

show more ...


# 9f26c5b1 01-Feb-2017 nicm <nicm@openbsd.org>

Implement "all event" (1003) mouse mode but in a way that works. The
main issue is that if we have two panes, A with 1002 and B with 1003, we
need to set 1003 outside tmux in order to get all the mou

Implement "all event" (1003) mouse mode but in a way that works. The
main issue is that if we have two panes, A with 1002 and B with 1003, we
need to set 1003 outside tmux in order to get all the mouse events, but
then we need to suppress the ones that pane A doesn't want. This is easy
in SGR mouse mode, because buttons == 3 is only used for movement events
(for other events the trailing m/M marks a release instead), but in
normal mouse mode we can't tell so easily. So for that, look at the
previous event instead - if it is drag+release as well, then the current
event is a movement event.

show more ...


# 77c6aa83 25-Jan-2017 nicm <nicm@openbsd.org>

Revert previous for now, it will break TERM=screen.


12345