GNOME Bugzilla – Bug 779817
Attributes of inserted blank character
Last modified: 2021-06-10 15:19:31 UTC
Emit the "CSI num @" (insert blank character(s)) escape sequence with nondefault current attributes. E.g.: echo -e '\e[4;7;9;33;44mAB\e[D\e[@' This prints "A B" where the space between is inserted by this escape sequence. VTE's behavior: The inserted character gets all the attributes (fg+bg colors; bold, underline, inverse, strikethrough) of the current context, that is, the same as the A and B letters in our example. xterm and most other emulators: The inserted character gets the fg+bg colors of the current context, but not the non-color attributes, those are all switched off. (The fg color can be seen if you highlight the cell with the mouse. The bold attribute (or lack thereof) can be seen if you enable bold (1) but not reverse (7) and then highlight with mouse: in xterm the background becomes the non-bright variant of the color, as opposed to the surrounding cells. I'm lazy to test the hardly ever used dim (aka half) attribute. I've no clue how to test italic and other attributes, they probably don't matter at all, and I think it's fair to assume that all the non-color attributes are handled the same way.) (I discovered this bug while wondering whether inserted characters should be hyperlinked in the feature request at bug 779734.)
I think VTE's current behavior makes sense. Notable variations: # Reset formatting before moving and inserting the space echo -e '\e[4;7;9;33;44mAB\e[m\e[D\e[@' # Reset formatting after moving but before inserting the space echo -e '\e[4;7;9;33;44mAB\e[m\e[D\e[@' Both of these insert the space with no formatting. That seems correct to me. Formatting of "inserted" characters should depend only on the current state, not on any existing properties of the location you move to.
(In reply to Josh Triplett from comment #1) > echo -e '\e[4;7;9;33;44mAB\e[m\e[D\e[@' You forgot to actually adjust these examples :D > Formatting of "inserted" characters should depend only on the current state, > not on any existing properties of the location you move to. This is obvious, the disagreement is not here. The question is whether underlined etc. status of the current state matters or is ignored (pretended to be off). I don't think xterm's behavior makes any sense, though.
(In reply to Egmont Koblinger from comment #2) > (In reply to Josh Triplett from comment #1) > > > echo -e '\e[4;7;9;33;44mAB\e[m\e[D\e[@' > > You forgot to actually adjust these examples :D Oops, yes, the second one should have had: echo -e '\e[4;7;9;33;44mAB\e[D\e[m\e[@' > > Formatting of "inserted" characters should depend only on the current state, > > not on any existing properties of the location you move to. > > This is obvious, the disagreement is not here. The question is whether > underlined etc. status of the current state matters or is ignored (pretended > to be off). When I said that 'formatting of "inserted" characters should depend only on the current state', I intended that to include all aspects of formatting, including underlining, bold, hyperlinking, etc. I don't think it makes sense for cursor motion commands to reset that state.
(In reply to Josh Triplett from comment #3) > When I said that 'formatting of "inserted" characters should depend only on > the current state', I intended that to include all aspects of formatting, > including underlining, bold, hyperlinking, etc. This is what vte does. I agree with you that xterm is the stupid one by taking the colors but not the other attributes. Maybe it just correctly emulates an ancient hardware terminal that had this stupid behavior. So "stupid" is not necessarily the same as "incorrect". > I don't think it makes sense for cursor motion commands to reset that state. It sure wouldn't make sense, and they don't do it. Cursor motion is utterly irrelevant here. It's only the character insertion "\e[@" that we're talking about. It's a truly minor issue, and I'm inclined to leave vte unchanged until this deviation from xterm actually causes a real-life issue. As for hyperlinks, I'd do whatever we do with the other non-color attributes, whether or not we've addressed this issue by then.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2379.