Cyan color preventing `<b>` tag from getting closed correctly about ansi-to-html

[raine]

Just after opening this issue, I realized that flipping the order in which color styles are applied to the header texts fixes the issue. It appears that doing cyan before bold is causing the problem here. Not sure if there still is a bug in ansi-to-html, though.

raine/ramda-cli@487010e

[rburns]

It appears to me that the 22 escaped code may be ignored as the previous opening bold tag is not on the top of the stack. https://github.com/rburns/ansi-to-html/blob/master/src/ansi_to_html.js#L149 https://github.com/rburns/ansi-to-html/blob/master/src/ansi_to_html.js#L299

the trailing close bold tag is on account of closing the remaining tags in the stack.

I've been trying to come up with a small test case which demonstrates that's what's happening. no luck yet.

In general, interpreting 22 as <span style="font-weight: normal"> instead of </b> might be a better approach.

[rburns]

this looks about right.

with the current release

convert.toHtml('\x1b[1m\x1b[36mname\x1b[22m|')

will produce

<b><span style="color:#0AA">name|</span></b>

which leaves the '|' erroneously bold.

Can you test the code on this branch, and see if it gives better results: https://github.com/rburns/ansi-to-html/pull/50/files

[raine]

Thanks @rburns.

Those changes appear to work as well.

With this, I wonder if it would make sense to change the starting <b> to a span element with a bold style.

[rburns]

for consistencies sake, it would probably make sense to use a style attribute instead of a bold tag. But, in the interest of not changing something that works, I'd probably lean towards leaving it as it is.

The relevance of the using the style attribute for 'normal' text is that there isn't a <normal> tag, in the way that there is a <bold> tag. The previous solution used a </bold> tag to emulate <normal>, which is context sensitive, and led to the bug.

Similarly, these https://github.com/rburns/ansi-to-html/blob/master/src/ansi_to_html.js#L150-L151 might better be implemented with font-style and text-decoration css properties.

But, this appears to fix this issue, so I'll merge it before making more changes.