Re: [RFC] Add :invisible face attribute

["Kévin Le Gouguec" <kevin.legouguec@gmail.com>]

Michal Nazarewicz <mina86@mina86.com> writes:

> On Fri, Dec 20 2024, Richard Stallman wrote:
>>   > Introduce :invisible face attribute which makes foreground to be the
>>   > same as background rendering the text invisible; or when :invert-video
>>   > is also in effect, background is the same as foreground.
>>
>> Why is this feature worth having>  What is useful about it?
>>
>>   > Use it in Org mode for org-hide face eliminting the need for
>>   > org-find-invisible-foreground function.
>>
>> Ia that the sole benefit of this feature?
>> I don't think it is sufficent reason to add the feature
>> and write the changes to document it.
>
> Yes, the use-cases I’m aware of are around org-hide.  To sum up:
> * The feature would make org-hide easier as described above.
> * It addresses two minor bugs with org-hide I’ve mentioned in the other
>   mail.

Drive-by idea, from another org-hide-leading-stars user who encounters
the first bug occasionally (or rather, a variant thereof, when
highlighting headings with faces like region or hl-line):

Would it make sense to fix these bugs by making Org apply a
  '(display (space :width 1))
property on every star to hide?  (Suggesting one prop per char, instead
of prop'ing the whole prefix with a single (space :width N), since AFAIU
that would prevent users from moving point within the prefix?)

Possibly a hot air suggestion: not super familiar with display props, so
they may have undesirable side-effects?  Also not sure how to apply them
& keep them updated "robustly".  The current org-hide face is applied
via font-lock so no extra bookkeeping required; '(elisp) Search-based
Fontification' suggests font-lock does support applying arbitrary
properties - and clearing them, using font-lock-extra-managed-props.

This is completely armchair reading of the manual tho, never toyed with
display properties.  Mostly curious if this is something that could make
sense in theory.  AFAIU this "solution" would not address your second
use-case anyway:

> * For code outside of Emacs, it makes auto-dim-other-buffers slightly
>   more user friendly.