abcdef123xyz123

It is easy to change the scroll speed in tmux, although the default is 5 lines at a time which seems like it should be fast enough...

Mouse and scrollback and clipboard are some of the more complicated areas of terminal emulators and ones where applications like tmux have the least power so they will always have the potential to be a bit fiddly.

If it hurts your wrist pressing it with one hand, perhaps you should use two...

I customize/copy my configs on the boxes I use regularly and just learn enough of the defaults to get by on boxes I am using only occasionally (eg I know enough vi to get by but if I am using a box for a bit I install emacs and if I am using it a lot I copy my .emacs as well). It helps that I keep my configs small and in a single file for each program so I can copy them quickly if I need to.

For tmux, it will look at VISUAL/EDITOR so for vi keys you could just try to remember to run it as "VISUAL=vi tmux" or to run "tmux set -g mode-keys vi" if you forget.

If someone has access to your user account and you're running tmux, they can just attach that tmux, they don't need to mess around with send-keys.

If send-keys didn't exist, a script could attach tmux in its own pty instead.

Detach/attach is a fundamental part of how tmux works, everyone must understand that it is fully available to anyone with access to your user.

GNU screen also has a similar feature to send-keys (they call it "stuff").

It has always been good practice to detach long-running root programs by starting a new tmux as root rather than running them in a non-root tmux, and to use sudo rather than su to run root commands inside tmux the same way as you would outside.

Yes. I'm not sure I would say afraid but certainly cautious. I would avoid recommending GPL software to anyone I work with or for. The license is too complicated, the rules too strict (and seem to change with every license version), the FSF is too hardline. Simple, permissive licenses are easier and safer.

We have been moving away from IB for our platform (algorithmic trading) since Ethernet now has almost comparable latency and is a lot easier to understand and manage.

My point is that for new features, like key up would be, it is not necessary to be bound by terminfo. If some or all of xterm, VTE, konsole, rxvt-unicode and iterm2 supported it, that is a large proportion of the modern *nix terminals that people still use. And they are all VT100 compatible terminals. If you look at a lot of recent features, such as SGR mouse mode, RGB colour, underline styles, focus events - they are all based on VT100 style escape sequences, and they all started with a few terminals and existed for a good while (with applications using them) before terminfo added any sort of support.

There are no terminals still in widespread use that are not VT100-compatible, by which I mean they use the escape sequence protocol originally used in the DEC terminals, although of course it has been much extended.

> So, yes, it's absolutely impossible to get key up events in tty context

There is absolutely no reason that many terminal emulators couldn't translate key up events into an escape sequence and forward them on to the application. So long as they receive them somehow themselves (eg an X terminal emulator will be told of them by X).

It doesn't need to be out-of-band and it doesn't need to involve the tty driver.

The right way to do it is to make them only sent when the application requests them.

For example, this is how focus events work. If the application requests them with SM ?1004, \033[I is sent when the window gains focus and \033[O when the window loses it. There are not a lot of applications that use them, but some can (eg vim).

Hi

> There's already no particularly consistent standard for most terminal events

This is not really true anymore, almost all terminals still in use (and certainly all that are widely used) are VT100 compatible. In fact most are broadly compatible with xterm. So that is pretty much the standard now, and most new features being added to terminals don't take any account of other types of terminal at all.

> It seems like it would just be a matter of adding another termcap entry for your specific terminal emulator, and hoping other people care enough to start implementing it in theirs.

termcap was superseded by terminfo around the late 80s. A few applications still use it, but most are now terminfo. The termcap database on most systems is now derived from terminfo.

terminfo is centrally managed as part of ncurses and stuff doesn't really get added to it just to see. The way it usually works is that one or more terminals add a feature and if it makes sense and is popular, applications will use it, and if applications use it then often it will end up in terminfo entries. Definitely if ncurses uses it, possibly if not (this can be controversial).

You are right that there is no real reason a terminal couldn't send an escape sequence for key up, although it would certainly have to be something requested by the application - there are plenty of other escape sequences like that (eg the mouse, focus events).

The tty doesn't really come into it, nor does the kernel or drivers, except for its own console terminal, but not many people use that very much.

SGR mouse mode is an example of a terminal feature added relatively recently which has been taken up widely.

In practice - like you say - for non-DSP, non-mainframe this doesn't matter. For applications development, differences between the standard libraries and even compilers are much more difficult than the few differences in architectures. Endiness, strict alignment, char signedness and overflow are about the only things that matter anymore even if you want to support nearly every modern architecture used for popular OSs, and they are relatively easy to handle. Writing C that compiles and works on eg both Unix and Windows is far more about libraries and compiler quirks.

Not so much for programmers, but I think certainly for people used to the terminal. If you know how to use the shell or a sophisticated editor like vi or emacs, tmux should not be a particular challenge. The target audience is not Unix beginners.