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

Colorize Your CLI

danyspin97.org

Post reply on HN
Print view View original

91–100 of 124 posts

Re: Colorize Your CLI

#91

Post by a1369209993 »

dleslie wrote: post #85

Colorizing is a red herring; it's akin to syntax highlighting: it's nice, but if you need it to determine important information then something's amiss. I'd much prefer consistent and predictable information conveyance. Ie, I don't need Midnight Commander to be lit up like a christmas tree because I know immediately what information is displayed in its tables and panes.

> but if you need it to determine important information then something's amiss.

Not untrue, but define "need"; as eg [0] points out, distinctive colors make it much easier to notice things. (On the other hand, TFA seems to be advocating precisely the kind of syntax-based ice-cream-sprinkle-soup coloring that makes it harder to notice things, so not exactly the most convincing presentation there.)

0: https://buttondown.email/hillelwayne/archive/syntax-highligh... 0 dicussed: https://news.ycombinator.com/item?id=23902124

Re: Colorize Your CLI

#93

Post by dleslie »

a1369209993 wrote: post #91
dleslie wrote: post #85

Colorizing is a red herring; it's akin to syntax highlighting: it's nice, but if you need it to determine important information then something's amiss. I'd much prefer consistent and predictable information conveyance. Ie, I don't need Midnight Commander to be lit up like a christmas tree because I know immediately what information is displayed in its tables and panes.

> but if you need it to determine important information then something's amiss. Not untrue, but define "need"; as eg [0] points out, distinctive colors make it much easier to notice things. (On the other hand, TFA seems to be advocating precisely the kind of syntax-based ice-cream-sprinkle-soup coloring that makes it harder to notice things, so not exactly the most convincing presentation there.) 0: https://buttondow…

Colour is a bad tool, even if it is an effective tool; a not-insignificant portion of the population has difficulties with colour. Then there's that not all displays render the same, and not all editors colourize the same. Syntax and layout are superior.

Re: Colorize Your CLI

#94

Post by a1369209993 »

dleslie wrote: post #93
a1369209993 wrote: post #91

Earlier quoted context omitted.

> but if you need it to determine important information then something's amiss. Not untrue, but define "need"; as eg [0] points out, distinctive colors make it much easier to notice things. (On the other hand, TFA seems to be advocating precisely the kind of syntax-based ice-cream-sprinkle-soup coloring that makes it harder to notice things, so not exactly the most convincing presentation there.) 0: https://buttondow…

Colour is a bad tool, even if it is an effective tool; a not-insignificant portion of the population has difficulties with colour. Then there's that not all displays render the same, and not all editors colourize the same. Syntax and layout are superior.

I am immensely opposed to the notion that something being difficult or even wholely unusable for a "not-insignificant portion of the population" makes it a bad tool, rather than merely a situational one to which alternatives are also necessary[0]. The same reasoning, applied to the not-insignificant portions of the population with more severe disabilities than color-blindness, would condemn very nearly every tool in the history of technological civilization.

0: And in this case - as you yourself have pointed out - happily available.

Re: Colorize Your CLI

#95

Post by Morgangeek »

IggleSniggle wrote: post #12

One of the biggest upgrades from using fish is syntax highlighting / autocompletion. You can get fish-style syntax highlighting and autocomplete in zsh (which has the advantage of being more interoperable with bash generally): [zsh-syntax-highlighting]( https://github.com/zsh-users/zsh-syntax-highlighting ) [zsh-autosuggestions]( https://github.com/zsh-users/zsh-autosuggestions ) Poster mentioned "modern alternatives…

I've also aliased cat to bat but it causes me issues when I redirect the output of cat (bat) without \cat to a file as then the file contains color codes that are not expected by other users and tools and cause some tools to not behave correctly,while the issue is invisible to me (unless reading the generated file with \cat)

Re: Colorize Your CLI

#96

Post by tvb12 »

Tade0 wrote: post #30

Somewhat related: My friend is developing a colour palette based on Solarized: https://github.com/jan-warchol/selenized but with more perceptual uniformity.

It looks like he's only doing the dark mode. I wonder what selenized-light would look like.

Re: Colorize Your CLI

#97

Post by digisign »

michaelmure wrote: post #19
mulmen wrote: post #9

Earlier quoted context omitted.

I kinda like using tooling with 40 years of refinement. Is it perfect? No. Do I need to resize a window with a progress bar? No. Would it be nice? Yeah, I guess. Am I underestimating the benefits? Almost certainly. But what are the other sharp edges that come with the shiny new thing? Would it be an electron app? Yes, probably. Would it work? Maybe, in a couple years. There would be some major bugs first, and a lot o…

It looks to me that the reality is closer to "40 years of hack over something that was not meant to be a standard (a popular hardware terminal from the 80s)". I'll give you just one example of the madness that is sometimes required: the escape code \e[1m is doing "bold on". It's counterpart to reset \e[21m, is supposed to do "bold off", but in practice some terminals do "double underline" instead because this standar…

Not entirely. Well there is bold, normal, and dim. Early on someone realized there is no need for unbold and undim codes. So undim, 22 I believe, works for both, setting normal intensity. 21 was then free for something else.

Re: Colorize Your CLI

#98

Post by digisign »

Tade0 wrote: post #30

Somewhat related: My friend is developing a colour palette based on Solarized: https://github.com/jan-warchol/selenized but with more perceptual uniformity.

I like it better but don't understand the desire for a near dark cyan background that each promotes.

Re: Colorize Your CLI

#100

Post by Mikhail_Edoshin »

craftkiller wrote: post #28
mulmen wrote: post #9

Earlier quoted context omitted.

I kinda like using tooling with 40 years of refinement. Is it perfect? No. Do I need to resize a window with a progress bar? No. Would it be nice? Yeah, I guess. Am I underestimating the benefits? Almost certainly. But what are the other sharp edges that come with the shiny new thing? Would it be an electron app? Yes, probably. Would it work? Maybe, in a couple years. There would be some major bugs first, and a lot o…

There still some pretty glaring issues, even after 40 years of refinement. Some I think could be iteratively fixed but not all of them (for example I believe #1 requires a significant breaking change to terminals). 1. You can't have an interactive program in a pipeline. For example, you can't do `gpg --decrypt foo.txt.gpg | nano | gpg --encrypt` because keyboard input on the console is handled through stdin. You can…

1. You can have an interactive program in the pipeline, for example 'less' is usually called this way:

  cat some.file | less
Less reads 'stdin' and then reaches out to the actual console to respond to navigation keys. The console is reachable either via '/dev/tty' (POSIX) or, on Windows, via CreateFile()[1].

But yes, most programming tutorials (and probably many programs) make no distinction between the console and standard streams, hence the confusion. They absolutely should.

[1] https://docs.microsoft.com/en-us/windows/win32/api/fileapi/n...

Post reply on HN