Talk:ANSI escape code

Latest comment: 1 month ago by Tedickey in topic old mailing list posting

inconsistent emulation

edit

An editor's comment about colors versus reverse-video is poorly sourced (the source given provides the reader with no insight) TEDickey (talk) 18:55, 26 April 2023 (UTC)Reply

I believe the text cited in support of the "inconsistent emulation" claim is found in the Display elements subsection on the target page. Unfortunately that subsection is not directly linkable, due to that page's poor HTML-internal structure. –ReadOnlyAccount (talk) 16:38, 29 February 2024 (UTC)Reply
You appear to be talking about the paragraph beginning "Virtual terminal display buffers also encompass a "light/dark background" screen flag", which uses the term only in the sentence "console-termio-realizer handles this flag itself, therefore, for consistency across realized-upon terminals and with other realizers.", following a couple of comments (including some inaccurate) about other programs. That's not a reliable source for the purpose intended in this topic. TEDickey (talk) 19:54, 29 February 2024 (UTC)Reply

Even if the paragraph's source wasn't dubious, I can't fathom how it could be implemented other than as described. If it's saying emulation isn't widely supported, I can't fathom how that could be true, either, as swapping fore- and background colours isn't that difficult if the fore- and background colours can be set. COArSe D1RTxxx (talk) 13:10, 19 April 2025 (UTC)Reply

Changed \\... to '\...'

edit

I changed the strings containing \\ in the "In shell scripting" printf examples to use a single \ inside single quotes, since the latter form is probably more intuitive. Also, it's possible that the unquoted ? in \\e[?5l is interpreted as a glob character (loosely speaking, a wildcard). BMJ-pdx (talk) 19:33, 22 August 2025 (UTC)Reply

Why are escape codes terminated with M?

edit

I was struggling to find an explanation for why C0 escape sequences are terminated with an M, like in `^[0m`. Did that part get left out altogether? I'd read the sources but I admit I don't understand this stuff very well. NomadicVoxel (talk) 19:19, 13 October 2025 (UTC)Reply

The 'm' indicates it is a set-the-color escape sequence. Other letters are used to end other sequences, like A for moving the cursor up. Spitzak (talk) 19:37, 13 October 2025 (UTC)Reply

old mailing list posting

edit

A ten-year-old posting is used to comment on implementation of a feature in terminal emulators, which is (a) old and (b) doesn't really reflect the changes which have been made in ten years. TEDickey (talk) 15:23, 15 November 2025 (UTC)Reply

Fair points. If you disagree with the statement that the semicolon-delimiter is more widely supported, I'll defer to your opinion which is more expert than mine. If you just think that it's a crummy reference for a probably-true statement, I won't disagree.
As a spot check, I grabbed a random Ubuntu install, did an Apt search on "terminal", and installed every one I could find. Of those, the semicolon delimiter worked, but ODA colon-delimiter failed on:
- RXVT (urxvt) v9.30
- Konsole 21.12.3
- Pangoterm (libvterm 0.1.4-1)
- terminalpp 0.6.0
Not a very thorough study, and not a reference, to be sure. Plothound (talk) 04:31, 16 November 2025 (UTC)Reply
The section we're discussing is "24-bit". If it's not mentioned in ncurses terminal database, it's unlikely that I'll agree that a given terminal is "notable". Some entries use semicolon where either colon/semicolon works, because of their respective developer's preference. TEDickey (talk) 11:15, 16 November 2025 (UTC)Reply
urxvt doesn't recognize 24-bit RGB. pangoterm isn't a good example (very buggy, likely few users), and "terminalpp" isn't well-known. konsole (testing colon) works with vttests/256colors2.pl. TEDickey (talk) 11:15, 16 November 2025 (UTC)Reply
Related: your edit also added a "cn" to the statement "ISO 8613-6 does not specify the format of the RGB triple".
The previous sentence has a reference to your NCURSES FAQ that includes the statement

from NCURSES FAQ:

The term “direct colour” has been interpreted as “24-bit mapping of RGB” (it is an interpretation, since the ISO standard referenced is not specific).

And then the FAQ proceeds to quote from the standard. That seems to me like a reasonable citation for the statement that the standard does not specify the format?
If the issue is that the reference isn't cited on that sentence as well- I'm not sure what the convention is for a reference that applies to multiple statements, but that could be fixed up as appropriate. Plothound (talk) 04:43, 16 November 2025 (UTC)Reply
The not-specified in the given source (There is no “24-bit” in the standard) refers to the number of bits used, rather than the subparameter syntax (which is specified in ISO 6429). ISO 6429 doesn't give the meaning of the parameter(s) for SGR 38 and 48, and 8613-3 doesn't give the number of bits. The konsole #107487 in comment #17 explains the difference of xterm #111 versus 8613-3 (and nowhere in the konsole issue is "TrueColor" used -- that's completely nonstandard). TEDickey (talk) 11:15, 16 November 2025 (UTC)Reply
Regarding the other recently-cited source, it doesn't satisfy the requirement in WP:RS: Articles should be based on reliable, independent, published sources with a reputation for fact-checking and accuracy. (some of its information was copied from Wikipedia). So I'd eliminate any mention of "defacto standard" to avoid confusing readers. TEDickey (talk) 11:15, 16 November 2025 (UTC)Reply
Thanks for your comments. I've updated the language / removed "de-facto standard", and added a reference to a GitHub page that appears to maintain a list of supported codes similar to (but more extensive than) that from the mailing list reference. I don't know that the GitHub page has a "reputation for fact-checking and accuracy", but it does seem to be maintained regularly. Plothound (talk) 14:49, 16 November 2025 (UTC)Reply
It's being updated, though technically it's community-edited (like Wikipedia). TEDickey (talk) 17:32, 16 November 2025 (UTC)Reply