abcdef123xyz

This reads like an advert for Eurostar. And it is absolutely not true that traveling London-Paris or anywhere else in Europe is now the norm, most people still fly.

You can try the sixel branch in tmux - the top of the branch does some conversion and scaling (currently fits image to the pane and scales to the terminal xpixel/ypixel) so it might interfere too much but if you just took b34111b3 and d2e3f3c1 you would have plain passthrough (I might make a separate branch for that actually).

There is still a lot of work to do, I haven't decided if the best option would be to store all images in a big list and draw them separately when needed, or whether to mark the cells they cover and draw the SIXEL when the cell is drawn. SIXEL seems to have some strange behaviours and xterm seems to have a few bugs so I'm not sure how close to emulate everything - it might be better just to do it a sensible way. I don't think many applications will rely on being able to draw on top of SIXELs or have partial characters appear underneath.

I couldn't get img2sixel to generate the right colours, but convert from ImageMagick worked.

An achievable option in the short term would be to do the following:

1) Fix the DCS issue as I suggested.

2) Check if the terminal supports SIXEL (there is a code in DA or DA2, or perhaps we need a flag).

3) If the terminal supports SIXEL, pass it through, if it doesn't then ignore it.

This would allow SIXEL to display on output although it would be corrupted as soon as tmux redraws. It would be a start however and could be added to tmux immediately.

I took a look at this but at the moment you are just commenting out the bits that stop tmux sending SIXEL to the outside terminal, so there is still a lot of work to do for proper SIXEL support:

- You don't check if the terminal outside even supports SIXEL. A major tmux design feature is that it avoids sending output to a terminal if it doesn't know it will understand it.

- What if there are two clients attached, one in a terminal with SIXEL, one without? Does it need to draw an ASCII placeholder?

- The SIXEL image needs to be saved so it can be redrawn if needed (current window is changed, detach/attach, scrolling into history etc).

- If the SIXEL image is scrolled partly off the terminal or the window pans so it is partly off the terminal, the image needs to be cropped to the right size and drawn at the right place.

- The problems with the timer and large DCS, just turning this off is bringing back the problems with fast output it is intended to solve. A better solution would be to only disable these while a DCS sequence is in progress.

If you get it working with these addressed I would be open to merging it into tmux itself.

Most likely you are using the wrong TERM so tmux doesn't have the correct information about what colours your terminal supports.

How is the colour support better?

Absolute nonsense, are you trying to press C-b with one hand?

There is no agreement on what is sensible and what is not, the defaults are no more or less sensible than any other suggestion.

There is no consensus on the best prefix so there is no point in changing it after 10 years. Lots of people dislike C-a.

Nice article, although a minor peeve is that tmux should no more have a capital letter than ls or cp.

But it goes little further than the dozens of similar articles already available. I'd like to see a few tmux 102 or 201 or whatever articles that cover some of the more advanced features such as hooks, targets and IDs, monitoring and alerts, formats and #(), command sequences, if-shell and run-shell, new/neww/splitw -P and shell scripting with tmux, buffers, capture-pane and pipe-pane, find-window and filters etc in the choose modes, pane titles, terminal-overrides, linking windows and session groups, detach -P, remain-on-exit and exit-unattached and detach-on-destroy, the mouse and advanced key bindings, the new status-format stuff in 2.9, and even menus coming in 3.0. And probably more :-).

Of course I know I could write one myself I suppose :-).

I think it is clear they mean what the programmer would expect /even if they knew the code was wrong/:

"And that’s what programmers expect: In the normal case a read from an array (even an out-of-bounds read) performs a load from the address computed for the array element; the programmer expects that load to produce the value at that address, or, in the out-of-bounds case, it may also lead to a segmentation violation (Unix), general protection fault (Windows), or equivalent; but most programmers do not expect it to “optimize” a bounded loop into an endless loop."

It sounds rather like he is trying to blame OpenBSD for his own mistake. As multiple people from OpenBSD have said, he agreed they could apply the fix, so they did. He didn't have to say they could. The fact that CERT persuaded him to extend the embargo later is not their fault.

Who says they were pressured?