Remove redundant g-AnsiDefault from formatted console output

[blairconrad]

From https://github.com/mosra/m.css/pull/151#issuecomment-640871837. @mosra noted

Btw., one thing I noticed in the "ground truth" output:

<span class="g g-AnsiDefault" style="background-color: #5f00d7"> (And then repeated several times for all the colors.) Isn't the g g-AnsiDefault redundant in this case? I didn't look close enough to see if this is really an explicitly specified default in the input (in which case I'd say it's okay), but if not then I think it isn't needed. Or is this a nested override of something defined above and thus it needs to be there?

The g g-AnsiDefault classes can be considered redundant. They do give the end user a customization option whereby they can change the default foreground colour, but they're inconsistently applied. Sections of output without any ANSI SGR codes won't have this annotation, only ones with codes that affect the background colour. It probably does make sense keep from emitting the classes, making the g-AnsiDefault and g-AnsiBackgroundDefault CSS rules useless. g-AnsiBrightDefault is still useful.

[blairconrad]

@mosra, I'm struggling with 2 questions:

1. css/pygments-console.py appears to be provided so users can use it to generate new .css files? I did not update it in my last change, although I did update css/pygments-console.css.
2. related to this, the token names emitted by the lexer are referenced in this file as well as in comments in some .css files. This gives me pause because I mangled the token types in my last change, so now things like Generic.AnsiBrightRedBackgroundColorBlue are emitted, and they are not covered by the .py, which will only apply to tokens with a modified non-RGB, non-palette foreground colour, and default background colour. If you expect anything but HtmlAnsiFormatter to consume the output of AnsiLexer, the previous change may confound those consumers.

I'd originally come to these questions because after suppressing the g-AnsiDefault class, I struck upon what was to my mind an improvement to the lexer/formatter pair, but it changed the tokens emitted by the lexer. Then I saw the token names referenced. I can easily not make the "improvement", but now I'm worried about the current state of the code. The richer highlighting required a more flexible token "language" emitted by the lexer, which will not be easily consumed by others.

If you're not worried about other consumers, I'll carry on, and can update css/pygments-console with at least the named background colors…

[mosra]

1. ah, yes. the css file is generated by Pygments from the py file. A guide how to do that is here (adapt paths to your system): https://mcss.mosra.cz/mcss/css/themes/#modifying-the-pygments-higlighting-style . So you'd need to "inversely" update the py and let Pygments generate the css from that, which should then result in the exact same file if everything goes well. I was actually a bit confused about the mismatch between the two files when checking the diff, now I see why :)

2. "as well as in comments in some .css files" -- can you tell me where? the pygments-*.css files are (or used to be) completely generated from the py, so whatever comments are in there are made by Pygments, not by a human. I can't find references to those anywhere else tho.

To be clear, the only consumer of the g-AnsiWhatever CSS classes is the ansilexer HTML formatter, so as long as ansilexer.py, pygments-console.py pygments-console.css are consistent, it's okay. In addition, the original pygments-console.py contains Pygments token names like Generic.Prompt for highlighting the prompt in generic shell session output (if you do .. code:: shell-session it highlights the prompt and the output differently such as here) and I imagine there are other similar builtin token names, which is why I want to preserve the original py file.

[blairconrad]

Thanks, @mosra. I've restored and updated the pygments-console.py appropriately and proceed with the rest of the work. I was sad I couldn't trick pygmentize into loading the file from anywhere but under site-libs, but what can you do? Copying works fine.

as well as in comments in some .css files" -- can you tell me where?

Turns out it was pygments-console.css. Things like

.m-console .g-AnsiBlack { color: #232627 } /* Generic.AnsiBlack */

So I worried for nothing. PR coming in another day or two.

[mosra]

I was sad I couldn't trick pygmentize into loading the file from anywhere but under site-libs, but what can you do?

Yeah that bothers me also :/ Fortunately this isn't something one would have do very often, otherwise I would be looking into submitting a patch to Pygments to allow that.

Thanks for the PR!

[mosra]

Fixed by #158 :tada: