Re: Foreground color opacity

[Filippo Argiolas]

On Mon, Sep 11, 2023 at 4:04 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Filippo Argiolas <filippo.argiolas@gmail.com>
> > Date: Mon, 11 Sep 2023 15:09:45 +0200
> > Cc: emacs-devel@gnu.org
> >
> > > Why not cover the "inactive" portion with an overlay which has the
> > > 'face' (or font-lock-face) property that specifies only the opacity?
> > > That is IMO simpler and doesn't need to run any functions after
> > > fontifications.
> > >
> > > (Caveat: I didn't actually try this approach, so maybe I'm missing
> > > something.)
> > >
> > > Thanks.
> >
> > That would be the perfect solution, but as far as I can tell we don't
> > have an opacity face attribute, do we?
>
> Too bad.  (The alpha parameter is what I had in mind , but I see now
> that it's only supported for the entire frame, not for a single face.)

Right, I looked into that as well but it seems it's just to set the
whole frame as semitransparent with compositing window managers.

> Anyway, it sounds inelegant that we need to jump through such hoops to
> achieve such a simple effect.  It could even be a problem, if some
> Lisp program expects to find the font-lock faces in a buffer, but
> instead sees your special faces which replaced them.  E.g., don't we
> have features that detect strings and comments in code by looking for
> their respective font-lock faces?

Agreed that's inelegant, unfortunately it's the only way I found so
far without changing the backend, i.e. that works with current Emacs.
Started this thread to see if anyone has a better solution in mind
besides introducing a new opacity/alpha attribute.

Didn't encounter any issue so far with c and c-ts modes but something
like you described could definitely happen if someone relies on font
face to detect symbol type. I'd say that's kind of an unsafe aspect to
rely on. Do you have any example in mind of code doing that so I could
run some tests?

Filippo