> It's 2021, and we should be able to do litterate programming in the console, with full graphical support.
Yeah. We are stuck cosplaying computers from the sixties.
What's even funnier, even if you find a modern terminal emulator that supports features like ligatures, graphics, emoji etc. you still will be blocked by tmux. Sure - not everyone needs tmux. If you never work on remote machines, you can live without it.
But I work on remote machines all the time. I also use Kakoune text editor that defers window management to external tools (WM or tmux, but to be honest, tmux is much better). Zellij is more of r/unixporn bait than usable tool for now. So I'm stuck with text only interface.
For those like me with the opposite inclinations, try dtach. It is only a session handler. It does not pretend to be a terminal, or do splits or tabs or anything but I/O. That's left to your actual terminal.
I mean, you could avoid knowing anything about the terminal state machine if you dumped the entirety of the session’s bytestream from the very beginning on each attach event, but unless you are willing to do that it seems to me that you’re going to have to track enough state to basically amount to maintaining a screen buffer (and then you do have to care about sixels).
For example, suppose the user fills the screen (maybe even with an image), then spends a lot of bytes overwriting the last line over and over (think progress bar). Either you’re tracking the first byte to have affected the current screen (and need to store the entirety of the “a lot” and dump it onto a newly attached client) or you’re trying to discard all the stale updates while keeping the last one and the initial screen contents (and that’s just a screen buffer with extra steps). (Incidentally, I suspect Muratori’s Refterm fails this test to the point of requiring a redesign, though I haven’t checked.)
dtach sends control-l or sigwinch or one of a few other things when you reattach, at your option, so if you're running a fullscreen program that cares about the terminal state machine, it will redraw itself
I see, yeah, that’s neat. I can still imagine situations where it’ll fail, but they’re reasonably limited. (If you detach and attach in the middle of a large sixel image being transmitted, you’ll have the tail of it dumped on you in text form; if you detach from a session with the terminal set to red text, it’ll be back to default when you return; and so on.)
For me the most common breakage was due to ssh dropping overnight (by corp security policy) while a remote editor has the (local) terminal in an altered state (i.e. modifyOtherKeys). Easy to recover, and for me well worth it for the direct I/O passthrough.
> do splits or tabs or anything but I/O. That's left to your actual terminal.
I use tmux exactly to split panels in any way I want. My terminal (iTerm2) doesn't give me the full power to manipulate windows/panels using shortcuts.
But unfortunately I'm gonna have to stop using tmux because it's not compatible with sixel. I spent a lot of time ricing it tho...
* show multiple terminals on screen. The best solution is to use a tiling window manager. Both MacOS and Windows have limited windows tiling capabilities.
* run long term TUI applications (like editors). The best solution is mosh.
* run long term CLI applications (like shells). The best solution is dtach.
tmux helps all 3, but not particular good at either.
> tmux helps all 3, but not particular good at either.
iTerm2 on macOS has some nice tmux integration[1]. Basically, you run a tmux session (using tmux -CC), but the actual window management on the client side is handled by iTerm2. This works pretty nicely with the tiling WM (Amethyst[2]) I use on macOS.
If anybody is aware of Wayland compositors that integrate similarly, please let me know. I'd love to be able to do the same on my linux machines.
I simply open multiple ssh sessions if that’s what’s needed. My terminal can then natively do tabs, panes, ligatures, emojis etc. There’s no middleman.
So after all these years I still managed to not need tmux. Am I missing out? Everyone seems to be using it.
I got in the habit of using GNU screen and so have never used tmux. But if you have a long-running text UI program (e.g. irssi) you want to be able to connect to on a whim and pass around to multiple client sessions, they're handy for that.
Yeah, I've also been using screen for years without ever feeling the need to switch to tmux. Although remote ssh work is relatively rare for me (eg a couple times per month)
That's by far a different work experience. Imagine to start a long running process on remote, probably after hopping through a number of different machines. The long running process should not get killed. This is not possible to guarantee on ssh connections.
Similar, I keep all my work alive in remote sessions in tmux. Vim IDE, mutt, ... I would not want to re start this everyday. The best part is, I can reach my setup from office and from home and mobile. And if necessary even from my phone.
tmux is one of those things that is nice if you take the time to learn and actually USE it for awhile.
But it doesn’t have amazing uses that immediately make you say “wow”. The biggest I’ve found is setting up something on a remote server and being able to disconnect it. For example it can be much nicer for running a Minecraft server than daemonizing.
I felt the same way, but ended up learning tmux because you can't make asciinema span multiple tabs or panes, and sometimes you want to make an asciicast with more than one shell.
It's handy to know sometimes, but if I have a sane window manager at hand then I don't use tmux. They're not common, sane window managers, so I use it occasionally.
In my memory, the patch was not in upstream and even more far away from distro packages at the time tmux came alive.
I also went with tmux for vertical split (left-right panes)
As an end-user, what software you choose to use is a form of advocacy for that software and its license. So it does matter, but you can choose to not care.
zellij is amazing in terms of UI/UX, but in my experience not as stable as the older options. Which is understandable, screen and tmux have had decades to sort things out, but it does mean that given the general messiness and complexity of remote network connections (which is the most common use case), running into these rough edges is not difficult at all.
I feel like zellij is the future of terminal multiplexers, and I like using it in my personal machines, but I stopped using it for work after a while.
I think DomTerm (in addition handling sixels and extended emoji) does multi-plexing and remoting quite well. Remote access (https://domterm.org/Remoting-over-ssh.html) is done with a simple wrapper over ssh. Mosh-style predictive echo. No special priviliges needed: Just drop a domterm executable somewhere on the remote machine. Multiplexing with tabs and tiles that can be dragged between windows. Builtin attach/detach.
I use emojis on tmux. I don't think it conflicts with them. :o
You just have to have an emoji font installed (Twemoji, of course). And I use Alacritty, a Rust-based, GPU-accelerated terminal editor. How's that for "modern"? :sunglasses:
while it is indeed useful for a terminal emulator to be efficient at discarding characters you will never see, it probably isn't the main criterion to judge it by
I presume you're talking about Alacritty? Because Terminology doesn't do this AFAIK (and there's a mini-map next to the scrollbar showing everything that came by)
Author of sixel-tmux (and of the matching rant) here.
Your description of sixels using words like 'cosplaying' or 'late 90s japanese cellphone' is not very technical. It seems biased. In any case, it would be better than being stuck with the 60s "text only" VT100 like protocols.
We can talk about technicalities, as some people do not like how sixels work under the hood, but... they work fine: I can play video in my terminals. I use gnuplot everyday.
Could it be done better by a protocol that would use compression and other features? Maybe. But does it have to be? Why should we waste time reinventing the wheel when locally there's plenty of bandwidth, and remotely too often enough?
Personally, I like sixels because prefer a standard that is well defined, and can't change on someone whim: I like stable interfaces.
I think users are unfairly held back due to biases like the one you demonstrated, and that seem very common in the free software world, which was the point of my rant: there is no logical reason sixels couldn't be offered today in gnome terminal if the key people making sure that doesn't happen changed their mind.
bandwidth is almost always an issue for local terminals; a 4k (3840×2160) terminal at 120fps and 32bpp is 4 gigabytes per second, and according to https://news.ycombinator.com/item?id=35694801, typically with ddr4 ram you get 30 or 40 gigabytes a second
if you send all that video data through the ddr4 bus twice (once writing, once reading) you're using about 20–25 percent of the machine's memory bandwidth, but the linux tty subsystem actually makes several copies and runs many instructions per byte [citation needed] so you can't get anywhere close to that in practice. especially not if you're spending a lot of time repacking bits into six-bit bytes in order to feign compatibility with the vt340, a misguided engineering dead end from 37 years ago that only supported 16 colors and 800×480 anyway
other protocols like x11 and xpra work considerably better, but x11 video reproduction on a local terminal normally uses xshm or its moral equivalent with xvshmputimage or gl. if you're on a local terminal, you might as well use x11; the only benefit to putting the pixels in the same bytestream as text is if the your terminal is connected to your drawing application over a bytestream such as an ssh connection, a tcp connection, an spi connection, or a uart
i think we could do better by designing a bytestream protocol that minimizes copies and pixel format conversions and is therefore within epsilon of the speed of xshm, but sixel isn't it, and neither is x11 without xshm. a bidirectional bytestream protocol could include flow control to also avoid transmitting pixels that won't be visible and increasing latency due to bufferbloat
as for emoji, they don't improve information density; there are only 2666 emoji in unicode 10.0, so at a maximum they convey only 13 bits of information, and they normally occupy roughly the space of two letters like 'n', so you have slightly fewer bits per pixel. people use emoji because they are cute and colorful, not because they are ithkuil. they're not
some technologies, like the unix shell, smalltalk, and tcp/ip, make hard things easy and easy things possible. others, like retrocomputing, code golf, and malbolge,
make easy things hard and hard things impossible.
sixel makes easy things hard and hard things impossible, like the rest of retrocomputing.
that's a fun way to spend my time when i choose to (e.g., in https://asciinema.org/a/390271 i did real-time 3d graphics in a unicode terminal emulator with braille) but it's not how i want my primary user interface to my computer to work
Sixel is defined for two purposes: the first is to allow display of bitmaps. the second is to allow the definition of characters glyphs (which xterm does NOT have -- due to graphics limitations). If the glyph definition could be done, your bandwidth requirement would be reduced. Back in the 80's we generated custom fonts for PostScript (the Apple laser printer PostScript would cache the glyphs). As needed, the printer would request glyps and these would be supplied by an external driver or box (we called this the "Robin Box" for fairly obscure reasons). This system provided pre-press proofing for many customers (which would include publishers like Ziff-Davis). Please note that the speed of the communication was 9600baud (1000 cps). The image of that printer was 300x300 dpi, with some printers doing 600x600. Sixel would have been good... we used ASCII.
I like sixel -- I use xterm which gives me the option. For everything? No. but if I need a graphic, it is easy enough to use. The alternative for most would be to simply generate PostScript, and run GhostScript to view the results (typically on another system). I have NEVER contemplated watching a video with sixel... I could do it, but the player would be a "labour of love" - I would use a common decoder to produce an uncompressed bitmap (scaling and colour reduction) then convert that into frames of sixel... Just to show StarWars on a 340. But, no urge.
The main issue is that sixel offers the feature. No real reason to NOT have it... and it exists.
Try pbmtoln03, ppmtosixel, imagemagick convert and lsix
sixel is not a protocol: just an encoding. Your idea conflates the two things.
The purpose of the Robin Box? The publishers typically had hundreds or thousands of typefaces. The PostScript Printer? 15 to 50. Since RAM in the printer was limited, this approach allowed the scanning of the target typeface, conversion to outline form and production of dynamic programs executing in the printer. That are discarded but results cached. (and note that
technology is within a period that, in this case, was bounded by RAM space, and typographic conventions -- all of which changed fairly rapidly).
That approach allowed hundreds of typefaces to be used on a single page! With "standard" PostScript; on a printer with only a megabyte or so of RAM available. Sixel is simply a similar tool. You really can't predict how something like would be used if it were generally available.
yeah, i agree that sixel was a reasonable way to implement downloadable fonts in the 01980s, though one that handled line noise and background process output interleaving poorly
(see supdup's graphics protocol for a better design for integrating pixel graphics into a (still retrocomputing) serial terminal. however, supdup foolishly omits any font-downloading facility)
i just think sixel, whatever its merits for the problems of 40 years ago, is a worse way to display graphics today than things like x11, which is itself no shining gem, just not as bad as sixel. also we're sort of stuck with most of x11 for the foreseeable future because there's a lot of software written for it; let's make sure that doesn't happen with sixel
(you point out that sixel is an encoding, not a protocol, which is sort of true, but it has an associated state machine in the terminal, so it's also sort of a protocol, and that's the part that has the poor error-recovery characteristics)
by 'worse' i mean: it requires more effort to achieve an equivalent result; it provides a worse result with the same effort; and there are some results it simply can't achieve that the alternatives can
if you're looking for a puzzle to solve for fun, of course, those are advantages, not disadvantages; but i repeat myself
it's especially an advantage if you find something that was previously thought to be impossible due to laboring under such artificial limitations but turns out to actually be possible despite them
here are some more nontechnical descriptions of sixel that are more correct than any technical description possibly can be
sixel is oulipo programming; encoding your graphics in sixel is like writing a novel without the letter 'e'. btw, a wonderful article about oulipo programming is https://100r.co/site/working_offgrid_efficiently.html
sixel is an art project, not an engineering project
> there is no logical reason sixels couldn't be offered today in gnome terminal if the key people making sure that doesn't happen changed their mind.
I read through that entire Bugzilla page, and IMHO the usability and technical concerns are pretty valid. You can say "well, those are not an issue for me" or "I can live with it" and that's entirely fair, but I can understand how a maintainer would want it to work really well before merging.
Also, I believe it did get merged in 2020? The current status is a bit unclear to me.
Same. Sixel support in gnuplot is very useful: it’s great to have decent graphics without relying on X with dodgy vpns. It’s probably not the most useful feature, but it was a significant QoL improvement when I found out the Sixel terminal.
> It's 2021, and we should be able to do litterate programming in the console, with full graphical support.
Yeah. We are stuck cosplaying computers from the sixties.
What's even funnier, even if you find a modern terminal emulator that supports features like ligatures, graphics, emoji etc. you still will be blocked by tmux. Sure - not everyone needs tmux. If you never work on remote machines, you can live without it.
But I work on remote machines all the time. I also use Kakoune text editor that defers window management to external tools (WM or tmux, but to be honest, tmux is much better). Zellij is more of r/unixporn bait than usable tool for now. So I'm stuck with text only interface.
[1]: https://github.com/csdvrx/sixel-tmux/blob/main/RANTS.md