Hi Prot,
I've come across some contrast issues while playing around with `term'
(in the context of `eshell', but that's irrelevant here). The tl;dr is
that the `term-color-*' variables are all set to the same colour for
their foreground and background:
`(term-color-black ((,c :background "gray35" :foreground "gray35")))
`(term-color-blue ((,c :background ,blue :foreground ,blue)))
`(term-color-cyan ((,c :background ,cyan :foreground ,cyan)))
`(term-color-green ((,c :background ,green :foreground ,green)))
`(term-color-magenta ((,c :background ,magenta :foreground ,magenta)))
`(term-color-red ((,c :background ,red :foreground ,red)))
`(term-color-white ((,c :background "gray65" :foreground "gray65")))
`(term-color-yellow ((,c :background ,yellow :foreground ,yellow)))
I'm not sure if this is due to some other use-case/reason that I'm not
aware of. In either case, this can result in hard to read text; for
example:
https://i.imgur.com/nZsh00N.png
Notice the blue background in the bottom left corner. Here's a
reproducer:
1. Basic environment: $ emacs -Q --eval "(load-theme 'modus-operandi)"
2. Start `term': M-x term RET
In a second prompt, `term' asks you to choose a shell. To make sure
no user options are at play here, I opted for `/bin/sh' (this is
dash for me).
3. Do something that involves a pager: git add --help
4. Notice that the temp file name in the bottom left has a very dark
blue background, making the text almost—or, depending on the
monitor, completely—illegible.
Upon pressing any key, the title will vanish. However, one can also
search for something, which uses the same face: / This RET
This "problem" seems to be entirely contained within Emacs (i.e., it's
not some program hardcoding something), as with
(modus-themes-with-colors
(set-face-attribute
'term-color-blue
nil
:background bg-blue-subtle :foreground blue))
; ^^^^^^^^^^^^^^
the text is already much more legible.
Tony
--
Tony Zorman | https://tony-zorman.com/
> From: Tony Zorman <tonyzorman@mailbox.org>> Date: Sun, 6 Aug 2023 12:28:52 +0200>> Hi Prot,
Hello Tony,
> I've come across some contrast issues while playing around with `term'> (in the context of `eshell', but that's irrelevant here). The tl;dr is> that the `term-color-*' variables are all set to the same colour for> their foreground and background:>> `(term-color-black ((,c :background "gray35" :foreground "gray35")))> `(term-color-blue ((,c :background ,blue :foreground ,blue)))> `(term-color-cyan ((,c :background ,cyan :foreground ,cyan)))> `(term-color-green ((,c :background ,green :foreground ,green)))> `(term-color-magenta ((,c :background ,magenta :foreground ,magenta)))> `(term-color-red ((,c :background ,red :foreground ,red)))> `(term-color-white ((,c :background "gray65" :foreground "gray65")))> `(term-color-yellow ((,c :background ,yellow :foreground ,yellow)))>> I'm not sure if this is due to some other use-case/reason that I'm not> aware of. In either case, this can result in hard to read text; for> example:>> https://i.imgur.com/nZsh00N.png>> Notice the blue background in the bottom left corner. Here's a> reproducer:> [... 31 lines elided]
Yes, this is a bug and your suggested change makes sense to me.
I don't know why terminal faces use the same value for background and
foreground, though this is the default. See ansi-color.el from where
term.el gets its colours. Vterm does the same, by virtue of inheriting
from term.el.
Maybe we should ask on the Emacs bug tracker? Just to be sure that a
change on our end does not break things. Which ones? I have no idea...
All the best,
Prot
--
Protesilaos Stavrou
https://protesilaos.com
On Wed, Aug 09 2023 09:53, Protesilaos Stavrou wrote:
> Maybe we should ask on the Emacs bug tracker? Just to be sure that a> change on our end does not break things. Which ones? I have no idea...
Just as a backlink, here is the relevant discussion on Emacs devel:
https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg00242.html
The core lessons are
(i) I'm an idiot and forgot that I had some user-specific
configuration in my ~/.profile that instructed man to use blue
as a background colour. The default man/pager colours are black
and white; quite readable. However, since anyone can send these
escape codes, the colour combinations shown is not unthinkable,
and probably still happens with a different reproducer.
(ii) Using the same colour for the fore- and background seems to be a
tradition, more or less. Every terminal emulator does it, but
there is no standard that says you _have_ to do it.
(iii) I maintain the position that one can't guarantee foreground
colours to provide good contrast when used as background
colours. Thus, I think it's still worth "breaking" the
convention of (ii) and using different fore- and background
colours here.
Tony
--
Tony Zorman | https://tony-zorman.com/
> From: Tony Zorman <tonyzorman@mailbox.org>> Date: Thu, 10 Aug 2023 06:57:28 +0200>> On Wed, Aug 09 2023 09:53, Protesilaos Stavrou wrote:>> Maybe we should ask on the Emacs bug tracker? Just to be sure that a>> change on our end does not break things. Which ones? I have no idea...>> Just as a backlink, here is the relevant discussion on Emacs devel:>> https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg00242.html
I followed along, thank you!
> The core lessons are>> (i) I'm an idiot and forgot that I had some user-specific> configuration in my ~/.profile that instructed man to use blue> as a background colour. The default man/pager colours are black> and white; quite readable. However, since anyone can send these> escape codes, the colour combinations shown is not unthinkable,> and probably still happens with a different reproducer.
No worries!
> (ii) Using the same colour for the fore- and background seems to be a> tradition, more or less. Every terminal emulator does it, but> there is no standard that says you _have_ to do it.
It is and it is wrong in the current era. I can understand the time
when we were limited to 8/16 colours and had to use the same value both
for background and foreground purposes. But now this limitation is out
of place: we can have values that work nicely as backgrounds and others
for colouring text.
> (iii) I maintain the position that one can't guarantee foreground> colours to provide good contrast when used as background> colours. Thus, I think it's still worth "breaking" the> convention of (ii) and using different fore- and background> colours here.
I agree. Though I cannot anticipate the implications of this change. I
thus suggest semantic colour mappings along the lines of 'bg-term-red',
fg-term-red', and so on for green, yellow, blue, magenta, cyan, black,
white. Then the user can change those to their liking. What do you
think?
--
Protesilaos Stavrou
https://protesilaos.com
On Thu, Aug 10 2023 08:40, Protesilaos Stavrou wrote:
>> From: Tony Zorman <tonyzorman@mailbox.org>>> [… 32 lines elided …]>>> (iii) I maintain the position that one can't guarantee foreground>> colours to provide good contrast when used as background>> colours. Thus, I think it's still worth "breaking" the>> convention of (ii) and using different fore- and background>> colours here.>> I agree. Though I cannot anticipate the implications of this change. I> thus suggest semantic colour mappings along the lines of 'bg-term-red',> fg-term-red', and so on for green, yellow, blue, magenta, cyan, black,> white. Then the user can change those to their liking. What do you> think?
Sounds good to me! I suppose this is exactly the kind of thing that the
semantic mappings were made to handle.
--
Tony Zorman | https://tony-zorman.com/
> From: Tony Zorman <tonyzorman@mailbox.org>> Date: Thu, 10 Aug 2023 08:50:28 +0200> [... 18 lines elided]> Sounds good to me! I suppose this is exactly the kind of thing that the> semantic mappings were made to handle.
I just made the change. Please let me know if everything works on your
end.
--
Protesilaos Stavrou
https://protesilaos.com
On Thu, Aug 10 2023 12:44, Protesilaos Stavrou wrote:
> I just made the change. Please let me know if everything works on your> end.
Yup, everything works beautifully. Thanks!
--
Tony Zorman | https://tony-zorman.com/
> From: Tony Zorman <tonyzorman@mailbox.org>> Date: Thu, 10 Aug 2023 13:24:46 +0200>> On Thu, Aug 10 2023 12:44, Protesilaos Stavrou wrote:>> I just made the change. Please let me know if everything works on your>> end.>> Yup, everything works beautifully. Thanks!
You are welcome!
--
Protesilaos Stavrou
https://protesilaos.com
> Vterm does the same, by virtue of inheriting from term.el
vterm-mode is currently lacking the possibility to specify different
colors for for background and foreground purposes, since it uses
:background attribute of its faces for "bright" ANSI color indices
(8-15) and :foreground is used for "normal" ANSI colors (0-7).
I have just submitted a PR [1] to vterm to add this functionality as it
has been bugging me for a long time and modus-themes now have the
mechanism to customize it.
[1] https://github.com/akermu/emacs-libvterm/pull/685
> From: Illia Ostapyshyn <ilya.ostapyshyn@gmail.com>> Date: Thu, 21 Sep 2023 15:45:41 +0200>>> Vterm does the same, by virtue of inheriting from term.el>> vterm-mode is currently lacking the possibility to specify different >> colors for for background and foreground purposes, since it uses >> :background attribute of its faces for "bright" ANSI color indices >> (8-15) and :foreground is used for "normal" ANSI colors (0-7).>> I have just submitted a PR [1] to vterm to add this functionality as it > has been bugging me for a long time and modus-themes now have the > mechanism to customize it.>> [1] https://github.com/akermu/emacs-libvterm/pull/685
Thank you Ilia! I commented there.
--
Protesilaos Stavrou
https://protesilaos.com
