In cmd/gq/color.go we add color to output when the target is a terminal.
It colorizes based upon a robust and well documented AST that gets emitted to it, so it would actually probably be relatively easy to replace these with meaningful variable names that get loaded from a config file:
ansiReset = "\x1b[0m"
ansiDim = "\x1b[2m"
ansiGreen = "\x1b[32m"
ansiYellow = "\x1b[33m"
ansiCyan = "\x1b[36m"
ansiBoldCyan = "\x1b[1;36m"
ansiMagenta = "\x1b[35m"
Only 5 of those are colors that would need to be broken out into settings vars and renamed to what they do instead of their color. The reset and dim can continue as constants. We should pick what to do with the bold.
Green is identifier, Yellow is string, Cyan is bool, Magenta is the keyword type and also numbers, BoldCyan is... also identifiers but if they are in a header, I think.
It would be pretty easy to have an optional env var that lets you point to your own theme. We should probably require an absolute path. We could use embed to also pack some themes with the tool. They would be referenced by instead setting the env var to a string staring with a scheme theme like theme://solarized to bypass the absolute path check and instead use the embedded fs.FS of themes.
A theme not existing should not cause the command output to fail. Just do not colorize.
The gq command should have a theme flag which takes the same input as the env var for the theme. It will print a message explaining how to set the theme permanently, listing the themes built in, and then printing some sample data and its schema in the given theme.
The env var should be GQ_THEME.
The theme setting file should be very simple to parse to avoid needing to import any dependencies. For instance, the setting name could be from a line start to an equal sign on that line. and value everything (trimmed) after the equal sign. I'd like to allow comments. Ignore anything after a #. I guess bail if there is a line with no equal sign. For the theme command, it can print an actual error message if something is invalid with the theme as an exception to the rule to just continue on.
In
cmd/gq/color.gowe add color to output when the target is a terminal.It colorizes based upon a robust and well documented AST that gets emitted to it, so it would actually probably be relatively easy to replace these with meaningful variable names that get loaded from a config file:
Only 5 of those are colors that would need to be broken out into settings vars and renamed to what they do instead of their color. The reset and dim can continue as constants. We should pick what to do with the bold.
Green is identifier, Yellow is string, Cyan is bool, Magenta is the keyword type and also numbers, BoldCyan is... also identifiers but if they are in a header, I think.
It would be pretty easy to have an optional env var that lets you point to your own theme. We should probably require an absolute path. We could use embed to also pack some themes with the tool. They would be referenced by instead setting the env var to a string staring with a scheme
themeliketheme://solarizedto bypass the absolute path check and instead use the embedded fs.FS of themes.A theme not existing should not cause the command output to fail. Just do not colorize.
The gq command should have a theme flag which takes the same input as the env var for the theme. It will print a message explaining how to set the theme permanently, listing the themes built in, and then printing some sample data and its schema in the given theme.
The env var should be GQ_THEME.
The theme setting file should be very simple to parse to avoid needing to import any dependencies. For instance, the setting name could be from a line start to an equal sign on that line. and value everything (trimmed) after the equal sign. I'd like to allow comments. Ignore anything after a #. I guess bail if there is a line with no equal sign. For the theme command, it can print an actual error message if something is invalid with the theme as an exception to the rule to just continue on.