Hi everyone,
I am forwarding this email by Prot (which was a reply to an email I had sent to his personal address) in order to gather users’ opinions on `mu4e-header-face’.
Protesilaos Stavrou <public@protesilaos.com> writes:
>> From: Edgar Vincent <e-v@posteo.net>>> Date: Sat, 7 Jan 2023 13:54:47 +0000>>>> Hi Prot,>> Hello Edgar,>>> As mentioned in the code I quoted in the email I sent to the>> modus-themes mailing list, I believe that the default value for>> `mu4e-header-face’ in version 4 of the Modus themes does not provide>> enough contrast and thus makes mu4e message headers difficult to read.>>>> You’ll find attached two pairs of screenshots, one of Modus operandi,>> the other of Modus vivendi, both before and after the following>> change:>>>> ┌────>> │ (modus-themes-with-colors>> │ (custom-set-faces>> │ ;; `(mu4e-header-face ((,c :inherit shadow))) ; original value>> │ `(mu4e-header-face ((,c :foreground ,fg-main)))>> │ ))>> └────>> I checked some older versions. The “:inherit shadow” seems to have been> there for a long time. I can find it in commit e02480f from 2021-12-24> (version 2.0.0). It probably is older than that, though this gives you> an idea. I am hesitant to change it the way you suggest due to how long> it has been this way. This is the first time this issue is brought up> and I believe Mu4e is a fairly popular package. I am open to further> feedback though: if other Mu4e users are reading this, please let me> know what you think. Personally, I am fine with the change to> ’fg-main’.>>> I also find `mu4e-header-highlight-face’ to be too colourful (and thus>> distracting), and I now use `bg-inactive’ for it instead of the>> original `highlight’, but that is a matter of personal preference and>> I don’t think your choice of `highlight’ is problematic per se.>> This is my mistake. Sorry! I will make it look the same as that of> ’hl-line-mode’. Will do it as soon as I send out this message.>>> Please tell me if I’m wrong, but it seems to me that the new version>> of the Modus themes is more colourful than the previous one. I would>> have preferred them to remain rather bland, especially now that the>> tinted variants exist but again, this is simply a matter of personal>> preference and I don’t think it contradicts the themes’ main Geist.>> If there are other places where it is more colourful, please let me> know. The only case I can think of that is intentional is the> completions’ selected line, which no longer has a grey background. It> is not grey because of the problem with “invisible” greys that I told> you about in the other thread.>
[…]
Following up on this:
I have found two faces which I deem too colourful (again this is just my opinion and not necessarily a request
for the faces to be changed upstream):
• modus-operandi’s bg-hl-line. Although the colour is quite dim, I find it a little too distracting, and would
prefer a light shade of grey. hl-line should of course be an indication of which is the line the point is on,
but the focus should first and foremost be on the text itself.
• more importantly, the background of org source blocks after running org-edit-src-code, which inherits from
the secondary-selection face is way too colourful, to the point where, when using modus-vivendi,
the text is unreadable. I do not really understand what second-selection is, so I don’t know if its colour is appropriate
elsewhere.
About mu4e:
I don’t know why, but since the last updates, I have encountered several bugs in mu4e’s appearance. They may or
may not be caused by Doom Emacs.
• with modus-operandi, the background of mu4e-header-highlight face is #303030, which makes the text under it
barely readable. According to mu4e’s code (and your latest updates to modus-themes), it is supposed to inherit from hl-line,
which I think is sensible. I don’t understand why it isn’t being applied.
• with modus-vivendi, mu4e-header-face’s background is #FFFFFF, while mu4e-replied-face is #000000, as it should be.
• not a bug per se and not very important, but the text which is specific to marked messages (for example “-> delete”) appears in green in
both modus-vivendi and modus-operandi. I am not sure this is caused by modus-themes - could anyone confirm?
With modus-themes 3, the marks appear in #8f0075, which I think is
nicer, because it makes the marks stand out more.
Thanks!
Edgar
Good day Edgar,
> From: Edgar Vincent <e-v@posteo.net>> Date: Wed, 11 Jan 2023 17:18:49 +0000>> Following up on this:>> I have found two faces which I deem too colourful (again this is just> my opinion and not necessarily a request for the faces to be changed> upstream):>> • modus-operandi’s bg-hl-line. Although the colour is quite dim, I> find it a little too distracting, and would prefer a light shade of> grey. hl-line should of course be an indication of which is the line> the point is on, but the focus should first and foremost be on the> text itself.
I also like a subtle style for hl-line when editing text. Actually, I
don't like a line highlight at all: I only want it for interfaces where
"selection" or "navigation" is the primary interaction.
That granted, I made background a bit more noticeable because the old
style of a default light grey was problematic in some cases:
* The light grey was not discernible at all given certain lighting or
hardware setups.
* The highlighted line would not be visible beside or around anything
that had a grey background, like with:
(setq modus-themes-org-blocks 'gray-background)
* Those who do not use my 'lin' package found hl-line-mode to be hard to
use for selection/navigation purposes because it did not stand out.
The compromise, then, is to slightly amplify the value and shift it away
from a neutral grey. It has a bit of blue to it.
I think this is a case where it is impossible to have a default that
works for everyone and/or in every case. There are different needs for
a "line highlight" that cannot be reconciled. This is why I wrote 'lin'.
> • more importantly, the background of org source blocks after running> org-edit-src-code, which inherits from the secondary-selection face is> way too colourful, to the point where, when using modus-vivendi, the> text is unreadable. I do not really understand what second-selection> is, so I don’t know if its colour is appropriate elsewhere.
This is an Org problem because it hardcodes the 'secondary-selection'
instead of providing a face that I could customise. You can find this
by placing the point over the colourised block and doing 'M-x
describe-char' (or type 'C-u C-x =' with the default key bindings). In
the resulting Help buffer, it mentions the applicable face.
I don't have time to patch Org but my suggestion is to (i) create a new
face, such as 'org-block-edited-indirect', (ii) make it inherit from
'secondary-selection' for backward compatibility, (iii) apply it to
function 'org-src--make-source-overlay'.
If I have this, I will just grey out the block the same way, say, the
inactive buttons are in M-x customize.
What do you think?
Generally, the 'secondary-selection' is used in places where it needs to
stand out, including Org's date selection indicator that is beside the
minibuffer prompt or that appears after you reschedule an item in the
Org agenda.
The Org code still has cases of bringing in the 'secondary-selection'
beside what I mentioned above. Just read the doc string of
'org-clock-overlay' for an example.
> About mu4e: I don’t know why, but since the last updates, I have> encountered several bugs in mu4e’s appearance. They may or may not be> caused by Doom Emacs.>> • with modus-operandi, the background of mu4e-header-highlight face is> #303030, which makes the text under it barely readable. According to> mu4e’s code (and your latest updates to modus-themes), it is supposed> to inherit from hl-line, which I think is sensible. I don’t understand> why it isn’t being applied.>> • with modus-vivendi, mu4e-header-face’s background is #FFFFFF, while> mu4e-replied-face is #000000, as it should be.>> • not a bug per se and not very important, but the text which is> specific to marked messages (for example “-> delete”) appears in green> in both modus-vivendi and modus-operandi. I am not sure this is caused> by modus-themes - could anyone confirm? With modus-themes 3, the> marks appear in #8f0075, which I think is nicer, because it makes the> marks stand out more.
It seems like another theme is enabled as well. What is the return
value of 'custom-enabled-themes'?
All the best,
Prot
--
Protesilaos Stavrou
https://protesilaos.com
> From: Protesilaos Stavrou <info@protesilaos.com>> Date: Thu, 12 Jan 2023 06:56:11 +0200> [... 43 lines elided]>> • more importantly, the background of org source blocks after running>> org-edit-src-code, which inherits from the secondary-selection face is>> way too colourful, to the point where, when using modus-vivendi, the>> text is unreadable. I do not really understand what second-selection>> is, so I don’t know if its colour is appropriate elsewhere.>> This is an Org problem because it hardcodes the 'secondary-selection'> instead of providing a face that I could customise. You can find this> by placing the point over the colourised block and doing 'M-x> describe-char' (or type 'C-u C-x =' with the default key bindings). In> the resulting Help buffer, it mentions the applicable face.>> I don't have time to patch Org but my suggestion is to (i) create a new> face, such as 'org-block-edited-indirect', (ii) make it inherit from> 'secondary-selection' for backward compatibility, (iii) apply it to> function 'org-src--make-source-overlay'.>> If I have this, I will just grey out the block the same way, say, the> inactive buttons are in M-x customize.>> What do you think?>> Generally, the 'secondary-selection' is used in places where it needs to> stand out, including Org's date selection indicator that is beside the> minibuffer prompt or that appears after you reschedule an item in the> Org agenda.>> The Org code still has cases of bringing in the 'secondary-selection'> beside what I mentioned above. Just read the doc string of> 'org-clock-overlay' for an example.
What I wrote above stands: we need more refined faces. Though note that
I made an update to modus-theme.el to always override the foreground of
'highlight' and 'secondary-selection' in the interest of legibility.
The commit:
commit 6afb2448d27f26bc73ac7472833280de9c01268e
Author: Protesilaos Stavrou <info@protesilaos.com>
Date: Thu Jan 12 07:03:56 2023 +0200
Enforce foreground for 'highlight', 'secondary-selection'
This should have always been there to avoid awkward colour
combinations. I realised it was missing after corresponding with
Edgar Vincent on a relevant topic:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C878ri95h1q.fsf%40posteo.net%3E#%3C87ilhc7usc.fsf@posteo.net%3E>.
modus-themes.el | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
Protesilaos Stavrou
https://protesilaos.com
#+OPTIONS: html-postamble:nil H:5 num:nil ^:{} toc:nil author:nil email:nil tex:dvipng d:nil
#+STARTUP: hidestars indent inlineimages
:PROPERTIES:
:reply-to: nil
:attachment: nil
:alternatives: (utf-8)
:END:
Hi Prot!
Protesilaos Stavrou <info@protesilaos.com> writes:
[...]
> I also like a subtle style for hl-line when editing text. Actually, I> don't like a line highlight at all: I only want it for interfaces where> "selection" or "navigation" is the primary interaction.>> That granted, I made background a bit more noticeable because the old> style of a default light grey was problematic in some cases:>> * The light grey was not discernible at all given certain lighting or> hardware setups.>> * The highlighted line would not be visible beside or around anything> that had a grey background, like with:>> (setq modus-themes-org-blocks 'gray-background)>> * Those who do not use my 'lin' package found hl-line-mode to be hard to> use for selection/navigation purposes because it did not stand out.>> The compromise, then, is to slightly amplify the value and shift it away> from a neutral grey. It has a bit of blue to it.>> I think this is a case where it is impossible to have a default that> works for everyone and/or in every case. There are different needs for> a "line highlight" that cannot be reconciled. This is why I wrote 'lin'.
You had mentioned that in the case of the modeline face too. I should have remembered.
I understand your argument, which does make sense indeed.
>> • more importantly, the background of org source blocks after running>> org-edit-src-code, which inherits from the secondary-selection face is>> way too colourful, to the point where, when using modus-vivendi, the>> text is unreadable. I do not really understand what second-selection>> is, so I don’t know if its colour is appropriate elsewhere.>> This is an Org problem because it hardcodes the 'secondary-selection'> instead of providing a face that I could customise. You can find this> by placing the point over the colourised block and doing 'M-x> describe-char' (or type 'C-u C-x =' with the default key bindings). In> the resulting Help buffer, it mentions the applicable face.>> I don't have time to patch Org but my suggestion is to (i) create a new> face, such as 'org-block-edited-indirect', (ii) make it inherit from> 'secondary-selection' for backward compatibility, (iii) apply it to> function 'org-src--make-source-overlay'.>> If I have this, I will just grey out the block the same way, say, the> inactive buttons are in M-x customize.>> What do you think?
That sounds like a good idea. I am not very familiar with the
'customize' interface, since I do not use it. I tried launching
'M-x customize' and looked at a few variables, but couldn't see
any buttons.
I haven't found which specific face is associated with the buttons you
mention in the Modus source code, but I trust your tastes ^^
> Generally, the 'secondary-selection' is used in places where it needs to> stand out, including Org's date selection indicator that is beside the> minibuffer prompt or that appears after you reschedule an item in the> Org agenda.>> The Org code still has cases of bringing in the 'secondary-selection'> beside what I mentioned above. Just read the doc string of> 'org-clock-overlay' for an example.
What about changing the colour of 'secondary-selection'? I have tried
setting it to 'bg-hover-secondary' and thought it worked well with the
two cases we have mentioned. Org only seems to use 'secondary-selection'
for 'org-clock-overlay', 'org-agenda-structure-secondary' and 'org-agenda-clocking'.
However:
- I do not know about the other uses of 'secondary-selection'.
- This association does not make sense semantically (so to speak).
>> About mu4e: I don’t know why, but since the last updates, I have>> encountered several bugs in mu4e’s appearance. They may or may not be>> caused by Doom Emacs.>>>> • with modus-operandi, the background of mu4e-header-highlight face is>> #303030, which makes the text under it barely readable. According to>> mu4e’s code (and your latest updates to modus-themes), it is supposed>> to inherit from hl-line, which I think is sensible. I don’t understand>> why it isn’t being applied.>>>> • with modus-vivendi, mu4e-header-face’s background is #FFFFFF, while>> mu4e-replied-face is #000000, as it should be.>>>> • not a bug per se and not very important, but the text which is>> specific to marked messages (for example “-> delete”) appears in green>> in both modus-vivendi and modus-operandi. I am not sure this is caused>> by modus-themes - could anyone confirm? With modus-themes 3, the>> marks appear in #8f0075, which I think is nicer, because it makes the>> marks stand out more.>> It seems like another theme is enabled as well. What is the return> value of 'custom-enabled-themes'?
I'm very sorry about the noise: somehow some face definitions had found
their way into 'custom.el' (which I don't normally use). Deleting the
file solved the problem. However, the marks still appear in green,
and they didn't in Modus themes 3.
Thanks a lot!
Edgar
Protesilaos Stavrou <info@protesilaos.com> writes:
>> From: Protesilaos Stavrou <info@protesilaos.com>>> Date: Thu, 12 Jan 2023 06:56:11 +0200>>> [… 43 lines elided]>>>> • more importantly, the background of org source blocks after running>>> org-edit-src-code, which inherits from the secondary-selection face is>>> way too colourful, to the point where, when using modus-vivendi, the>>> text is unreadable. I do not really understand what second-selection>>> is, so I don’t know if its colour is appropriate elsewhere.>>>> This is an Org problem because it hardcodes the ’secondary-selection’>> instead of providing a face that I could customise. You can find this>> by placing the point over the colourised block and doing ’M-x>> describe-char’ (or type ’C-u C-x =’ with the default key bindings). In>> the resulting Help buffer, it mentions the applicable face.>>>> I don’t have time to patch Org but my suggestion is to (i) create a new>> face, such as ’org-block-edited-indirect’, (ii) make it inherit from>> ’secondary-selection’ for backward compatibility, (iii) apply it to>> function ’org-src–make-source-overlay’.>>>> If I have this, I will just grey out the block the same way, say, the>> inactive buttons are in M-x customize.>>>> What do you think?>>>> Generally, the ’secondary-selection’ is used in places where it needs to>> stand out, including Org’s date selection indicator that is beside the>> minibuffer prompt or that appears after you reschedule an item in the>> Org agenda.>>>> The Org code still has cases of bringing in the ’secondary-selection’>> beside what I mentioned above. Just read the doc string of>> ’org-clock-overlay’ for an example.>> What I wrote above stands: we need more refined faces. Though note that> I made an update to modus-theme.el to always override the foreground of> ’highlight’ and ’secondary-selection’ in the interest of legibility.> The commit:>> commit 6afb2448d27f26bc73ac7472833280de9c01268e> Author: Protesilaos Stavrou <info@protesilaos.com>> Date: Thu Jan 12 07:03:56 2023 +0200>> Enforce foreground for ’highlight’, ’secondary-selection’>> This should have always been there to avoid awkward colour> combinations. I realised it was missing after corresponding with> Edgar Vincent on a relevant topic:> <https://lists.sr.ht/~protesilaos/modus-themes/%3C878ri95h1q.fsf%40posteo.net%3E#%3C87ilhc7usc.fsf@posteo.net%3E>.>> modus-themes.el | 4 ++–> 1 file changed, 2 insertions(+), 2 deletions(-)
Thanks! That’s much better. I hadn’t noticed that that was actually the main issue in this case.
> From: Edgar Vincent <e-v@posteo.net>> Date: Thu, 12 Jan 2023 08:49:39 +0000>> Hi Prot!
Hello Edgar!
> [... 20 lines elided]>> The compromise, then, is to slightly amplify the value and shift it away>> from a neutral grey. It has a bit of blue to it.>>>> I think this is a case where it is impossible to have a default that>> works for everyone and/or in every case. There are different needs for>> a "line highlight" that cannot be reconciled. This is why I wrote 'lin'.>> You had mentioned that in the case of the modeline face too. I should> have remembered. I understand your argument, which does make sense> indeed.
And this is why I wanted to broaden the scope of the overrides: it makes
it easier to make all those tweaks without changing tens of faces.
Still, the defaults matter and I am open to suggestions for further
refinements.
> [... 17 lines elided]>> If I have this, I will just grey out the block the same way, say, the>> inactive buttons are in M-x customize.>>>> What do you think?>> That sounds like a good idea. I am not very familiar with the> 'customize' interface, since I do not use it. I tried launching> 'M-x customize' and looked at a few variables, but couldn't see> any buttons.> I haven't found which specific face is associated with the buttons you> mention in the Modus source code, but I trust your tastes ^^
You can see the inactive buttons if you do 'M-x customize'. The "Apply"
and "Apply and Save" are inactive when you enter the buffer and don't
make any changes.
This is the style I have in mind for those visited Org blocks. They are
"inactive" in the main buffer, as you can also make edits in the
indirect buffer.
>> Generally, the 'secondary-selection' is used in places where it needs to>> stand out, including Org's date selection indicator that is beside the>> minibuffer prompt or that appears after you reschedule an item in the>> Org agenda.>>>> The Org code still has cases of bringing in the 'secondary-selection'>> beside what I mentioned above. Just read the doc string of>> 'org-clock-overlay' for an example.>> What about changing the colour of 'secondary-selection'? I have tried> setting it to 'bg-hover-secondary' and thought it worked well with the> two cases we have mentioned. Org only seems to use 'secondary-selection'> for 'org-clock-overlay', 'org-agenda-structure-secondary' and 'org-agenda-clocking'.>> However:> - I do not know about the other uses of 'secondary-selection'.> - This association does not make sense semantically (so to speak).
I assume you meant another background instead of 'bg-hover-secondary' as
that is what is currently applied to 'secondary-selection' by default.
In terms of semantics, I agree that this is a face with a loosely
defined scope. Org uses it as a "highlight that should not be the same
as the 'highlight' face". I suppose one reason for this is that you can
hover with the mouse over headings in the Org agenda so it is possible
to have the date overlay and the mouse hover side-by-side. As such, the
distinction makes sense, even if the exact faces do not necessarily make
that clear.
Perhaps we can neutralise the value of 'bg-hover-secondary'? Make it a
bit more brown? Though it should not be much different due to the
expectations that the default value of this face sets. Its standard
light colour is 'yellow-1', which you can visualise with 'M-x
list-colors-display': it is intense. So ours should be "visible, though
not over-the-top like the default".
What do you think?
> [... 20 lines elided]>> It seems like another theme is enabled as well. What is the return>> value of 'custom-enabled-themes'?>> I'm very sorry about the noise: somehow some face definitions had found> their way into 'custom.el' (which I don't normally use).
That's okay, no worries! I personally do not use a permanent
custom-file for this very reason.
> Deleting the file solved the problem. However, the marks still appear> in green, and they didn't in Modus themes 3.
Can you identify the underlying face? Place the point over the colour
and do 'M-x describe-char' (or type 'C-u C-x =' with the default keys).
In the resulting Help buffer, check the face mentioned there.
> Thanks a lot!
You are welcome!
All the best,
Prot
--
Protesilaos Stavrou
https://protesilaos.com
Protesilaos Stavrou <info@protesilaos.com> writes:
[…]
>>> If I have this, I will just grey out the block the same way, say, the>>> inactive buttons are in M-x customize.>>>>>> What do you think?>>>> That sounds like a good idea. I am not very familiar with the>> ’customize’ interface, since I do not use it. I tried launching>> ’M-x customize’ and looked at a few variables, but couldn’t see>> any buttons.>> I haven’t found which specific face is associated with the buttons you>> mention in the Modus source code, but I trust your tastes ^^>> You can see the inactive buttons if you do ’M-x customize’. The “Apply”> and “Apply and Save” are inactive when you enter the buffer and don’t> make any changes.>> This is the style I have in mind for those visited Org blocks. They are> “inactive” in the main buffer, as you can also make edits in the> indirect buffer.
Oh well, Doom Emacs must be overriding the default settings for them. I looked at them
in a non-Doom configuration, and their colour looks good to me.
>>> Generally, the ’secondary-selection’ is used in places where it needs to>>> stand out, including Org’s date selection indicator that is beside the>>> minibuffer prompt or that appears after you reschedule an item in the>>> Org agenda.>>>>>> The Org code still has cases of bringing in the ’secondary-selection’>>> beside what I mentioned above. Just read the doc string of>>> ’org-clock-overlay’ for an example.>>>> What about changing the colour of ’secondary-selection’? I have tried>> setting it to ’bg-hover-secondary’ and thought it worked well with the>> two cases we have mentioned. Org only seems to use ’secondary-selection’>> for ’org-clock-overlay’, ’org-agenda-structure-secondary’ and ’org-agenda-clocking’.>>>> However:>> - I do not know about the other uses of ’secondary-selection’.>> - This association does not make sense semantically (so to speak).>> I assume you meant another background instead of ’bg-hover-secondary’ as> that is what is currently applied to ’secondary-selection’ by default.
Oh, this is embarrassing. Due to the ’custom.el’ issue I mentioned earlier, I had stale code setting
’secondary-selection’ to ’prose-tag’, which looked awful. Actually, the default setting (’bg-hover-secondary’)
is fine, but a shade of grey would be good too. I may have a slight preference for the former, because
although the source of narrowed source blocks (i.e the text in the original buffer) is “inactive”, it also
has a direct link with the narrowed buffer. I think the current colour conveys that idea: it is inactive (and
is thus coloured with a dim colour) but it is being acted upon (hence the hue).
Long story short: I think the choices you made are good, and I’m going in circles trying to reinvent them, ending
up back in square one :)
> In terms of semantics, I agree that this is a face with a loosely> defined scope. Org uses it as a “highlight that should not be the same> as the ‘highlight’ face”. I suppose one reason for this is that you can> hover with the mouse over headings in the Org agenda so it is possible> to have the date overlay and the mouse hover side-by-side. As such, the> distinction makes sense, even if the exact faces do not necessarily make> that clear.
I see. It does make sense.
> Perhaps we can neutralise the value of ’bg-hover-secondary’? Make it a> bit more brown? Though it should not be much different due to the> expectations that the default value of this face sets. Its standard> light colour is ’yellow-1’, which you can visualise with ’M-x> list-colors-display’: it is intense. So ours should be “visible, though> not over-the-top like the default”.>> What do you think?
It’s a difficult choice. For the Org timestamp prompt indicator, I think something
in the line of ’bg-changed-refine’ would be better, but ’bg-hover-secondary’ is
better for Org source blocks, as I find ’bg-changed-refine’ too distracting in
that context. Still, the current state of things is probably good enough.
[…]
>> Deleting the file solved the problem. However, the marks still appear>> in green, and they didn’t in Modus themes 3.>> Can you identify the underlying face? Place the point over the colour> and do ’M-x describe-char’ (or type ’C-u C-x =’ with the default keys).> In the resulting Help buffer, check the face mentioned there.>
It seems to be ’all-the-icons-green’ (#006800), which seems to be caused by
custom Doom code, so it has nothing to do with Modus. I should have checked that before.
[…]
Thanks again,
Edgar
> From: Edgar Vincent <e-v@posteo.net>> Date: Thu, 12 Jan 2023 14:06:10 +0000>> [... 15 lines elided]>>> You can see the inactive buttons if you do ’M-x customize’. The “Apply”>> and “Apply and Save” are inactive when you enter the buffer and don’t>> make any changes.>>>> This is the style I have in mind for those visited Org blocks. They are>> “inactive” in the main buffer, as you can also make edits in the>> indirect buffer.>> Oh well, Doom Emacs must be overriding the default settings for> them. I looked at them in a non-Doom configuration, and their colour> looks good to me.
Very well! If I find time this weekend, I will send a patch for
org.git. Otherwise you or anyone else reading this is welcome to it.
If you need help from me on defining a place, please let me know.
> [... 18 lines elided]>> I assume you meant another background instead of ’bg-hover-secondary’ as>> that is what is currently applied to ’secondary-selection’ by default.>> Oh, this is embarrassing. Due to the ’custom.el’ issue I mentioned> earlier, I had stale code setting ’secondary-selection’ to> ’prose-tag’, which looked awful. Actually, the default setting> (’bg-hover-secondary’) is fine, but a shade of grey would be good> too. I may have a slight preference for the former, because although> the source of narrowed source blocks (i.e the text in the original> buffer) is “inactive”, it also has a direct link with the narrowed> buffer. I think the current colour conveys that idea: it is inactive> (and is thus coloured with a dim colour) but it is being acted upon> (hence the hue).>> Long story short: I think the choices you made are good, and I’m going> in circles trying to reinvent them, ending up back in square one :)
That's okay, no worries! I am of the view that the custom-file does
more harm than good. Granted, it is a minor inconvenience, but it feels
like it happens often.
Anyhow, you now gained insight into an important aspect of the design
process that is not obvious: colours must work well for their intended
task as the context matters greatly. For this we now know that we need
a background that (i) is not purely grey, (ii) is not too intense but
not super subtle either, (iii) does not get mistaken for one of the diff
colours, (iv) is not like any of the backgrounds we use for isearch,
occur, grep, the region, and the highlighted expression of
show-paren-match (see 'show-paren-style'), and (v) is easy to tell apart
from the mouse highlight.
Many of the choices I make are informed by such considerations. This is
not to say that I do not make mistakes---I do all the time---but that
something that looks odd may have a good reason for being that way.
> [... 17 lines elided]>> What do you think?>> It’s a difficult choice. For the Org timestamp prompt indicator, I> think something in the line of ’bg-changed-refine’ would be better,> but ’bg-hover-secondary’ is better for Org source blocks, as I find> ’bg-changed-refine’ too distracting in that context. Still, the> current state of things is probably good enough.
If we can get Org to use specific faces for each of those, we can refine
the colouration. In principle, I am fine with that though I agree that
the current state is decent.
> […]>>>> Deleting the file solved the problem. However, the marks still appear>>> in green, and they didn’t in Modus themes 3.>>>> Can you identify the underlying face? Place the point over the colour>> and do ’M-x describe-char’ (or type ’C-u C-x =’ with the default keys).>> In the resulting Help buffer, check the face mentioned there.>>>> It seems to be ’all-the-icons-green’ (#006800), which seems to be> caused by custom Doom code, so it has nothing to do with Modus. I> should have checked that before.
I know Doom is opinionated, though this one is surprising! Hopefully
the themes are not affected too much in all sorts of contexts... I had
a case like that with Doom's inconsiderate tweaks to git-gutter:
<https://protesilaos.com/codelog/2022-08-04-doom-git-gutter-modus-themes/>.
--
Protesilaos Stavrou
https://protesilaos.com