Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

lsix: ls for images

github.com

Post reply on HN
Print view View original

21–30 of 111 posts

Re: lsix: ls for images

#21

Post by jopsen »

amasad wrote: post #17
jopsen wrote: post #9

How many terminal emulators can handle sixel? (vt340) Does anyone have a list?

As far as I know it's just xterm on desktop. It's fascinating that we have this standard that allows us to build programming environments like notebooks -- without resorting to layering hacks on hacks to make it work on web -- practically crossplatform yet we don't make use of it. At repl.it we've been toying around with adding sixel support for xterm.js and we have a prototype up and people in our community are alre…

It's also facinating that programs that generate text output do so in a format that's well over 40 years old.

What if our CLI programs could output HTML or JSON depending on whether they are piped or printed.

Both standards are not good for this, but is VT100 really that great?

Re: lsix: ls for images

#23

Post by pvg »

hn_throwaway_99 wrote: post #19
pvg wrote: post #8

Earlier quoted context omitted.

ls does not show files starting with .

Yeah, but those files are known as "hidden files". In other words, it is the creators of those files who purposefully prepend them with a . to hide them from ls and other tools. One can argue whether this "starting with a . means hidden" is a hack or not, but I think it's manifestly different than not showing particular file types based on size or something like that. I agree just not showing pdf files by default bec…

The thing I'm getting at is not whether one behaviour or another is 'right' - just that they are both inconsistent so in this case 'consistency' is probably not the right design criterion on which to base this criticism.

Re: lsix: ls for images

#24

Post by Wowfunhappy »

pvg wrote: post #14
binarysaurus wrote: post #10

Earlier quoted context omitted.

But there is a driving purpose behind that, hidden vs non-hidden is binary. With so many media formats I agree that consistency is very important.

It's still largely arbitrary. I'm pushing back against the general notion that standard Unix-y command line tools are some shining example of consistency. Most of it is just us confusing familiarity for consistency.

There are some edge cases, but those cases are well-known and simple to understand.

Re: lsix: ls for images

#25

Post by _emacsomancer_ »

snazz wrote: post #11

Semi-related fun fact: if you have iimage-mode turned on in Emacs (it might be the default on recent versions?), you can just cat images in eshell and have them show up just like this app. Unfortunately it doesn't do sixel graphics in a terminal yet.

I needed to advise eshell/cat (as per https://emacs.stackexchange.com/questions/3432/display-image... ) before I could get this to work.

Re: lsix: ls for images

#27

Post by Wowfunhappy »

jopsen wrote: post #21
amasad wrote: post #17

Earlier quoted context omitted.

As far as I know it's just xterm on desktop. It's fascinating that we have this standard that allows us to build programming environments like notebooks -- without resorting to layering hacks on hacks to make it work on web -- practically crossplatform yet we don't make use of it. At repl.it we've been toying around with adding sixel support for xterm.js and we have a prototype up and people in our community are alre…

It's also facinating that programs that generate text output do so in a format that's well over 40 years old. What if our CLI programs could output HTML or JSON depending on whether they are piped or printed. Both standards are not good for this, but is VT100 really that great?

Most terminals use unicode, not ascii, right? Unicode is much younger than 40.

Re: lsix: ls for images

#28

Post by pvg »

Wowfunhappy wrote: post #24
pvg wrote: post #14

Earlier quoted context omitted.

It's still largely arbitrary. I'm pushing back against the general notion that standard Unix-y command line tools are some shining example of consistency. Most of it is just us confusing familiarity for consistency.

There are some edge cases, but those cases are well-known and simple to understand.

If you haven't run across it before, google up The Unix-Haters Handbook for an entertaining book-length rebuttal.

Re: lsix: ls for images

#29

Post by scarejunba »

userbinator wrote: post #7

You can also specify filenames and, of course, use shell wild cards However, some may be slow to render (like PDF), so lsix doesn't show them unless you ask specifically. Regardless of the justification, I don't think creating such extra exception/edge-case behaviours are ever a good idea in a commandline tool like this. The equivalent in regular ls would be something like not showing more than X files "unless you as…

It doesn't matter. These are smart defaults. Just like ripgrep uses gitignore files by default. It makes my normal use useful.
Post reply on HN