> 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.
* 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.
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 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:
Look at the “The transmission medium” section. I’m reasonably familiar with what can go wrong when messing with files you shouldn’t mess with on Linux, I’ve worked on the various security mechanisms that can help, and I would not want to implement this. If someone wanted me to consult on implementing this, my advice would be, first and foremost, not to.
There isn’t even a “security considerations” section in the document!
Since your comment is (was) topmost, I want to clarify that while kitty seems to have an overlarge attack surface, Sixel doesn't seem bad at all.
There's an escape code to enter "sixel" mode, then base64-style data representing 1x6 pixel bitmaps, then an escape code to get back out.
No vector graphics that might overdraw unexpectedly (security considerations!), no mechanism for out-of-band data (security considerations!), no unproven compression libraries (security considerations!), but also none of the extra magic that something like kitty would provide.
I could live happily with Sixel being universally supported in my terminal emulators.
FUD as usual. I am so sick of people waving around the security word. If you are scared of dealing with files on Linux, I suggest you throw your computer in the garbage and retire to a mountain fastness with no electricity. If you have a specific criticism of the kitty protocol make it, otherwise spare us the vague FUD.
Love the idea, but Sixels are a can of worms - it’s inefficient and it’s unclear how they should map to physical pixels - most do 1:1 but I’d prefer a more historically accurate mapping similar to the original terminals that supported them. It was originally designed for dot-matrix printing and later implemented in CRT terminals.
Also, ReGIS and Tektronix (disclaimer: I proposed including Tek graphics in VTE) could also be very useful.
Is ReGIS support uncommon? I know the terminal I use on Linux (mlterm) does, as does plain ol' xterm of course. (As an aside, it's annoying how many terminals set TERM to `xterm-256color` without being xterm compatible.)
>how they should map to physical pixels - most do 1:1
Isn't this can of worms inherent to the subject, anyway? This question has been asked - and answered - by pretty much every rendering/display system, ever.
Seems to me, sixel adoption at this point is the pre-cursor to optimization ...
This. At least add the check/cross to the table at the beginning, so you can get an idea how widespread support is. Having to scroll down is really annoying.
Yeah, sorry about that. I threw this together with the first terminal-like Hugo theme I could find, since I wanted to focus on getting the info out there. I'd probably either have to create a custom theme, or just rewrite the site from scratch. Your point is noted though--others have brought this up.
FWIW, it might be worth mentioning in this context that iTerm 2 also has its own protocol for displaying pixels, so you can cat images in the terminal using an "imgcat" script that they offer for download:
Shouldn't you just use a web browser or a GUI at some point, if you're trying to do graphics? Adding bitmaps seems like feature creep, muddying the whole purpose and appeal of the terminal.
Next you'll want accessibility, alt text for blind readers, DPI awareness, responsive scaling on different screens, etc.
For the record: My terminal emulator does not do sixel, and providing that or any other graphics mechanism is not a design goal, and not in keeping with the internal mechanics of storing the terminal display as an array of character code points. The terminal emulators that my terminal emulator is designed to supplant, the kernel built-in emulators of Linux, FreeBSD, OpenBSD, NetBSD, and indeed SCO Unix, don't do sixel graphics.
This is not to say that I am against sixel. As someone who was doing graphics on terminals in the 1980s, sometimes by accident when I catted the wrong file, the idea that "terminals don't do graphics" seems blinkered and ahistoric to me. They do and did, in my direct experience. I'm simply not targetting that as a feature in a program that has the specific goal of matching specific kernel built-in emulators. You know where XTerm is if you want it. (-:
On the gripping hand, my terminal emulator does Unicode (as do several of the kernel built-in ones, albeit with severe limitations), and so all of the things that one can do with Unicode pseudo-graphics are possible on it, from MouseText windows through progress bars using the 1/8th block glyph set to PC-style line drawing.
I just started using this! I'm making a tool called command-line-maps, its gonna be amazing.
Echoing another comment here, it doesn't work in tmux though which is pretty heartbreaking. But viewing beautiful maps in the terminal is amazing, and works perfectly.
(I'm using the alacritty branch that supports it, worked perfectly.)
Displaying the result of a command as a graph (histograms, plots) can be more pleasant than a bunch of **** bars. An external graphic window works well too, but displaying in place can be convenient sometimes, no need to click or alt-tab.
Running MRI processing on a super computer and I want to check at a certain point in the pipeline that things went correctly by viewing a couple of slices without downloading a huge brain image
Show images inline and have it scroll with other text. This is useful for working with programs that process images. For example, ImageMagick can render a PNG in the terminal like this:
convert image.png six:-
"six" means use Sixel format, and "-" tells it to write to stdout.
Checking snapshot diffs from git repo. I would love doing that in terminal instead of opening in external app.
I have scripts that do diffing and opens results in external app, but I will replace this with in-terminal images when I will find out a way to do that.
I find it a lot faster to do icat previews than bother opening up an application to find & view a specific image. Even something as lightweight as feh, is still gonna open a split in my window manager which in going to be more jarring than a preview in the terminal.
It would allow portable graphics applications on the terminal, e.g. this C64-emulator-in-Docker only renders ASCII characters, but could be extended with sixels to render graphics (I actually tinkered with this, but didn't get far because most terminals have either none or too slow sixels support):
Sixels are cool. There's one thing I wish konsole would do better: if you draw a sixel image, and then zoom in/out, the image should also zoom in/out. It should scale the sixel graphics and the regular text the same way.
And the kitty protocol also supported by konsole has the exact same issue last time I tried, doesn't zoom in.
Please, let's move away from red and green as "good"/"bad" colors. It's hard to tell the difference for colorblind folks, especially when the symbols used are quite similar.
Why do I smell another “just adding more capability…” thing turning into an OS? Maybe only for devs? Sure there’s a long way, but I see it coming. This time without DOM.
[+] [-] TeddyDD|2 years ago|reply
> 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
[+] [-] kps|2 years ago|reply
[+] [-] derekzhouzhen|2 years ago|reply
* 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.
[+] [-] diarrhea|2 years ago|reply
So after all these years I still managed to not need tmux. Am I missing out? Everyone seems to be using it.
[+] [-] ingenieroariel|2 years ago|reply
[1] https://github.com/cipharius/kakoune-arcan [2] https://github.com/letoram/cat9
[+] [-] sgt|2 years ago|reply
[+] [-] dbdoskey|2 years ago|reply
[+] [-] 3np|2 years ago|reply
This is a more promising and updated sixel branch of tmux, which is slowly getting updates propagated to mainline.
[+] [-] Per_Bothner|2 years ago|reply
[+] [-] shrimp_emoji|2 years ago|reply
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:
[+] [-] opan|2 years ago|reply
I'd rather not live without it even on local stuff. It's way too good. Yes, I already use a tiling wm, and no it's not the same.
[+] [-] kragen|2 years ago|reply
loose coupling via byte streams is great, and so is text, but we can do better than character cell terminals
if you sacrifice textuality, xpra does reattachment, multiwindow, and lowish bandwidth pretty well
[+] [-] mnky9800n|2 years ago|reply
[+] [-] amluto|2 years ago|reply
https://sw.kovidgoyal.net/kitty/graphics-protocol/
Look at the “The transmission medium” section. I’m reasonably familiar with what can go wrong when messing with files you shouldn’t mess with on Linux, I’ve worked on the various security mechanisms that can help, and I would not want to implement this. If someone wanted me to consult on implementing this, my advice would be, first and foremost, not to.
There isn’t even a “security considerations” section in the document!
[+] [-] syncsynchalt|2 years ago|reply
There's an escape code to enter "sixel" mode, then base64-style data representing 1x6 pixel bitmaps, then an escape code to get back out.
No vector graphics that might overdraw unexpectedly (security considerations!), no mechanism for out-of-band data (security considerations!), no unproven compression libraries (security considerations!), but also none of the extra magic that something like kitty would provide.
I could live happily with Sixel being universally supported in my terminal emulators.
[+] [-] aumerle|2 years ago|reply
[+] [-] RustyRussell|2 years ago|reply
[+] [-] rbanffy|2 years ago|reply
Also, ReGIS and Tektronix (disclaimer: I proposed including Tek graphics in VTE) could also be very useful.
[+] [-] kps|2 years ago|reply
[+] [-] aa-jv|2 years ago|reply
Isn't this can of worms inherent to the subject, anyway? This question has been asked - and answered - by pretty much every rendering/display system, ever.
Seems to me, sixel adoption at this point is the pre-cursor to optimization ...
[+] [-] detrites|2 years ago|reply
Probably work better if it was a comparison table, with ticks and crosses all in one column.
[+] [-] iforgotpassword|2 years ago|reply
[+] [-] smasher164|2 years ago|reply
[+] [-] busfahrer|2 years ago|reply
https://iterm2.com/documentation-images.html
[+] [-] smasher164|2 years ago|reply
[+] [-] kps|2 years ago|reply
[+] [-] koterpillar|2 years ago|reply
Recently discovered Kitty's graphics protocol (https://sw.kovidgoyal.net/kitty/graphics-protocol/) which has more features or at least more documented ones :)
[+] [-] QuadrupleA|2 years ago|reply
Next you'll want accessibility, alt text for blind readers, DPI awareness, responsive scaling on different screens, etc.
[+] [-] kmac_|2 years ago|reply
[+] [-] JdeBP|2 years ago|reply
This is not to say that I am against sixel. As someone who was doing graphics on terminals in the 1980s, sometimes by accident when I catted the wrong file, the idea that "terminals don't do graphics" seems blinkered and ahistoric to me. They do and did, in my direct experience. I'm simply not targetting that as a feature in a program that has the specific goal of matching specific kernel built-in emulators. You know where XTerm is if you want it. (-:
On the gripping hand, my terminal emulator does Unicode (as do several of the kernel built-in ones, albeit with severe limitations), and so all of the things that one can do with Unicode pseudo-graphics are possible on it, from MouseText windows through progress bars using the 1/8th block glyph set to PC-style line drawing.
[+] [-] __MatrixMan__|2 years ago|reply
I'd like to play with terminal graphics in a an app I'm working on. Does anybody know if a terminal which supports:
- wayland - sixel - copying substrings without a mouse
I know I can just pipe to wl-copy, but sometimes the right chain of sed & awk is less convenient than the right chain of vim highlight movements.
[+] [-] RupertEisenhart|2 years ago|reply
Echoing another comment here, it doesn't work in tmux though which is pretty heartbreaking. But viewing beautiful maps in the terminal is amazing, and works perfectly.
(I'm using the alacritty branch that supports it, worked perfectly.)
[+] [-] mfeldheim|2 years ago|reply
[+] [-] drdebug|2 years ago|reply
[+] [-] NeuroCoder|2 years ago|reply
[+] [-] TeddyDD|2 years ago|reply
[+] [-] omoikane|2 years ago|reply
Demo (running on cygwin's mintty): https://twitter.com/uguu_org/status/1631207051602042880
[+] [-] coderpersson|2 years ago|reply
[+] [-] daliusd|2 years ago|reply
I have scripts that do diffing and opens results in external app, but I will replace this with in-terminal images when I will find out a way to do that.
[+] [-] toastal|2 years ago|reply
[+] [-] flohofwoe|2 years ago|reply
https://github.com/floooh/docker-c64
[+] [-] ape4|2 years ago|reply
[+] [-] Aardwolf|2 years ago|reply
Having these intermixed between the regular scrollable textual output is quite powerful.
[+] [-] schappim|2 years ago|reply
https://news.ycombinator.com/item?id=35940691
[+] [-] Aardwolf|2 years ago|reply
And the kitty protocol also supported by konsole has the exact same issue last time I tried, doesn't zoom in.
[+] [-] jackhalford|2 years ago|reply
[+] [-] pimlottc|2 years ago|reply
[+] [-] Aerbil313|2 years ago|reply
[+] [-] ok123456|2 years ago|reply
[+] [-] shmerl|2 years ago|reply