Re: Foreground color opacity

[Eli Zaretskii <eliz@gnu.org>]

> From: Filippo Argiolas <filippo.argiolas@gmail.com>
> Date: Mon, 11 Sep 2023 21:00:35 +0200
> Cc: emacs-devel@gnu.org
> 
> On Mon, Sep 11, 2023 at 6:57 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: Filippo Argiolas <filippo.argiolas@gmail.com>
> > > Date: Mon, 11 Sep 2023 18:25:50 +0200
> > > Cc: emacs-devel@gnu.org
> > >
> > > 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?
> >
> > One such example is flyspell.el's flyspell-prog-mode.  See
> > flyspell-prog-text-faces there.
> 
> Thanks! That should be easily solvable by adding
> `font-lock-string-face-clangd-inactive' and the other relevant
> inactive face variants to `flyspell-prog-text-faces'.
> FWIW with eglot+clangd (and I guess other servers too) inactive code
> regions already behave differently because they are not compiled, so
> you won't get e.g. any flymake diagnostics or inlay hints, so it could
> be a little less of an issue if something else like flyspell in this
> case breaks.

My point is that this technique _will_ break features, and I don't
think it's reasonable to expect each one of them to be fixed
individually.