In case you're like me, and you wouldn't think of using a terminal without Tmux, the experimental sixel branch was finally merged[0] as of about 10 months ago. This means you can finally build mainstream Tmux with --enable-sixel and use tools like lsix in Tmux!
If you're curious if your favorite terminal or multiplexer supports sixel, you can check out the "Are We Sixel Yet"[1] site.
[0]: https://github.com/tmux/tmux/commit/dfbc6b1888c110cf0ade66f2...
As long as terminal used supports sixel graphics.
xterm supports sixel, so surely anything that sets TERM=xterm256-color or similar will be compatible… right? ∗cough∗ gnome-terminal ∗cough∗
xterm supports sixel, so surely if your TERM is xterm-kitty, it's supported right?
I would say so, yes (not a fan of kitty's general NIH), but it could be argued that `xterm-kitty` is at least not identical to a $TERM used for xterm.
Indeed. I was trying to humorously reference the author's staunch refusal to remove `xterm` from the TERM identifier, knowing full well that many programs simply look for `^xterm` when determining if the terminal is compatible. As you eluded to with 'NIH', the same author refused to implement Sixel in Kitty because it is "inferior" to Kitty's image implementation.
What does "NIH" mean in this context?
Kitty developer decided to go with a custom image display protocol instead of going with sixel.
Not Invented Here
https://en.wikipedia.org/wiki/Not_invented_here - When someone or some group prefers to re-invent something rather than using an existing, perfectly serviceable solution.
Why do we now have User-Agent in the terminal ;-;
Isn't the TERM variable ancient? I know one of the "common" exported variables is the VT100, sold in 1978.
Yes, it is very old.
I wrote a graphics library for non-sixel terminals
https://github.com/dheera/python-termgraphics
Might be interesting to mod this library to support this as a fallback.
Looks good! I've seen a few such libraries. My favorite is chafa: https://hpjansson.org/chafa/
A labor of love, congratulations.
mlterm works
Something interesting might be to mix in object detection in images, for something like:
`lsix --search cat`
And find all the images that contain cats.
That comic lost some meaning in recent years, you could put out some decently accurate bird detection model by following a 30 mins YouTube video, it was even one of the first exercice in some ML youtube courses (can't remember the channel).
But it still retains some meaning. Using a glob pattern to wildcard files with the same name vs. running an image entity classifier across 1 to n images in potentially recursive directories. In a command line utility for displaying files.
well sure. But if you were building this for actual usage, you'd have a separate cron-style tool that would monitor your picture folder (and its subdirectories) for new images. Feed aforementioned image into Llava or any number of image classifier APIs, embed classification information as IPTC data into the image file. Then give the CLI flag for the search tool the ability to do partial word search on metadata within images.
Maybe more in the sense of the Unix philosophy: The detection should happen in a separate tool of which the output filenames can then be piped into lsix.
To be fair, that comic was published around ten years ago. I'd say the example it used to make its point was reasonably accurate.
Yes for sure and the general idea is timeless anyway.
Jeremy Howard references this xkcd in the very beginning of his stable diffusion course[0], and builds such a detector in about 10 minutes.
wouldn't that be grepix cat *?
Quite the list of deps (from brew install): dependencies for lsix: bash, libpng, freetype, fontconfig, jbig2dec, jpeg-turbo, libidn, libtiff, little-cms2, openjpeg, ghostscript, brotli, giflib, highway, imath, openexr, webp, jpeg-xl, libvmaf, aom, libde265, glib, shared-mime-info, x265, libheif, liblqr, jasper, libomp, libraw, m4, libtool and imagemagick
The only direct dependency is imagemagick; the rest are pulled in by that; here's a breakdown:
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
Nice breakdown.
I think jasper is this, a library for JPEG-2000 images: https://www.ece.uvic.ca/~frodo/jasper/
Linked to from here: https://formulae.brew.sh/formula/jasper
Weird then that there is already openjpeg which is also for j2k.
A lot of them seem pretty reasonable, I wonder though if it would benefit from some optional dependency based scheme
Not really, imagemagick is the only package it needs installed (apart from bash and coreutils).
Majority are simply to support opening different types of graphics (still and moving) files. Some are necessary just for the build process.
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.
if you want to look at media, you gotta have the proper codecs--and there's a lot of them. that's what the majority of them are.
have you seen some of the dependency trees for npm packages? not really sure your point here
Pretty much all of these are dependencies of imagemagick, because that supports tons of image formats, often via things like lib$format. The script itself just depends on bash, imagemagick, and a few standard shell tools like sed.
Awesome idea, but doesn't work under PuTTY/KiTTY:
$ 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?
I started using wezterm recently and really like it. It's cross platform and supports sixel graphics.
I can no longer edit my post. I just saw that apparently it doesn't work with wezterm on Windows. Sorry about that.
Mintty is an excellent windows terminal with sixel support fyi.
Be careful running this on an untrusted directory, especially with e.g. pdfs, just like anything else that parses images, especially using ImageMagick.
Is parsing untrusted images inherently problematic?
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.)
Random example that doesn't even require opening the directory.
https://github.blog/2023-10-09-coordinated-disclosure-1-clic...
Unfortunately, it can be a vector[0], especially on less security focused software that has less sandboxing.
0: https://www.cvedetails.com/vulnerability-list/vendor_id-7294...
I think my favourite feature of this repo is the `README.md.d` directory. That's actually a nice idea. Could maybe drop the `.md` I guess.
I think my favourite feature of this repo is the `README.md.d` directory.
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.
Along similar lines, timg : https://github.com/hzeller/timg
Another that I've used: https://github.com/posva/catimg
Anyone knows why the hell the most used terms do have no sixel support? The libvte based ones.
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
iTerm2 for MacOS has similar functionality baked in, but less demanding on the server side.
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.
konsole implemented the same protocol; I use their unmodified imgcat script on Linux. It's of course much faster than converting using imagemagick, still added lsix to my bin directory for now. :)
fzf has "(Experimental) Sixel image support in preview window (not available on Windows)" since version 0.44.0
https://github.com/junegunn/fzf/releases/tag/0.44.0
fzf --preview='fzf-preview.sh {}'
Alternatively, fzf --preview 'convert {} -geometry 800x480 sixel:-'.
It also requires ImageMagick installed.
Do the filenames work with text selection?
(Looks like they might only be in the pixmaps, not accessible as text to the terminal.)
They don't (on iTerm2), which makes this of fairly limited utility for me, since my next operation would be to copy the filename and act on it.
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.
Unfortunate capitalisation, it took me a copy-paste to realise the first letter is a lowercase L, and not an uppercase i.
The name is at least consistent.
"ls with sixel" => "ls six" => "lsix"Sadly Emacs does not support VT340.
Are there any plans to support the features? Or is it just not a direction for the devs?
"However, some may be slow to render (like PDF), so lsix doesn't show them unless you ask specifically."
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.
This seems like a reasonable point. Add an option to skip slow files if needed, but don’t skip them by default as it leads to unexpected behavior
See, that is pure genius!
Oh that's great! Finally a way to server-side getting pwned right in the shell with the next imagemagick security hole!
Gets some points for referencing Kermit in its documentation.
This is a great tool.
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).
Uses "\e[c" to automatically detect sixel support:
https://github.com/hackerb9/lsix/blob/3a431793a747df3f934051...
"\e[c" is "send device attributes":
https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-F...
I wish we had all these goodies in default linux console (I know about and try to use kmscon sometimes...)
The example screenshots feature a terminal with a "foo@kremvax" prompt, nice touch :D
The lengths people will go to avoid leaving the terminal
The HN font is very misleading here. I am waiting for the next headline: 'Isis, like "ls", but for terrorists.'
I'm not sure I understand the use of tmux. Can someone explain why it's essential to their workflow and why it might end up being essential to mine?
Tmux provides a means multiplexing a single terminal window into multiple terminals, either full screen, or like a tiling window manager. It lets you organize and label these terminals and provides a very flexible keyboard interface to terminal management, including history scrollback, search, etc. I started using GNU Screen in the early 90s, and over the years I have developed a keyboard muscle memory for managing multiple terminals in this fashion that is completely independent from whatever terminal program I'm using. This allows me to utilize this keyboard muscle memory if I'm using iTerm2 on macOS, Windows Terminal, or Alacrity on Linux.
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.
It's also very good if you're SSHing over an unreliable connection. The tmux terminal doesn't break when your connection does.
This is exactly the same reason I had in the 90s using tmux’s precursor, GNU screen. With dialup or crappy isdn, screen -R was always the first input after login
Have we gone from shitty connectivity to stable and then back to shitty?
I still use screen, is tmux better?
By a decent measure, yes. It's screen plus modern QoL additions like multi-panels/windows/tabs and a giant pile more, and it's decades-stable so that's not like a "node framework of the week" pile of useful stuff that you'll have to rip out next month. It's very firmly established as a full screen successor.
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.
It's handy even if you just need to go from work to home to Starbucks or whatever. Doesn't have to be a poor connection as much as one that changes occasionally.
In a way - I use laptops that move around and go on/off, as well as VPNs which do the same, network-wise.
I don't think so! But tmux is really useful for laptop scenarios, like when the laptop goes to sleep, or if you're working on a train and it goes through a tunnel with no network reception.
I use tmux, but as far as unreliable connections, I've found mosh[0] to be the best solution to the problem (when you have the ability to install it). It basically runs a background process on connection not tied to the session that your client will automatically reconnect to if the connection fails. I regularly close my laptop, travel between home and work, open it back up and the connection is available almost instantly.
[0] https://mosh.org/
Both together are even better... seamless persistence of your session across sleeps/connection lapses from mosh, and from tmux for everything else like switching client machines, a dead battery, a client's OS/terminal crashing, etc.
Absolutely. I personally prefer to use both together.
You can use shpool for this if you aren't using the other features.
Saved terminal state. Multiple tabs. Can log off and come back and everything’s there. tmux and mosh are game changers, especially while tethering/roaming and switching networks.
That should be table stakes at this point; these features should be built into all conventional desktop terminal emulators. I shouldn't have to run a second, inferior text mode terminal emulator inside the terminal emulator app that ships with my preferred desktop environment (and deal with the conflicts/impedance mismatch that falls out of this pairing).
Pretty nuts that so many desktops and independent modern terminal emulators lag so far behind GNU Screen, which was first released in 1987.
The first problem is that most of that is a result of how the remote computer handles the programs you were running. When your connection drops, all of them die immediately.
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.
Mosh is a great tool but you’re thinking of tmux like a client side tool when in fact, like Mosh, you can run tmux server side and have it manage all of that annoying state you described earlier.
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 didn’t say that it wasn’t. I was responding to the notion that “these features should be built into all conventional desktop terminal emulators.” There are reasons why it cannot just be built–in to the terminal emulator, and the best we can do currently is just to run some program like mosh or tmux on the remote side so that the terminal state is maintained correctly.
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.
Hard disagree. I very much like my terminals thin and "stupid" (sixels, clickable links, speed, and workable CJK font/IME support are about the non-standard features I really want), leaving all the navigation to something like tmux/zellij/screen.
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.
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.
Well, there's the topic of the thread...
As for me, I like the “do one thing well” philosophy — I don't want my terminal to manage multiple sub-‘windows’, because I already have a window manager that I like just fine thank you.
`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.
Personally I'd much rather run that server-side. I use iTerm which has a lot of great features for session management, but I like being able to connect from any machine and keep the exact state I was in rather than having it tied to my local client.
I prefer tmux because I can run it on servers/remote machines too. It doesn't require X so runs perfectly and happily on headless machines. Can also be nested.
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.
Lennart, is that you? ;)
Maybe one of the missing pieces here for anyone not terminal-fluent:
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.
At any given time, I'm working on like 10 different projects. tmux lets me set up sessions for each of these projects, so that when I leave one and come back in a week, all the context is there (multiple windows, bash history, working directories I was in, etc)
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.
What happens when you press page up or down in tmux? Have you configured it to scroll page up & down? Or do you do that via Ctrl-B ] or whatever the magic incantation was?
Not parent but keybindings are fully configurable. For example to scroll up with Shift-Pgup:
The first line is a top-level binding to enter copy-mode and immediately scroll up one page. The other two add bindings within copy-mode so you can continue to scroll up or down with those keys.I also have a small hack in my .zshrc to start scrolling up with `M-v` (like in Emacs) while at a shell prompt:
I used to do all of this type of stuff to get my copy-paste to work in tmux but honestly it's still a pita. The alternative I started using recently (zellij[1]) has copy and paste, scrollback, dump scrollback to editor etc just working out of the box with no fancy configuration required and also has a much saner session management mechanic that also works right out of the box.
[1] https://zellij.dev/
That's right. You have a prefix that lets you use page up page down in any pane you've got currently selected.
Ctrl-B PgUp/PgDown enters scroll mode.
When I used tmux I used to set Ctrl-PgUp/Down bindings to scroll the buffer.
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?
I used to work on CECL and stress testing models for large banks and i used tmux similarly. Lots of scripts that would take like 6 hours to run.
Similar use case here, but in a biotech company.
Anyone here who can answer this as well in the context of local work on a Mac? I manually use tmux when sshing into servers but usually that’s one session split in two and that’s it.
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
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.
I don't use tmux but I use screen which AFAIK is the same basic functionality on my Mac. I use it to run long lasting software during development, so the frontend and backend of the service I'm developing for example, since they have hot-reload.
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.
I use tmux basically the same way but prefer tmux sessions because I find tabs hard to navigate reliably.
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. <leader>+J always opens projectfoo, <leader>+K projectbar, etc.
With tabs you need to know which tab contains what and what order everything is in.
Personally I find the small shell function below really helps my tmux workflow. Run it with no arguments and you'll get a list of available sessions. Run it with a session name and it will start the session if it doesn't exist or reattach if it does. If you're already in one tmux session, it will just switch over your client to that session.
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.
I have a better version (in the sense that it automatically names sessions after the current directory):
Better is subjective. This version has no way to easily list sessions. Depends on what you want :)
I like tmux for keeping a remote session open but I don't use it for my local machine. On my local machine the only thing it would really buy me are tabs/split panes, and iTerm does those things natively and far better than tmux does.
tmux + vim with some plugins is a really good developer experience, it makes it really easy to leverage command line tools
A use case I haven't seen mentioned - from skimming the comments, is that multiple users can connect to the same tmux session.
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.
lots of good answers already. my tldr: it's a terminal-agnostic tool to split a window vertically or horizontally so you have multiple shell sessions on the same screen (and can move between them). Lots of other great reasons too but that's the major one IMHO.
why would you want browser tabs?
It provides all of the useful functionality of a window manager (hosting multiple terminals) but you can run it in a terminal.
Plenty of great use cases have already been pointed out, but what I also love is that sometimes I get carried away and use the close window keybind on the wrong terminal, with tmux set to create a new session when the terminal is launched (which isn't closed unless all shells in the sessions have excited) I just use a keybind to spawn a terminal attached to any unattached sessions and never again have to recreate 10 different panes in different working directories on different windows
Also let's my colleagues monitor my builds on our shared server pretty easily and it's better than screen sharing
I find the split screen capability very useful for terminal use, but i'm only a more basic user
Aside from tabs/panes/persistence already mentioned, it serves as a portable, programmable layer that will work anywhere, whether on the client or server side. I set up my key bindings once and now they work over SSH from Windows, local terminal emulator, on a Linux framebuffer console or even through a serial port. While I do use a tiling/tabbing window manager, tmux is just really good at what it does so I still keep using it for my terminals.
But.. why? Why would I want to force pixel graphics into a text-based, low-resolution matrix, when.. I could just do pixel graphics?
There are many terminal users, check their email in terminal, and use browser like Links, Links2, and would like to be able to see pictures sometimes.
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.
Console-based analysis over SSH is much easier when your console tools can just output charts etc directly to the terminal. Also image processing scripts are easier to write when you can directly view the images created at each stage of the process.
I'm a long time tmux user (and screen before that), but I don't understand why sixel makes a difference.
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.
Terminals and shells aren't like window managers where you can just subdivide your drawing space and pass a block pixels to something else to draw on.
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.
You can't just pass through things; what happens when you resize, (re)attach, switch tabs &c.
Tmux needs to know that there are graphics on the screen and redraw in any of those situations.
I switched to Zellij[1] a few years back, and I've been enjoying Sixel support since sometime in 2022. If you're looking to shake up your workflow, I find it's a vastly superior experience to tmux out of the box. It ships with all the features I would otherwise add through external plugins and convoluted configuration scripts by default while remaining significantly more stable and more performant.
[1] https://zellij.dev/
I can only second this comment. I discovered it a while back and it has been a pleasant experience ever since. I still use both though, depending on availibility.
My favorite feature about Zellij is the ability to have as many floating panes in arbitrary locations as desired. The way it works is that there are 2 "layers" of panes: the normal tiled panes, and a layer of floating panes that exists in front of the tiled panes. The floating layer can be toggled on and off, and the floating panes can be overlapping with each other. I have my ordered tiled panes that I work on normally, and then I can bring up my messy desktop of panes that I have lots of freedom in how I organize, more akin to an actual desk.
It's a bit silly, and certainly not necessary, but I like it a lot.
Do you happen to know if sixel is enabled when tmux is installed with brew?
It doesn't. If you run brew edit tmux and add args << "--enable-sixel" after line 76 and then run brew uninstall tmux and brew install --build-from-source tmux, you'll get one where it is.