Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for the "concealed" graphic rendition attribute #6876

Closed
j4james opened this issue Jul 11, 2020 · 6 comments · Fixed by #6907
Closed

Add support for the "concealed" graphic rendition attribute #6876

j4james opened this issue Jul 11, 2020 · 6 comments · Fixed by #6907
Labels
Area-VT Virtual Terminal sequence support Issue-Task It's a feature request, but it doesn't really need a major design. Priority-2 A description (P2) Product-Conhost For issues in the Console codebase Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Milestone

Comments

@j4james
Copy link
Collaborator

j4james commented Jul 11, 2020

Description of the new feature/enhancement

The ANSI SGR 8 rendition attribute is used to indicate that text to which it's applied should be rendered invisible. I'm not sure how widely it's used, but it is supported by most terminal emulators, so I think it's probably worth doing. And most of the framework is already in place, so it's an easy addition for us.

Proposed technical implementation details (optional)

I think all that's required is an update to the TextAttribute::CalculateRgbColors method, adjusting the colors to make the foreground and background the same when the attribute is set. Something like:

if (IsInvisible())
{
    fg = bg;
}

In testing this on other terminals, I found that XTerm also prevented the invisible content being copied to the clipboard. However, pretty much everyone else allowed it to be copied, so I'm more inclined to follow the majority behaviour.

I have a PR ready to submit for this if you're happy with the idea and the proposed approach, but it'd be best if #6873 is merged first, otherwise there'll probably be conflicts in the unit tests.

@j4james j4james added the Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. label Jul 11, 2020
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Jul 11, 2020
@DHowett
Copy link
Member

DHowett commented Jul 11, 2020

Philosophically, if it's not copyable and not rendered in xterm, is there any meaningful difference between it being concealed and it simply not existing?

For us, matching the colors and leaving it copyable sounds great. I'm r+ on this proposal!

@DHowett DHowett added Area-VT Virtual Terminal sequence support Issue-Task It's a feature request, but it doesn't really need a major design. Priority-2 A description (P2) Product-Conhost For issues in the Console codebase Product-Terminal The new Windows Terminal. and removed Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. labels Jul 11, 2020
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Jul 11, 2020
@DHowett DHowett removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Jul 11, 2020
@DHowett DHowett added this to the Terminal v1.x milestone Jul 11, 2020
@j4james
Copy link
Collaborator Author

j4james commented Jul 11, 2020

Philosophically, if it's not copyable and not rendered in xterm, is there any meaningful difference between it being concealed and it simply not existing?

That depends on the implementation. If they're still writing the text to the buffer, then it could potentially be revealed through other means, e.g. by changing the attributes with DECARA, or reading the content back via DECRQCRA. I couldn't get DECARA to work, but I'm not sure if that's just a bug. And I didn't try DECRQCRA, but I suspect it wouldn't work either - my guess is they're not actually storing anything.

Anyway I don't think it matters much. This is one of those things that doesn't have a clear right answer, because the ANSI/ECMA specs don't go into any detail, and the DEC terminals never had this functionality. I figure as long as we're doing what most others are doing then we're probably OK.

@jdebp
Copy link

jdebp commented Jul 13, 2020

DECCARA is documented as only affecting specific attributes, of which this is not one. But the DEC doco does state that invisibility is rendered by making the foreground colour the same as the background colour.

Observe, furthermore, that kitty extends DECCARA to cover this attribute.

@j4james
Copy link
Collaborator Author

j4james commented Jul 13, 2020

But the DEC doco does state that invisibility is rendered by making the foreground colour the same as the background colour.

That's good to know - thanks for pointing that out. I was under the impression that none of the DEC terminals supported the concealed/invisible attribute, possibly because it's not listed in the functions summary table of the VT520 Programmer Reference. But I see now that even the VT420 supported it.

DECCARA is documented as only affecting specific attributes, of which this is not one.

Yeah I saw that, but I thought (incorrectly) that that was just because they didn't support the concealed attribute in general. I suppose it's still possible that was an oversight in the docs.

Observe, furthermore, that kitty extends DECCARA to cover this attribute.

I thought XTerm did that too (see here), but as I mentioned above I couldn't get it to work. I don't think I tested DECCARA on kitty. Not that it matters much at the moment. We can figure out those details when we actually implement those ops.

@ghost ghost added the In-PR This issue has a related PR label Jul 13, 2020
@ghost ghost closed this as completed in #6907 Jul 14, 2020
@ghost ghost removed the In-PR This issue has a related PR label Jul 14, 2020
ghost pushed a commit that referenced this issue Jul 14, 2020
## Summary of the Pull Request

This PR adds support for the `SGR 8` and `SGR 28` escape sequences,
which enable and disable the _concealed/invisible_ graphic rendition
attribute. When a character is output with this attribute set, it is
rendered with the same foreground and background colors, so the text is
essentially invisible.

## PR Checklist
* [x] Closes #6876
* [x] CLA signed. 
* [x] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. Issue number
  where discussion took place: #6876

## Detailed Description of the Pull Request / Additional comments

Most of the framework for this attribute was already implemented, so it
was just a matter of updating the `TextAttribute::CalculateRgbColors`
method to make the foreground the same as the background when the
_Invisible_ flag was set. Note that this has to happen after the
_Reverse Video_ attribute is applied, so if you have white-on-black text
that is reversed and invisible, it should be all white, rather than all
black.

## Validation Steps Performed

There were already existing SGR unit tests covering this attribute in
the `ScreenBufferTests`, and the `VtRendererTest`. But I've added to the
`AdapterTest` which verifies the SGR sequences for setting and resetting
the attribute, and I've extended the `TextAttributeTests` to verify that
the color calculations return the correct values when the attribute is
set.

I've also manually confirmed that we now render the _concealed text_
values correctly in the _ISO 6429_ tests in Vttest. And I've manually
tested the output of _concealed_ when combined with other attributes,
and made sure that we're matching the behaviour of most other terminals.
@ghost ghost added the Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. label Jul 14, 2020
@ghost
Copy link

ghost commented Jul 22, 2020

🎉This issue was addressed in #6907, which has now been successfully released as Windows Terminal Preview v1.2.2022.0.:tada:

Handy links:

@DHowett
Copy link
Member

DHowett commented Aug 21, 2020

🎉 As of Windows Insider build 20197, this is also supported in the traditional console.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-VT Virtual Terminal sequence support Issue-Task It's a feature request, but it doesn't really need a major design. Priority-2 A description (P2) Product-Conhost For issues in the Console codebase Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants