Specify usable escape sequences in Exception#detailed_message#6119
Specify usable escape sequences in Exception#detailed_message#6119mame merged 2 commits intoruby:masterfrom
Conversation
An error message is primarily rendered in a terminal emulator, but is also shown in a browser by converting it to a HTML fragment. However, the conversion would be unreasonably difficult if the message includes any escape sequence (such as cursor move or screen clear). This change adds a guideline about escape sequences in `Exception#detailed_message`: * Use widely-supported escape sequences: bold, underline, and basic eight foreground colors (except white and black). * Make the message readable if all escape sequences are ignored.
ioquatix
left a comment
There was a problem hiding this comment.
Looks good to me! We might also want to clarify whether fixed width rendering is required - i.e. "a detailed message might contain multiple lines which are designed for fixed width presentation" or something to that effect. If terminal color codes were used instead of ^~~ markers, then fixed width wouldn't be needed, so some thinking might be required around whether (1) we want to allow for non-fixed width and (2) if so what cases that it is allowed.
error.c
Outdated
| * - Magenta (+\e[35m+) | ||
| * - Cyan (+\e[36m+) | ||
| * | ||
| * Use escape sequeunces carefully even if +highlight+ is true. |
There was a problem hiding this comment.
s/sequeunces/sequences
|
@ioquatix I talked about this with you in Slack, but for the record... I believe that the current ecosystem is not yet mature to handle attributed error messages. Copying text in the terminal does not preserve attributes such as underline and colors. Pasting attributed text onto each media like GitHub issues, Slack, stackoverflow, etc. yields different results; some attributes are dropped, and others are kept (but often slightly changed). If we use attributed error messages before the ecosystem is improved, I am afraid that more people will start communicating by pasting screenshots of error messages and logs. Unfortunately, it is incompatible with web search. We will not be able to find issues and discussions by web-search. I do never want to steer people in this direction. Instead, I think it's good to stay with the plain old terminal style for the time being. Technically, it is possible to copy and paste attributed text. And we may use OCR to extract text information from screenshots. After copying and pasting an attributed text is standardized and/or OCR is integrated into the ecosystem, we may make more use of attributes. But I think that will still take more than a few years at least. (BTW, I personally think it is more likely that screenshots will be searchable by OCR than many sites support attributed text communication.) |
|
All I asked was whether we should document that fixed width font is required or not… |
|
In addition, if you feel strongly about ascii output, why not have both formatting AND |
An error message is primarily rendered in a terminal emulator, but is
also shown in a browser by converting it to a HTML fragment.
However, the conversion would be unreasonably difficult if the message
includes any escape sequence (such as cursor move or screen clear).
This change adds a guideline about escape sequences in
Exception#detailed_message:eight foreground colors (except white and black).