[1] https://zellij.dev/

It's a bit silly, and certainly not necessary, but I like it a lot.

Since I work with big biological data, most of my work takes place on our university cluster, which means my laptop is just a dumb terminal and all of the action takes place on the server. IME, tmux is especially powerful with coupled with mosh, which gives a persistent SSH connection. That means I can be in the middle of a project, close my laptop lid, go home, then later that evening, open my lid and everything is reconnected and just right there. Same if I reboot my laptop - one command to reconnect my terminal with mosh, and I'm back in the middle of my complicated multi-window project.

    bind -n S-PPage copy-mode -u
    bind -T copy-mode S-PPage send -X page-up
    bind -T copy-mode S-NPage send -X page-down

I also have a small hack in my .zshrc to start scrolling up with `M-v` (like in Emacs) while at a shell prompt:

    tmuxup(){tmux copy-mode -u}
    zle -N tmuxup
    bindkey '^[v' tmuxup

[1] https://zellij.dev/

This is something tmux inherited from screen, but it from a quick test it looks like they didn't copy the whole thing? You use [ to enter this mode (it's actually for copying text, not just scrolling) and in screen use ] to exit without copying anything. Looks like tmux doesn't have ], at least by default?

Many fancy terminal programs offer some subset of these multiplexing features (like tabs) and such, but in my experience none of them are as configurable or as feature rich as Tmux.

[0] https://mosh.org/

Have we gone from shitty connectivity to stable and then back to shitty?

For strictly "keep one thing running remotely" it's not much different (screen is entirely fine), but for "do work remotely" it's like comparing `cat` and `less`. One does what the other does and a heck of a lot more that is very useful when you need it. Sure, you can use grep, but having an integrated (reversible) incremental search is hard to truly replicate from the outside. Tmux is kinda on a similar level vs screen.

Personally fwiw: I almost exclusively use tmux with iterm's integration, so I don't have to learn basically any of it. I just get resumable terminal tabs and windows when I ssh anywhere, and they're still there months later when I go back. With that kind of setup it's just plain magic, a complete no-brainer, feels like what computing just obviously should be (even though it isn't). I've learned enough of the details around screen/tmux/etc to know that I'm glad to shove almost all of it over there and ignore it.

The function below will also automatically detach other clients, but for me it's what I want since other clients are always just me on another machine, often with a different screen size.

    tm () {
        if [ -z $1 ]
        then
            tmux list-sessions
            return
        fi
        tmux detach -s $1 2> /dev/null
        if [ -n "${TMUX+1}" ]
        then
            tmux switch-client -t $1 2> /dev/null || tmux new-session -s $1
        else
            tmux attach-session -t $1 2> /dev/null || tmux new-session -s $1
        fi
    }

  if [ -z "$1" ]; then
    name="$(basename $PWD)"
    name="${name//\./-}"
  else
    name=$1
  fi

  tmux has -t "=$name" && tmux attach -t "$name" && exit

  tmux new-session -d -s "$name" -n shell

Normally, when you lose your ssh connection to another machine, it'll kill your scripts, drop all the output into /dev/null, and you can't get any of it back. Because that's how a remote terminal normally works.

So even brief connection issues are a major headache, much less known stuff like "close your laptop and resume after lunch".

Tmux gets you what you would expect instead from a "remote tab" thing. Stable, reconnectable, still exists when you're not connected, etc. There are other options of course (there always are), but tmux does it all and it's an industry standard.

Pretty nuts that so many desktops and independent modern terminal emulators lag so far behind GNU Screen, which was first released in 1987.

There are other features a desktop terminal emulator can not give you. And being able to maintain all the shortcuts and muscle memory across devices, servers, X11/Wayland, different DEs, and inside nested VNC or SSH sessions, more than compensates for "impedance mismatch" (curious what you're actually referring to here... Just putting a line in my shellrc to start a new tmux session unless the TMUX env var is already set makes it mostly seamless and you could do the same in terminal emulator conf if you dislike putting such things in your shell or profile).

Unix philosophy: I want my graphical terminal emulator to render my sessions on my display. The stuff happening inside should mostly not be its concern.

> I shouldn't have to

Good thing you don't have to, then. For casual users, emulators like Kitty, xfce-terminal and Konsole exist and are quite popular. Yeah, a batteries-included terminal emulator sounds more appropriate for you and probably the majority. For "niche" users like sysadmins and many power users, tmux is the table-stakes. There's no one-size-fits-all and not everything has to be for everyone.

> GNU Screen

Well, there's the topic of the thread...

`tmux` is actually more than I want, because it interposes itself as a terminal emulator in its own right (hence, per the thread parent, requiring its own sixel support on top of the display terminal's) and use `dtach` instead: it's just a pass-through session holder. Something like `tmux` is necessary when you want to connect to a session from significantly different terminals (say, iTerm on a Mac and Konsole on *nix) but I don't do that.

Second, terminals have state. That state must be synchronized between the program you are running on the remote computer and the terminal on your local computer, or the display will be garbled. Even something as trivial as the cursor position is important. If you disconnect, then your program prints something or moves the cursor, and then you reconnect, whatever it did has been lost and whatever it does next will not be correct. At best it will just be a few lines of lost output, but it could be output at the wrong position on the screen, resulting in a garbled display. Or the size of your screen could be different, again garbling it.

Worse, the remote side could send an escape sequence that changes the terminal’s character set. If your local terminal misses that, then the incoming text will be unreadable. Of course, with the spread of Unicode this has become quite rare. You are most likely to see the problem with programs that switch character sets to draw a UI or other artwork; the line–drawing characters would be printed using ordinary letters and numbers.

What you really want to run is not tmux but a program called mosh. mosh is a drop–in replacement for ssh. It runs on both your local computer and on the remote computer, and synchronizes the state of your terminal for you. The remote end maintains a representation of the local state of the terminal, and visa versa. If you lose your connection, mosh only needs to copy the remote state to the local terminal to resume the session correctly. The other cool trick is that mosh uses a UDP connection instead of TCP. This combined with the encryption it uses allows it to seamlessly resume your session even if your IP address changes suddenly. It also keeps your session alive even if the UDP packets from your local machine stop arriving. If you suddenly close the lid of your laptop, suspending it, it will patiently wait for you to open the lid again and seamlessly reconnect.

There’s definitely overlap in features between tmux and mosh but it’s better to think of them as solving different problems. Mosh is for working on laggy or unstable network connections. Whereas tmux is more like a terminal based tiling window manager.

At the end of the day there are as many good reasons to use tmux as there are good reasons not to. Like most things terminal based, it’s just a matter of personal preference

I suppose the terminal emulator could be more helpful though. For example, if you have a terminal emulator with local tabs/panes/splits/whatever, maybe it should orchestrate the process of connecting (or reconnecting) to the remote server. If I create a new tab or split the current window, it could connect automatically to the server for me. If it is connecting via mosh, then the terminal state in each of my tabs/windows/panes will be maintained correctly.

I'm all for adding those features to the terminal emulators, but it will never meet and certainly not exceed tmux in flexibility, power, portability, and compatiblity.

Locally I use iterm2 with a single hotkey window but multiple tabs with one per project and then up to 8 panes per tab. These stay open for many months until the inevitable restart for system updates. I feel like I have pretty good persistent terminals this way.

But would there be any benefit for me using tmux locally? I know that iterm2 has some kind of integration with it but I‘ve not tried that

With tmux I can assign a name to each session, list all sessions, and have keyboard shortcuts to take me to a specific session or create it if it doesn't already exist. +J always opens projectfoo, +K projectbar, etc.

With tabs you need to know which tab contains what and what order everything is in.

And iTerm won't have a way to restore them, right? The `tmux resurrect` plugin can save and restore all your sessions, even after restarts. At the moment I have 45 tmux sessions running and I'm not worried in the slightest about not being able to pick up exactly where I was for every project.

Also, tmux is a nice way to "bury" your "windows." Hiding an iTerm window can only be done by covering something with it or minimizing it, but a tmux session can be detached from/attached to at will, and when you're detached it doesn't add cruft to your window management.

It's not _necessary_ but it's nice knowing I can close my terminals without worrying of having to wait for another 10m build because I like to keep my open windows to a minimum.

I think it's really down to how you use your computer more than a real need.

It does a good job at scaling the session to fit the size of each client's terminal window and has multiple scaling options available.

In my experience it works way better than for instance terminal sharing in VS Code.

Also let's my colleagues monitor my builds on our shared server pretty easily and it's better than screen sharing

Is this as big as bring a stacking window manager to tmux (compared to the current which is tiling)? Or is just better graphics in the terminal? or am I way off here?

If it's just the better graphics, then I'm not sure I understand why tmux needs to support it. I would think the terminal emulator (such as Gnome terminal) is what would matter. I suppose maybe both but I would think tmux would just pass through.

Tmux needs to know that there are graphics on the screen and redraw in any of those situations.

What the terminal processes processing is a stream of bytes from the shell and needs to be able to interpret them in order to lay things out correctly.

Also graphics response in terminal are blazing fast, and compared to whatever is happening in the Apple, MS and Gnome GUI environment that are just getting sluggish by the version upgrade. More and more I just want to do everything in terminal, and not have to deal with all this GPU acceleration BS that is happening. Give me the UI in pixels likes it is 1980's. Most of times just want to do my work, We don't care if there is some anti-aliasing or shadows under the text.

Gnome is far from slow, and doing it properly matters. Sure, you can also have mouse and whatnot integration in a terminal.. but it becomes questionable.

The real power move here would be to embed the images as verbatim sixel inside the README file. Thus you could cat README and see them in all their glory.

  $ lsix
  Error: Your terminal does not report having sixel graphics support.
  
  Please use a sixel capable terminal, such as xterm -ti vt340, or
  ask your terminal manufacturer to add sixel support.
  
  You may test your terminal by viewing a single image, like so:
  
  convert  foo.jpg  -geometry 800x480  sixel:-
  
  If your terminal actually does support sixel, please file a bug
  report at http://github.com/hackerb9/lsix/issues
  
  Please mention device attribute codes: ^[[?6c

Is there an open-source windows terminal which supports Sixel? Mostly seems only Cygwin or WSL stuff out there, nothing pure?

If I open my (untrusted) downloads folder using Gnome Files and it displays (and therefore parses) the contained images, is that a security issue I should be concerned about?

(I would have assumed that (e.g.) Javascript in PDFs could be problematic, but not a simple preview.)

Rather than using a ton of server-side image libraries to render the picture into sixels on the server, it just sends a base64-encoded copy of the whole image to the client where it can determine the image type and render it into the terminal locally.

https://iterm2.com/documentation-images.html

And I'd really like to see exiftag support, like the ImageDescription, in the long form.

And I would be a bit concerned about security, but it's certainly not as dangerous as unicode

This kind of arbitrary special case can often be aggravating in software. Something's mysteriously not working for some reason and you have to hunt around to work out how to "fix" it. I'd rather see it being slow on some files (which is understandable) and if it's a pain, look for an option to skip slow files.

It works without problems with Mintty and I'm confused about how it manages to draw individual pixels in the terminal.

It's the first time I try such an image viewer and I feel so relieved to not have to download images to view them anymore (or to view them in VS Code).

(Looks like they might only be in the pixmaps, not accessible as text to the terminal.)

I mainly use a modified version of iTerm2's imgcat script for browsing images (remotely through SSH and locally) and knowing the filename.

This lsix tool is faster than my imgcat based script, though, so it looks like I have some room for tweaking/improving.

Common build-time requirements:

- bash

- m4

- libtool

Image decoding libraries:

- libpng

- jbig2decjpeg-turbo

- libtiff

- openjpeg

- ghostscript

- giflib

- openexr

- webp

- jpeg-xl

- aom

- libde265

- x265

- libheif

- libraw

Image manipulation:

- imagemagick

- liblqr

- little-cms2

Font-rendering (needed to display vector formats):

- freetype

- fontconfig

General purpose and/or math libraries:

- glib

- libomp

- imath

- highway

This leaves the following:

- brotli : a compression library; I suspect some image format uses it.

- libidn : probably a deep dependency, command line tools ought not be doing domain-name lookups

- libvmaf : A video related library; probably a dependency of one of the video-codec based image libraries?

- shared-mime-info : figure out what file type a file is

- jasper : found a few possibilities for what this is; I don't use homebrew so don't know how to resolve a brew name to an OSS project

All in, I'd say it has remarkably little in dependencies that aren't directly connected to fulfilling the job it's supposed to do (bash, libtool, m4 - looks like build time does; libomp, highway, imath - useful optimization libraries; glib - living in C land is a PITA; shared-mime-info - useful for file type recognition and handling) and I would be totally unsurprised if some of them weren't transitive deps anyway (esp. libomp and highway).

So I'd say it's very light on dependencies.

have you seen some of the dependency trees for npm packages? not really sure your point here