12 ms·

Show HN: Sixel-tmux displays graphics even if your terminal has no Sixel support

161 points by csdvrx 5y ago

marginalia_nu 5y ago
The world is finally catching up with the capabilities of TempleOS.
KaiserPro 5y ago
Ooo I didn't even know that Sixel was a thing. This looks fun
- flohofwoe 5y ago
  I tinkered a bit with sixel support for my "C64 emulator in the terminal" (https://github.com/floooh/docker-c64 https://github.com/floooh/docker-c64), but unfortunately it's way too slow to get anywhere near 'realtime' output (30fps or better). Here's the (abandondend) sixel-version source code, only with two colors, more color planes would drastically reduce the performance. https://github.com/floooh/chips-test/blob/master/examples/ascii/c64-sixel.c https://github.com/floooh/chips-test/blob/master/examples/as... I really wish there was a decent pixel-framebuffer standard for terminals (with at least the same performance as ncurses). This would allow a lot of fun "terminal applications" (e.g. everything that used to run in VGA Mode 13h).
  - csdvrx 5y ago
    > unfortunately it's way too slow to get anywhere near 'realtime' output (30fps or better). That's not due to sixels. Check out the sixel nyan cat: https://github.com/hackerb9/sixvid https://github.com/hackerb9/sixvid Look at the FPS indicator in the bottom. It was pointed to me in https://github.com/microsoft/Terminal/issues/448#issuecomment-928717530 https://github.com/microsoft/Terminal/issues/448#issuecommen... The issue may be in your code. I think I have similar performance issues, as the glyph selection process could be more optimized. Derasterized is mostly Jart work (who is best known here for her work on Cosmopolitan), we were mostly interested in quality. Reducing the set of glyph to something that could benefit from optimizations could help. > I really wish there was a decent pixel-framebuffer standard for terminals (with at least the same performance as ncurses) Sixel performance is quite decent: personally, I can play videos in my terminal. Try MPV on mintty: https://github.com/mpv-player/mpv/issues/2183 https://github.com/mpv-player/mpv/issues/2183 I have also played with a X server rendering over sixel, no performance issue: https://github.com/saitoha/xserver-SIXEL https://github.com/saitoha/xserver-SIXEL When sixel support is added to Windows Terminal, I may update it, because it would be fun to have one tab to run stuff!
    - flohofwoe 5y ago
      Wow interesting, thanks for the links! I still suspect it's a performance issue in the terminal(s) I tested (mainly iTerm2 on Mac, and probably Ubuntu's vanilla terminal), because it would take a lot of effort to make encoding a 320x200 framebuffer to sixels slow ;) I should definitely have another look though, it's good to know that it is possible to get decent performance out of sixels.
      - csdvrx 5y ago
        > Wow interesting, thanks for the links! Indeed! It's nice to see what's possible! As for video playback, while it may not be realistic with the current sixel-tmux due to the size of the search space, it may be possible once the new 1FBxx block https://en.wikipedia.org/wiki/Symbols_for_Legacy_Computing https://en.wikipedia.org/wiki/Symbols_for_Legacy_Computing is integrated into derasterize and the suggested fonts: restricting ourselves to the 1FB0x-1FB3x subset would only require adjudicating about 64 characters. Some very basic programming tricks (a bloom filter after binarization of the input, memoizing...) may be sufficient to derasterize sixel videos in real time, even on an average system. > I still suspect it's a performance issue in the terminal(s) I tested If you don't use Windows, try xterm and mlterm. For xterm, I maintain a set of config files giving you a decent out-of-the box experience, cutexterm > I should definitely have another look though, it's good to know that it is possible to get decent performance out of sixels. Indeed :) It's a format that has been unfairly dismissed. It's old, but we have great tools like libsixel to do anything we want with it in this millenium. Speaking of libsixel, also check https://github.com/libsixel/libsixel https://github.com/libsixel/libsixel a recent fork that's open to PR
dinedal 5y ago
The rant is a much better read and insight into the reason for this: https://github.com/csdvrx/sixel-tmux/blob/main/RANTS.md https://github.com/csdvrx/sixel-tmux/blob/main/RANTS.md
- echelon 5y ago
  This is such a good read. I hope this person goes far and gets wider support for this. I really like their project and their motivation. > Sorry guys, but I don't want you to hold Linux terminal users hostage for your petty concerns over what is the "right" way to do something like sixels. [...] It's something that has been done successfully for over 30 years. ... > Still, you could successfully block sixel support by having control over the terminal emulators or the libraries. Ok, but now, try to prevent your users from running sixel-tmux! ... > Also, you guys like to say that the only voices that matters are from those who can code? Hmm, ok for that too. Let's see how you like the code I release to show the pointlessness of your petty fights, and free your users from your questionable decisions. Also, I wasn't familiar with the term "sixel". They've been around since DEC introduced them in the 80's: https://en.wikipedia.org/wiki/Sixel https://en.wikipedia.org/wiki/Sixel
  - speeddemon 5y ago
    >This is such a good read. I really like their project and their motivation. I can't agree. Like most rants, I found it to be very needlessly emotional, lacking in the technical department, and motivating towards the wrong goal (trying to fight and argue with maintainers, accusing them of negative things like "holding users hostage", etc) rather than doing the right thing for users (delivering new and useful features in a way that isn't broken). I wish open source programmers would make less rants and emotionally-driven forks, it's not helpful to someone like me who just wants to get something new like images in their terminal. The issues in the GNOME/WT bug trackers are what actually contain technical information. And just from looking at that, it appears there is an open development branch for VTE that contains sixel support: https://gitlab.gnome.org/GNOME/vte/-/issues/253 https://gitlab.gnome.org/GNOME/vte/-/issues/253 So if you use GNOME, I would say just use that and work on that, the quality is going to be better than the degraded functionality you get from de-rasterizing. In my opinion, it would be better from a technical standpoint if the author just wanted to work on that, or wanted to work on getting it implemented proper in WT. The degraded-image approach used by this tmux fork is unusable for the cited use case of getting nice graphs in the terminal, and I can't see how it's going to make it any easier for those other terminals to solve the real technical issues with sixel. Edit: I also want to respond to this comment in the rant: >What will happen as Wayland replaces X? Nothing? XTerm still works. But there is also a Wayland-native terminal called "Foot" that supports sixel, if that's your thing: https://codeberg.org/dnkl/foot https://codeberg.org/dnkl/foot 2nd edit: To those downvoting, please reply to me instead of doing that. If you disagree with me it would be better to know why so I could potentially change my view, a downvote communicates nothing of value towards changing my mind.
Lio 5y ago
This is really interesting (to me anyway). I normally just default to using Gnome Terminal on Linux, which sadly doesn't support Sixels, so I'll definitely give this a go. Looking around I've just found Foot, which looks like it does support Sixel on Wayland[1]. So that might be a more permanent way forward. 1. https://codeberg.org/dnkl/foot https://codeberg.org/dnkl/foot
- easygenes 5y ago
  Any insight into how this one compares to Alacritty and Kitty?
  - _2paq 5y ago
    > Any insight into how this one compares to Alacritty and Kitty? In terms of customization and configuration, I'd say foot falls between Alacritty and Kitty with Kitty being the most customizable and configurable while Alacritty being the least. One of the things I really like about Alacritty and foot is that they don't enforce italic and bold monospace variants while Kitty does. I despise italic variants of monospace fonts. Most monospace fonts don't even have proper italic variants. They're just slanted. I tried using foot a few days ago but went back to Alacritty because of this issue. https://codeberg.org/dnkl/foot/issues/628 https://codeberg.org/dnkl/foot/issues/628 I think I might move back to foot though because it felt a bit faster (lesser latency) and for some reason, text on Alacritty is sometimes blurry for me.
    - trapnii 5y ago
      Hey; what do you mean by "force"? I mean, to me this reads like you don't want to see italic nor bold font in the terminal (due to lag of monospace support in that regard maybe). But I think having the possibility of italic, bold, bold+italic in the TE is a very good thing. And if you do not want that I think Kitty allows you to just use another font then; please correct me here, but I think that is configurable. Bold text in the TE world is yet another heated discussion. Some people like it bold, some people like the color to be intensified instead when using `SGR 1` (which is responsible for making font intensified/bold).
eatonphil 5y ago
On a tangent, it would be awesome to have tmux for Windows Terminal without WSL (i.e. a native windows app). I've remapped Windows Terminal shortcuts to be like tmux bindings which gets me closer but it's still not the same.
- mkhnews 5y ago
  tmux in mintty ?
  - eatonphil 5y ago
    Yeah that's an option but I can't stand Cygwin UX. tmux and mosh for native Windows would both be awesome.
    - csdvrx 5y ago
      Try sixel-tmux compiled with msys2 in Windows-Terminal: https://github.com/csdvrx/sixel-tmux/blob/main/tmux.exe https://github.com/csdvrx/sixel-tmux/blob/main/tmux.exe Or compile it yourself using MinGW64 : after installing from msys2.org, pacman -S base-devel etc It works fine here. I have a Windows Terminal settings to start sixel-tmux instead of bash, using script to provide a pty: just have the command line be: C:/msys64/usr/bin/env.exe MSYS=winsymlinks:nativestrict MSYSTEM=MSYS /usr/bin/script -c /usr/bin/tmux /dev/null
      - rashil2000 5y ago
        Wow, I'd been dying to make tmux work on WT. I couldn't get your tmux.exe executable to work (it froze WT, in both bash and cmd). However, the script method works!
        csdvrx 5y ago
        I thought you might be having this issue, which is why I tried to be very explicit. It's due to a cygwin and how /dev/cons* are different from /dev/pty* cf https://cygwin.com/pipermail/cygwin/2020-May/244878.html https://cygwin.com/pipermail/cygwin/2020-May/244878.html I've tried to explain that a bit better in server-client.c (check line 251) to give the user a clue of what's happening with *cause = xstrdup(c->ttyname) Unfortunately, even in 2021, properly configuring a terminal can be complicated. That's why sixel-tmux page has a step-by-step configuration guide, and why I often provide config files in other projects like https://github.com/csdvrx/indent-rainbow https://github.com/csdvrx/indent-rainbow : if needed, check https://github.com/csdvrx/indent-rainbow/blob/main/config/windows-terminal.json https://github.com/csdvrx/indent-rainbow/blob/main/config/wi... even if I need to update it that should give you a good base to start tweaking from. I strongly encourage you to check your configuration with the steps suggest on the sixel-tmux page, or at least the minimal set of steps shown in http://github.com/csdvrx/sixel-testsuite http://github.com/csdvrx/sixel-testsuite (which I should update to show how font change should work, with sixels being resize to be kept in perfect alignment with the text, as done in mintty, as several people seem to believe it's a sixel limitation)
ganzuul 5y ago
This is lovely. The author recommended XTerm as one of the best, so I would like to suggest trying Kitty for size for graphics.
- saladuh 5y ago
  The issue with Kitty is that its graphics protocol is not widespread yet, so some of the CLI/terminal programs OP uses that can do graphics output may only support sixel. But yea, personally looking forward to Foot terminal implementing one of the fancier graphics protocols, even if it feels more like a toy at the moment (until they are used more). But seriously running the notcurses[0] graphics test with a terminal supporting the kitty graphics protocol is sex, just like the program itself says. [0] https://github.com/dankamongmen/notcurses https://github.com/dankamongmen/notcurses
  - csdvrx 5y ago
    > it feels more like a toy at the moment It's not! Gnuplot in the terminal open many new use cases, such as examining data on remote hosts with scripts without even bothering to scp the data first. Also, Notebooks in the terminal is wonderful! Check https://github.com/koppa/matplotlib-sixel https://github.com/koppa/matplotlib-sixel As for kitty format, adding support in sixel-tmux is planned, but you are welcome to write a patch if you want it sooner! Imagine sixel-tmux as some middleware, because it is totally possible to intercept sixel sequences and rewrite them on the fly into something more palatable to kitty or iTerm. This way, even if gnuplot doesn't support kitty, you could still view the results. If it's done well enough, you may not even perceive the difference! That's the direction I want to follow, so that users can take any software and play with it on their terminal regardless of the underlying format.
    - kzrdude 5y ago
      A matplotlib backend isn't even needed, just a cool piece of info, it's possible to extend ipython and/or jupyter console to display pngs and svgs with sixels (and/or kitty graphics, dynamically). I have code lying around for this.
chaganated 5y ago
Sixel is a terrible encoding. Most of the newer terminals have escape sequences for sending base64 encoded png/gif/jpg--for higher quality output & lower bandwidth.
- csdvrx 5y ago
  > Sixel is a terrible encoding This is not based on technical facts, but bias against an old format. > png/gif/jpg--for higher quality output & lower bandwidth For bandwidth, my ssh stream is compressed. For quality, I can't see difference in a 24 bit bitmap when comparing with a png or jpg, unless I compress them too much, in which case the compression artifacts start playing AGAINST the formats you recommend.
  - chaganated 5y ago
    it is self-evident to anyone who knows how sixel works. gif is no prize--yet still manages to be a more efficient encoding than sixel.
- NonEUCitizen 5y ago
  Which terminals support "escape sequences for sending base64 encoded png/gif/jpg" ? Thanks.
  - chaganated 5y ago
    kitty, iterm2, mintty, mlterm, rlogin, wezterm...
  - kzrdude 5y ago
    Kitty, iterm2, wezterm and a few others that support iterm2's protocol. At least PNG.
cyberge99 5y ago
For macos users using iTerm2, installing the integration provides ‘imgcat’ and ‘imgls’. Not sure about tmux support though.
- csdvrx 5y ago
  I have plans to add support for iTerm format, but I'm not a Mac user, while of the work should not be on the derasterize part (image -> unicode text: easy), but on the passthrough part (when to abandon the image). If you are a Mac user, could you please consider writing a patch? The ability to dogfood it means whatever you write will still be better than whatever I may come up with.
saladuh 5y ago
OP, your rants are pretty subjective and imo come from a place of windows fanboy-ism (before someone reports this comment for flame baiting, go read both of OP's rants in the repo, they're far worse). I came to Linux last year, and I've been on it 100% no windows during this entire period. I'm using Sway (Wayland), a DE (well, really just a window manager) you cannot replicate in the windows graphical environment, and I'd never go back. Everything is so smooth, and of course you may say that it's "because vsync is used in Sway and vsync = bad blah blah", but I've never agreed with that and a good implementation of vsync with minimal latency increases is worth it, especially paired with freesync/adaptive sync (which works on the desktop just as it does in Windows). Fyi, before my Linux days, I was a very competitive gamer, and absolute windows power user. I went out of my way to get every last bit of performance and latency reduction possible (just so you know where I'm coming from). My terminal emulator is Foot, a wayland native terminal with a focus on TUI performance, especially in TUI editors like (neo)vim (my editor of choice). It has amazing Sixel support with a developer who goes out of his way to fix even the smallest imperfections with the implementation. Foot has features I really love, like link following by keyboard shortcuts, great font fallback customisation, and no bloat (a feature in my book) My multi-resolution setup is not impacted by Linux because Sway, and Wayland ecosystem in general, handles multi resolution tremendously, and supports integer and fractional scaling per display. Multi display freesync/adaptive-sync (and gsync whenever Nvidia starts playing ball) works great too, just as it does on windows. The majority of stuff you complain about is due to crusty old X11 (whether you're stuck on X because of nvidia or not, it's not a fair argument). Or because you think the way Windows does something is better than the way Linux does that thing (even though in most cases I think the opposite, clearly a subjective thing). Oh, and yea I think Windows sucks and Linux does <insert> better. But I'm saying that as a zoomer, not a "geek millennial" (as you said in your rant) :)
- _2paq 5y ago
  I'll probably regret writing this but if you read the entire rant, the author had been trying get sixel support into VTE based terminals (GNOME terminal and family) but he was blocked, which isn't really surprising considering the "my way or the highway" approach of GNOME devs towards anything that they make. The recent theming fiasco is a good example for this. He also tried getting sixel support in tmux but was rejected again. All he did was make a hard fork to get the feature that he wanted. That's it. The end. There are some things that Windows does better and some things that Linux does better. Generalizing your anecdotal experience and implying that one is entirely "better" than the other is what fundamentalism and fanaticism looks like.
leotaku 5y ago
This is a really cool project. It's unfortunate to see the author being this obviously frustrated by having Sixel-related contributions be rejected time and time again. However it seems like the main Tmux maintainer has shown up on the issue tracker about being open to including the changes upstream, maybe that will improve their faith in the open-source community.
seg_lol 5y ago
Your rant and the issues around keeping an ecosystem pinned to a mess of incompatible tech reminds me of the time that mpng support was pulled/not merged into Firefox because it added too size of the binary. Which was then obviated by the first download of an animated gif. Petabytes in bandwidth and disk storage wasted because FF decided saving a couple hundred K on the png animation code. By not supporting sixels, it forces people to use a whole browser to show images. Graphics support in the terminal is more than just QoL for the users, it is also a power savings and a hardware lifetime issue. You are fighting the good fight.
- csdvrx 5y ago
  > Petabytes in bandwidth and disk storage wasted because FF decided saving a couple hundred K on the png animation code Indeed, penny wise but pound foolish... and I guess they were proud of themselves! > You are fighting the good fight. Thanks, hopefully due to kicking the ant nest with my rants and now sixel-tmux, VTE will be forced to deliver something, anything really, even if it may be 6 years too late and not enabled by default (!!) At least Linux distributions would have the possibility to compile it in? But at this point, even that I can't believe. I think they will weasel out at the last minute with some half-baked more or less plausible excuse, like your example about firefox code increasing by a few kb. My hopes for gnome are extremely low, so "I'll believe it when I can see it" and not before, say when it's shipping in Ubuntu.
v-yadli 5y ago
I appreciate the work and wish the best for @csdvrx, with my emotions and the dream for better UX for the years to come.

161 points by csdvrx 5y ago

marginalia_nu 5y ago

The world is finally catching up with the capabilities of TempleOS.

KaiserPro 5y ago

Ooo I didn't even know that Sixel was a thing. This looks fun

flohofwoe 5y ago
I tinkered a bit with sixel support for my "C64 emulator in the terminal" (https://github.com/floooh/docker-c64 https://github.com/floooh/docker-c64), but unfortunately it's way too slow to get anywhere near 'realtime' output (30fps or better). Here's the (abandondend) sixel-version source code, only with two colors, more color planes would drastically reduce the performance. https://github.com/floooh/chips-test/blob/master/examples/ascii/c64-sixel.c https://github.com/floooh/chips-test/blob/master/examples/as... I really wish there was a decent pixel-framebuffer standard for terminals (with at least the same performance as ncurses). This would allow a lot of fun "terminal applications" (e.g. everything that used to run in VGA Mode 13h).
- csdvrx 5y ago
  > unfortunately it's way too slow to get anywhere near 'realtime' output (30fps or better). That's not due to sixels. Check out the sixel nyan cat: https://github.com/hackerb9/sixvid https://github.com/hackerb9/sixvid Look at the FPS indicator in the bottom. It was pointed to me in https://github.com/microsoft/Terminal/issues/448#issuecomment-928717530 https://github.com/microsoft/Terminal/issues/448#issuecommen... The issue may be in your code. I think I have similar performance issues, as the glyph selection process could be more optimized. Derasterized is mostly Jart work (who is best known here for her work on Cosmopolitan), we were mostly interested in quality. Reducing the set of glyph to something that could benefit from optimizations could help. > I really wish there was a decent pixel-framebuffer standard for terminals (with at least the same performance as ncurses) Sixel performance is quite decent: personally, I can play videos in my terminal. Try MPV on mintty: https://github.com/mpv-player/mpv/issues/2183 https://github.com/mpv-player/mpv/issues/2183 I have also played with a X server rendering over sixel, no performance issue: https://github.com/saitoha/xserver-SIXEL https://github.com/saitoha/xserver-SIXEL When sixel support is added to Windows Terminal, I may update it, because it would be fun to have one tab to run stuff!
  - flohofwoe 5y ago
    Wow interesting, thanks for the links! I still suspect it's a performance issue in the terminal(s) I tested (mainly iTerm2 on Mac, and probably Ubuntu's vanilla terminal), because it would take a lot of effort to make encoding a 320x200 framebuffer to sixels slow ;) I should definitely have another look though, it's good to know that it is possible to get decent performance out of sixels.
    - csdvrx 5y ago
      > Wow interesting, thanks for the links! Indeed! It's nice to see what's possible! As for video playback, while it may not be realistic with the current sixel-tmux due to the size of the search space, it may be possible once the new 1FBxx block https://en.wikipedia.org/wiki/Symbols_for_Legacy_Computing https://en.wikipedia.org/wiki/Symbols_for_Legacy_Computing is integrated into derasterize and the suggested fonts: restricting ourselves to the 1FB0x-1FB3x subset would only require adjudicating about 64 characters. Some very basic programming tricks (a bloom filter after binarization of the input, memoizing...) may be sufficient to derasterize sixel videos in real time, even on an average system. > I still suspect it's a performance issue in the terminal(s) I tested If you don't use Windows, try xterm and mlterm. For xterm, I maintain a set of config files giving you a decent out-of-the box experience, cutexterm > I should definitely have another look though, it's good to know that it is possible to get decent performance out of sixels. Indeed :) It's a format that has been unfairly dismissed. It's old, but we have great tools like libsixel to do anything we want with it in this millenium. Speaking of libsixel, also check https://github.com/libsixel/libsixel https://github.com/libsixel/libsixel a recent fork that's open to PR

dinedal 5y ago

The rant is a much better read and insight into the reason for this: https://github.com/csdvrx/sixel-tmux/blob/main/RANTS.md https://github.com/csdvrx/sixel-tmux/blob/main/RANTS.md

echelon 5y ago
This is such a good read. I hope this person goes far and gets wider support for this. I really like their project and their motivation. > Sorry guys, but I don't want you to hold Linux terminal users hostage for your petty concerns over what is the "right" way to do something like sixels. [...] It's something that has been done successfully for over 30 years. ... > Still, you could successfully block sixel support by having control over the terminal emulators or the libraries. Ok, but now, try to prevent your users from running sixel-tmux! ... > Also, you guys like to say that the only voices that matters are from those who can code? Hmm, ok for that too. Let's see how you like the code I release to show the pointlessness of your petty fights, and free your users from your questionable decisions. Also, I wasn't familiar with the term "sixel". They've been around since DEC introduced them in the 80's: https://en.wikipedia.org/wiki/Sixel https://en.wikipedia.org/wiki/Sixel
- speeddemon 5y ago
  >This is such a good read. I really like their project and their motivation. I can't agree. Like most rants, I found it to be very needlessly emotional, lacking in the technical department, and motivating towards the wrong goal (trying to fight and argue with maintainers, accusing them of negative things like "holding users hostage", etc) rather than doing the right thing for users (delivering new and useful features in a way that isn't broken). I wish open source programmers would make less rants and emotionally-driven forks, it's not helpful to someone like me who just wants to get something new like images in their terminal. The issues in the GNOME/WT bug trackers are what actually contain technical information. And just from looking at that, it appears there is an open development branch for VTE that contains sixel support: https://gitlab.gnome.org/GNOME/vte/-/issues/253 https://gitlab.gnome.org/GNOME/vte/-/issues/253 So if you use GNOME, I would say just use that and work on that, the quality is going to be better than the degraded functionality you get from de-rasterizing. In my opinion, it would be better from a technical standpoint if the author just wanted to work on that, or wanted to work on getting it implemented proper in WT. The degraded-image approach used by this tmux fork is unusable for the cited use case of getting nice graphs in the terminal, and I can't see how it's going to make it any easier for those other terminals to solve the real technical issues with sixel. Edit: I also want to respond to this comment in the rant: >What will happen as Wayland replaces X? Nothing? XTerm still works. But there is also a Wayland-native terminal called "Foot" that supports sixel, if that's your thing: https://codeberg.org/dnkl/foot https://codeberg.org/dnkl/foot 2nd edit: To those downvoting, please reply to me instead of doing that. If you disagree with me it would be better to know why so I could potentially change my view, a downvote communicates nothing of value towards changing my mind.

Lio 5y ago

This is really interesting (to me anyway). I normally just default to using Gnome Terminal on Linux, which sadly doesn't support Sixels, so I'll definitely give this a go. Looking around I've just found Foot, which looks like it does support Sixel on Wayland[1]. So that might be a more permanent way forward. 1. https://codeberg.org/dnkl/foot https://codeberg.org/dnkl/foot

easygenes 5y ago
Any insight into how this one compares to Alacritty and Kitty?
- _2paq 5y ago
  > Any insight into how this one compares to Alacritty and Kitty? In terms of customization and configuration, I'd say foot falls between Alacritty and Kitty with Kitty being the most customizable and configurable while Alacritty being the least. One of the things I really like about Alacritty and foot is that they don't enforce italic and bold monospace variants while Kitty does. I despise italic variants of monospace fonts. Most monospace fonts don't even have proper italic variants. They're just slanted. I tried using foot a few days ago but went back to Alacritty because of this issue. https://codeberg.org/dnkl/foot/issues/628 https://codeberg.org/dnkl/foot/issues/628 I think I might move back to foot though because it felt a bit faster (lesser latency) and for some reason, text on Alacritty is sometimes blurry for me.
  - trapnii 5y ago
    Hey; what do you mean by "force"? I mean, to me this reads like you don't want to see italic nor bold font in the terminal (due to lag of monospace support in that regard maybe). But I think having the possibility of italic, bold, bold+italic in the TE is a very good thing. And if you do not want that I think Kitty allows you to just use another font then; please correct me here, but I think that is configurable. Bold text in the TE world is yet another heated discussion. Some people like it bold, some people like the color to be intensified instead when using `SGR 1` (which is responsible for making font intensified/bold).

eatonphil 5y ago

On a tangent, it would be awesome to have tmux for Windows Terminal without WSL (i.e. a native windows app). I've remapped Windows Terminal shortcuts to be like tmux bindings which gets me closer but it's still not the same.

mkhnews 5y ago
tmux in mintty ?
- eatonphil 5y ago
  Yeah that's an option but I can't stand Cygwin UX. tmux and mosh for native Windows would both be awesome.
  - csdvrx 5y ago
    Try sixel-tmux compiled with msys2 in Windows-Terminal: https://github.com/csdvrx/sixel-tmux/blob/main/tmux.exe https://github.com/csdvrx/sixel-tmux/blob/main/tmux.exe Or compile it yourself using MinGW64 : after installing from msys2.org, pacman -S base-devel etc It works fine here. I have a Windows Terminal settings to start sixel-tmux instead of bash, using script to provide a pty: just have the command line be: C:/msys64/usr/bin/env.exe MSYS=winsymlinks:nativestrict MSYSTEM=MSYS /usr/bin/script -c /usr/bin/tmux /dev/null
    - rashil2000 5y ago
      Wow, I'd been dying to make tmux work on WT. I couldn't get your tmux.exe executable to work (it froze WT, in both bash and cmd). However, the script method works!
      - csdvrx 5y ago
        I thought you might be having this issue, which is why I tried to be very explicit. It's due to a cygwin and how /dev/cons* are different from /dev/pty* cf https://cygwin.com/pipermail/cygwin/2020-May/244878.html https://cygwin.com/pipermail/cygwin/2020-May/244878.html I've tried to explain that a bit better in server-client.c (check line 251) to give the user a clue of what's happening with *cause = xstrdup(c->ttyname) Unfortunately, even in 2021, properly configuring a terminal can be complicated. That's why sixel-tmux page has a step-by-step configuration guide, and why I often provide config files in other projects like https://github.com/csdvrx/indent-rainbow https://github.com/csdvrx/indent-rainbow : if needed, check https://github.com/csdvrx/indent-rainbow/blob/main/config/windows-terminal.json https://github.com/csdvrx/indent-rainbow/blob/main/config/wi... even if I need to update it that should give you a good base to start tweaking from. I strongly encourage you to check your configuration with the steps suggest on the sixel-tmux page, or at least the minimal set of steps shown in http://github.com/csdvrx/sixel-testsuite http://github.com/csdvrx/sixel-testsuite (which I should update to show how font change should work, with sixels being resize to be kept in perfect alignment with the text, as done in mintty, as several people seem to believe it's a sixel limitation)

ganzuul 5y ago

This is lovely. The author recommended XTerm as one of the best, so I would like to suggest trying Kitty for size for graphics.

saladuh 5y ago
The issue with Kitty is that its graphics protocol is not widespread yet, so some of the CLI/terminal programs OP uses that can do graphics output may only support sixel. But yea, personally looking forward to Foot terminal implementing one of the fancier graphics protocols, even if it feels more like a toy at the moment (until they are used more). But seriously running the notcurses[0] graphics test with a terminal supporting the kitty graphics protocol is sex, just like the program itself says. [0] https://github.com/dankamongmen/notcurses https://github.com/dankamongmen/notcurses
- csdvrx 5y ago
  > it feels more like a toy at the moment It's not! Gnuplot in the terminal open many new use cases, such as examining data on remote hosts with scripts without even bothering to scp the data first. Also, Notebooks in the terminal is wonderful! Check https://github.com/koppa/matplotlib-sixel https://github.com/koppa/matplotlib-sixel As for kitty format, adding support in sixel-tmux is planned, but you are welcome to write a patch if you want it sooner! Imagine sixel-tmux as some middleware, because it is totally possible to intercept sixel sequences and rewrite them on the fly into something more palatable to kitty or iTerm. This way, even if gnuplot doesn't support kitty, you could still view the results. If it's done well enough, you may not even perceive the difference! That's the direction I want to follow, so that users can take any software and play with it on their terminal regardless of the underlying format.
  - kzrdude 5y ago
    A matplotlib backend isn't even needed, just a cool piece of info, it's possible to extend ipython and/or jupyter console to display pngs and svgs with sixels (and/or kitty graphics, dynamically). I have code lying around for this.

chaganated 5y ago

Sixel is a terrible encoding. Most of the newer terminals have escape sequences for sending base64 encoded png/gif/jpg--for higher quality output & lower bandwidth.

csdvrx 5y ago
> Sixel is a terrible encoding This is not based on technical facts, but bias against an old format. > png/gif/jpg--for higher quality output & lower bandwidth For bandwidth, my ssh stream is compressed. For quality, I can't see difference in a 24 bit bitmap when comparing with a png or jpg, unless I compress them too much, in which case the compression artifacts start playing AGAINST the formats you recommend.
- chaganated 5y ago
  it is self-evident to anyone who knows how sixel works. gif is no prize--yet still manages to be a more efficient encoding than sixel.
NonEUCitizen 5y ago
Which terminals support "escape sequences for sending base64 encoded png/gif/jpg" ? Thanks.
- chaganated 5y ago
  kitty, iterm2, mintty, mlterm, rlogin, wezterm...
- kzrdude 5y ago
  Kitty, iterm2, wezterm and a few others that support iterm2's protocol. At least PNG.

cyberge99 5y ago

For macos users using iTerm2, installing the integration provides ‘imgcat’ and ‘imgls’. Not sure about tmux support though.

csdvrx 5y ago
I have plans to add support for iTerm format, but I'm not a Mac user, while of the work should not be on the derasterize part (image -> unicode text: easy), but on the passthrough part (when to abandon the image). If you are a Mac user, could you please consider writing a patch? The ability to dogfood it means whatever you write will still be better than whatever I may come up with.

saladuh 5y ago

OP, your rants are pretty subjective and imo come from a place of windows fanboy-ism (before someone reports this comment for flame baiting, go read both of OP's rants in the repo, they're far worse). I came to Linux last year, and I've been on it 100% no windows during this entire period. I'm using Sway (Wayland), a DE (well, really just a window manager) you cannot replicate in the windows graphical environment, and I'd never go back. Everything is so smooth, and of course you may say that it's "because vsync is used in Sway and vsync = bad blah blah", but I've never agreed with that and a good implementation of vsync with minimal latency increases is worth it, especially paired with freesync/adaptive sync (which works on the desktop just as it does in Windows). Fyi, before my Linux days, I was a very competitive gamer, and absolute windows power user. I went out of my way to get every last bit of performance and latency reduction possible (just so you know where I'm coming from). My terminal emulator is Foot, a wayland native terminal with a focus on TUI performance, especially in TUI editors like (neo)vim (my editor of choice). It has amazing Sixel support with a developer who goes out of his way to fix even the smallest imperfections with the implementation. Foot has features I really love, like link following by keyboard shortcuts, great font fallback customisation, and no bloat (a feature in my book) My multi-resolution setup is not impacted by Linux because Sway, and Wayland ecosystem in general, handles multi resolution tremendously, and supports integer and fractional scaling per display. Multi display freesync/adaptive-sync (and gsync whenever Nvidia starts playing ball) works great too, just as it does on windows. The majority of stuff you complain about is due to crusty old X11 (whether you're stuck on X because of nvidia or not, it's not a fair argument). Or because you think the way Windows does something is better than the way Linux does that thing (even though in most cases I think the opposite, clearly a subjective thing). Oh, and yea I think Windows sucks and Linux does <insert> better. But I'm saying that as a zoomer, not a "geek millennial" (as you said in your rant) :)

_2paq 5y ago
I'll probably regret writing this but if you read the entire rant, the author had been trying get sixel support into VTE based terminals (GNOME terminal and family) but he was blocked, which isn't really surprising considering the "my way or the highway" approach of GNOME devs towards anything that they make. The recent theming fiasco is a good example for this. He also tried getting sixel support in tmux but was rejected again. All he did was make a hard fork to get the feature that he wanted. That's it. The end. There are some things that Windows does better and some things that Linux does better. Generalizing your anecdotal experience and implying that one is entirely "better" than the other is what fundamentalism and fanaticism looks like.

leotaku 5y ago

This is a really cool project. It's unfortunate to see the author being this obviously frustrated by having Sixel-related contributions be rejected time and time again. However it seems like the main Tmux maintainer has shown up on the issue tracker about being open to including the changes upstream, maybe that will improve their faith in the open-source community.

seg_lol 5y ago

Your rant and the issues around keeping an ecosystem pinned to a mess of incompatible tech reminds me of the time that mpng support was pulled/not merged into Firefox because it added too size of the binary. Which was then obviated by the first download of an animated gif. Petabytes in bandwidth and disk storage wasted because FF decided saving a couple hundred K on the png animation code. By not supporting sixels, it forces people to use a whole browser to show images. Graphics support in the terminal is more than just QoL for the users, it is also a power savings and a hardware lifetime issue. You are fighting the good fight.

csdvrx 5y ago
> Petabytes in bandwidth and disk storage wasted because FF decided saving a couple hundred K on the png animation code Indeed, penny wise but pound foolish... and I guess they were proud of themselves! > You are fighting the good fight. Thanks, hopefully due to kicking the ant nest with my rants and now sixel-tmux, VTE will be forced to deliver something, anything really, even if it may be 6 years too late and not enabled by default (!!) At least Linux distributions would have the possibility to compile it in? But at this point, even that I can't believe. I think they will weasel out at the last minute with some half-baked more or less plausible excuse, like your example about firefox code increasing by a few kb. My hopes for gnome are extremely low, so "I'll believe it when I can see it" and not before, say when it's shipping in Ubuntu.

v-yadli 5y ago

I appreciate the work and wish the best for @csdvrx, with my emotions and the dream for better UX for the years to come.