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

111–120 of 124 posts

Re: Colorize Your CLI

#111

Post by IggleSniggle »

diego898 wrote: post #110
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…

Thanks for the links! Could you say a bit more about how you use/configure fzf to work in combination with bat and delta?

fzf has a preview pane option. Typical OOTB usage is to use this to cat the output of the currently hovered item in your list. But fzf can fuzzy-find on any list, not just file lists, and use the preview pane to display anything based on your selected inputs. One very nice demonstration of this is [git-fuzzy](https://github.com/bigH/git-fuzzy)

The hardest part about leveraging the power of fzf is getting input into your --preview argument in the middle of some piped process. But that's also where it's true power becomes fully evident.

awk users have long had similar powers. And indeed you might find awk useful for reorganizing record separators in a pipe to fzf. But fzf is brilliant because it "just works" for 90% of cases.

I think we're probably going to see people sharing some pretty incredible workflows with fzf in the next few years. Something about being able to stick it in the middle of a Unix pipe just makes it really really special; it's compose-able!

Re: Colorize Your CLI

#112

Post by WorldMaker »

GhostVII wrote: post #6

I feel like we need a complete rewrite of terminal emulators/bash/whatever. It should be super easy to make a CLI with nice colors, good loading icons, etc. without having to deal with all kinds of color codes and cursor movement. When I press "enter" while a script is showing some progress bar, or resize the terminal window, it should handle it nicely like every other application. I use the command line whenever pos…

I've wondered for a bit why in the Unix philosophy there isn't a standard /dev/progress or something for somewhat unified progress reporting already. It seems something that should be easy to standardize: make it append-only and take maybe a task name and a double [0, 1] (maybe, maybe optionally x of y counts, but a single double should be all you need). Let the terminal, the shell, and/or the GUI figure out how it wants to display things.

All of the major OSes today have some sort of dock/taskbar/activity panel standardized progress reporting API that is basically that simple, seems interesting we haven't pushed that idea back into the terminal. Makes you wonder what other sorts of GUI era pseudo-devices might be useful to add to Unix. In the other direction, imagine if some of these tools had been standardized as real devices in past terminals, like using something fun like an analog meter for progress operations.

Re: Colorize Your CLI

#114

Post by Tade0 »

tvb12 wrote: post #96
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.

It's available for terminals, but it's a work in progress for editors.

Re: Colorize Your CLI

#115

Post by O_H_E »

tvb12 wrote: post #96
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.

Take a look here: https://github.com/jan-warchol/selenized/blob/master/the-val...

Re: Colorize Your CLI

#116

Post by O_H_E »

digisign wrote: post #98
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.

alternate colours based on the same principles here: https://github.com/jan-warchol/selenized/blob/master/the-val...

Re: Colorize Your CLI

#117

Post by a1369209993 »

dleslie wrote: post #108
a1369209993 wrote: post #94

Earlier quoted context omitted.

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 necessary alternatives, in CLI, are consistent and human readable syntax in a consistent and pleasing layout; and those alternatives are generally either present or not. Moreover, they're useful to anyone regardless of their ability, and consistent syntax is easier to automatically colourize. Starting with colourizing is backwards.

At what point did I suggest starting with colorizing? I pointed out that[0] colorizing was sometimes so effective at drawing attention to important information that it was reasonable to describe it as needed, with the implication that coloring should be available in addition to other information channels.

0: for some people, which I perhaps should have explicitly noted, but it really ought to go without saying that no tool is equally effective for everyone.

Re: Colorize Your CLI

#118

Post by dleslie »

a1369209993 wrote: post #117
dleslie wrote: post #108

Earlier quoted context omitted.

The necessary alternatives, in CLI, are consistent and human readable syntax in a consistent and pleasing layout; and those alternatives are generally either present or not. Moreover, they're useful to anyone regardless of their ability, and consistent syntax is easier to automatically colourize. Starting with colourizing is backwards.

At what point did I suggest starting with colorizing? I pointed out that[0] colorizing was sometimes so effective at drawing attention to important information that it was reasonable to describe it as needed, with the implication that coloring should be available in addition to other information channels. 0: for some people, which I perhaps should have explicitly noted, but it really ought to go without saying that n…

You didn't; and neither did I suggest that colorizing was ineffective. It's bad because when using other tools it's unnecessary.

Re: Colorize Your CLI

#119

Post by michaelmure »

spc476 wrote: post #76
michaelmure wrote: post #19

Earlier quoted context omitted.

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…

I hate to say it, but the standard for C1 escape codes, ECMA-48, does list "\e[21m" as "double underline". I can see where one might think it does a "bold off" but alas, that isn't in the standard. The standard also has a lot of redundancy, and some omissions (getting the size, but I think it was standardized long before TTYs were resizable). A standard is a good idea, but I think ECMA-48 was a draft that was put int…

My point exactly. Some terminals do the expected thing of doing "bold off" because that make the mapping of codes regular, some follow ECMA-48 and do "double underline" even if that means that "bold off" is not possible.

At the end, there is no way to reliably do either of them.

Re: Colorize Your CLI

#120

Post by michaelmure »

kjeetgill wrote: post #69
thih9 wrote: post #41

Earlier quoted context omitted.

> fallback to no colors/decoration if the user wish so Fallbacks are frequently not implemented, not tested or not supported as well as the main feature. > Even detecting if the terminal support colors is a pain. As the end user, I don’t mind. This means that I’ll see colors only when it’s important.

I'm with you 100%, virtually nobody will take the time to code against a fallback profile like that. That's why most sites tend not to work without JavaScript regardless of whether their functionality strictly requires it. Support for images concern many of us for that reason: sure it seems nice for a few cases used judiciously. But it feels counter-productive to the strengths of the CLI. I would feel that way about…

From what I've seen it's quite common to use a library to output those escape code. Given that, there is often a flag to disable all those colors/decoration at once without implementing a fallback specifically.

> Support for images concern many of us for that reason: sure it seems nice for a few cases used judiciously. But it feels counter-productive to the strengths of the CLI.

Of course those things should be used judiciously, but building CLI app on a broken standard only make it so much harder to build a quality app. You get a crappy end result just because it's difficult to do the "judiciously" part.

Post reply on HN