grass

grass copied to clipboard

• Adds support for using ANSI escape sequences to add color to the shell.
• All shells now have an identical prompt:
• Tested with bash, zsh, tcsh, csh, ksh on Ubuntu 20.04

I'm happy to see this! I'm surprised by the individual color settings in the command line parameters. I guess you would create an alias since this is for interactive use anyway, but I haven't seen it before. I usually see things like --color, --auto-color, and --no-color. This could be read from a JSON config in the config dir if needed (the (previously only) GUI config is already read in grass.py for the locales, so it could be use here as well).

I wanted to give the user control over the colors since terminal color schemes and settings are so varied. But defaults should maybe be something we can use. I could convert the --monochrome flag to a --no-color :thinking:

I was thinking of reading / writing to some config, but wanted to get the prompts set first, and then in a separate PR add the config, but I can add it to this one as well. I like the idea of a separate color config! :+1: I'll start taking a look at how I could best structure a color JSON.

I think the per-item color options would unnecessarily increase the number of parameters (esp. now when there are no subcommands). A config file, a separate one or combined with GUI, is the way to go.

On 8/15/2022 6:13 PM, Vaclav Petras wrote:

I think the per-item color options would unnecessarily increase the number of parameters (esp. now when there are no subcommands). A config file, a separate one or combined with GUI, is the way to go.

You are free to do as you wish, but I believe that is an arcane way of looking at things. Fashion and usability are far more important to users than we give credit. A little judicious eye candy in the name of usability to cue users isn't a bad thing. Whether this meets that criteria may be something to consider?

I, personally, would use it as I'm accustom to CLI (it would relieve a bit of eye strain), but I suspect many would not know the option even exists.

Message ID: @.***>

-- Best Regards, -Brad

...Fashion and usability are far more important to users than we give credit...I, personally, would use it...

Agreed and I would/will use it too. I think that should be the default. (We already detect tty anyway and consider it interactive, so it makes sense to link "color on" to it as a default.)

Maybe I was not clear, I mean that we should not have a parameter for every item which has color. That's what a config file should handle.

I wrote my second comment to clarify that I think these parameters should not really be there at all, even as a temporary or an additional solution.

I think we can have both. Personally (I'm very CLI oriented) I don't want to edit a config file if I can simply use a flag once. I'm planning to make it so that whatever flags are given, it will save it to the config file, much like --text or --gui flags work.

I could also rename the --monochrome flag to something else if it feels clunky. Maybe a bool flag --color / --no-color but I strongly believe that we should do color on by default to show that there is color (have some reasonable defaults, like the ones Markus used), and also tell the user that they can turn off the color with the --no-color flag.

A GUI would be nice, but that I'll leave as an exercise for someone else. :stuck_out_tongue:

Config from command line should be edited using a separate subcommand. We are unfortunately not using subcommands yet, but my experiments suggested, we can introduce them while keeping the current interface. I'm not saying that should be part of this PR.

Something like (see, e.g., Git):

grass config set shell.mapset_color red
grass

Or for now:

vi ~/.grass8/wx.json
grass

A compromise could be:

grass --color='{"mapset_color": "red", "location_color": "red"}'

Or:

grass shell --color='{"mapset_color": "red", "location_color": "red"}'

Ugly, but one option, parsed as JSON, and you anyway set that only once.

Default should be colors. The shell is interactive.

Definitively no need to have a GUI for this.

I like the idea of sub commands, very much like e.g. the Google cloud CLI works, or as you say, git.

However the color parsing is not going to be that easy, since each color is 3 components (all optional, but I made the style mandatory): style, foreground color, background color and any value that you don't set is inherited.

So the JSON will have to look something like this

{
  "mapset": {
    "style": "bold",
    "fg": "cyan",
    "bg": "yellow"
  }
}

So I propose we keep the flags as I've implemented it for now*, and then when we convert to a sub command we can simply change it to be a sub command like this, becuse functionally it's about equal. And remember if you're happy with the defaults, no need to specify any color at all.

grass config set shell.mapset_color --style bold --fg cyan --bg yellow

*) I will rename --monochrome to --no-color

What about trying to follow this convention https://no-color.org

Python library Termcolor already supports it.