From: Michal Nazarewicz <mina86@mina86.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: [RFC] Add :invisible face attribute
Date: Wed, 18 Dec 2024 19:05:45 +0100 [thread overview]
Message-ID: <78ygdhfoffedn7p69uwz1oy8@mina86.com> (raw)
In-Reply-To: <867c7xlyqp.fsf@gnu.org>
On Wed, Dec 18 2024, Eli Zaretskii wrote:
> A new face attribute adds quite a bit of complexity, so we should
> really believe this is a good idea. Given that this can already be
> achieved without a new attribute, I'm not sure. Is this really a
> frequent need/situation?
Yes, agreed. org-hide is the only face I’m aware of and this only came
up as I was working on auto-dim-other-buffers.
To quickly recap, auto-dim-other-buffers adds a face remap to default
face which changes its background. The problem is that if default
background is changed, text rendered with org-hide becomes visible. So
now I also need to remap org-hide.
This by itself I could live with, but it creates friction for users who
need to not only customise auto-dim-other-buffers-face (which specifies
the remap background) but also auto-dim-other-buffers-hide-face.
There are actually two minor bugs in Org mode that this patch fixes.
First is when default face is changed after org-mode is initialised:
(setq org-hide-leading-stars t)
(org-mode)
(insert "\n*** Foo\n") ; the first two stars are invisible
(set-face-background 'default "red") ; the starts become visible
Second is when running with frames on multiple displays, e.g. starting
org-mode on terminal frame with black background makes org-hide use
black foreground. But that’s visible on X11 frame which uses white
background.
This is why I’ve not gone with Org’s way of initialising the hide face
when the mode is first enabled.
>> @@ -2911,6 +2925,13 @@ merge_face_ref (struct window *w,
>> else
>> err = true;
>> }
>> + else if (EQ (keyword, QCinvisible))
>> + {
>> + if (EQ (value, Qt) || NILP (value))
>> + to[LFACE_INVISIBLE_INDEX] = value;
>> + else
>> + err = true;
>> + }
> Does this mean that the result of merging two faces with different
> values for :invisible will depend on the order of the merge? That is,
> does the nil value override the t value? Or am I missing something?
The behaviour is the same as for other boolean attributes, e.g. extend
or inverse-video, so yes, if the attribute is specified multiple times
one overrides the other.
There’s a related difference in how org-hide works now vs with this
patch. Currently, selecting text which uses org-hide makes the text
visible; with this patch it remains invisible unless region face is
changed to include :invisible nil.
> Btw, I think "invisible" is not the best name for this, because that's
> not really what will happen on display. It's more like "illegible" or
> something to that effect.
Not sure I’m a fan of illegible but I’m happy to go with whatever name.
By the way, two other ideas I had were:
a) add another value for :inverse-video (e.g. ‘:inverse-video
'foreground’ makes foreground same as background) or
b) add a pseudo colour so one could write ‘:foreground "background"’.
--
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»
prev parent reply other threads:[~2024-12-18 18:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-18 16:08 [RFC] Add :invisible face attribute Michal Nazarewicz
2024-12-18 16:52 ` Eli Zaretskii
2024-12-18 18:05 ` Michal Nazarewicz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=78ygdhfoffedn7p69uwz1oy8@mina86.com \
--to=mina86@mina86.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).