abcdef123xyz123

You can try this:

https://gist.githubusercontent.com/nicm/9acc00b67035b5f2b8a8...

Which does the basics of this:

- Bump the sequence timeout to 5 seconds instead of 100 ms for more time for SIXEL images but still not let the terminal hang forever. This could be made more sophisticated perhaps.

- Check the code in DA for SIXEL support and also check a terminfo(5) extension flag Sxl.

- Recognise SIXEL sequences and pass them through (like the 'tmux' passthrough escape sequence) and copy them to the attached outside terminals if they support SIXEL (DA or Sxl set).

I didn't try to disable the terminal-can't-keep-up code during DCS, that is more complicated because some panes may be inside DCS and some may not. I only have a small test SIXEL image so I would need a larger one that demonstrates the problem to look at that.

I probably won't move this any further forward unless someone tests this, but it may be a good start for further work on SIXEL.

https://github.com/tmux/tmux/issues/1613 is a better reflection of my views on SIXEL, although I am coming round to the idea rather. It is not easy to do properly however, I am interested to see how your code works.

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.

It isn't really implicit, it is just a shorthand, new is short for new-session and attach for attach-session. The alias for list-sessions is "ls" not "list".

I don't know why you would say -s shouldn't be required. Are you suggesting that "tmux new -sname command" should be something like "tmux new -ccommand name" instead?

The intent of -t is that it works much the same for all commands.

Of course you need to read the manual for anything more than the very basics, but tmux is hardly unique in that. Vim is hardly intuitive in any way.

OpenBSD has never disobeyed an embargo. Argued for them to be reduced, criticized them, but not disobeyed them.

You are quite lucky, C-a could easily have been the default and then you would have to either use it or have a config ;-).

The disadvantage of C-b is that you need two hands to press it on a QWERTY keyboard, so I kind of wish I had picked C-x or something instead. But there is no consensus about what the default should be (lots of people use C-a, C-b, `, C-e, etc) so it is not worth changing now.

It works pretty well if you bind C-a to send C-a. It is easy to get used to pressing C-a twice for beginning of line, and if you do it outside tmux it is harmless.

Also prefix-[0-9] is used for navigating windows, not panes.

You mean "tmux detach" not just "detach". Also it is prefix+: not just :. Also there is no attach keyboard shortcut,not prefix-a.

Not sure why you keep putting tmux in all caps but whatever floats your boat there.