bug#39390: 28.0.50; prettify-symbols-mode confuses display when start/end faces are different

[Raphael 'kena' Poss]

Hi Eli,

thanks for your fast answer.

On 02-02-2020 19:03, Eli Zaretskii wrote:
> I can only explain it in general terms, since I'm not familiar with
> go-mode.

Look the issue is not particular to go-mode.

Also note that I am using prettify-symbols-mode which is a standard
function from prog-mode.el shipped in core Emacs. This is not an
extension and it is not my own custom code.

I am looking for advice to either:

1. enhance my *configuration* of prettify-symbols-alist, so as to avoid
the problem when using the standard code prog-mode.el

2. or, a diff for prog-mode.el to fix/workaround the problem in a way
independent of the particular lang major mode.

Your advice:

> The idea is to modify the font-lock definitions of the mode such that
> the characters you want to substitute all get the same face.

The substitution is performed by prog-mode.el
(prettify-symbols--compose-symbol) not by my own code. I would like to
know what I need to do to make that code use the same face for all of
the result of the substitution.

Preferably without modifying prog-mode.el (which I don't control), but
I'll take a diff against that if that's my only option.

I think the salient part from prog-mode.el is this:

        ;; That's a symbol alright, so add the composition.
        (with-silent-modifications
          (compose-region start end (cdr (assoc match alist)))
          (add-text-properties
           start end
           `(prettify-symbols-start ,start prettify-symbols-end ,end)))

from here:
https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/progmodes/prog-mode.el#n134

Is there a way to tweak either the configuration
(prettify-symbols-alist) or prog-mode.el to trick it into emitting the
same face for the substitution?

If that is not possible, is there a way to add an additional font-lock
keyword rule that applies _after_ the substitution performed by
prettify-symbols-mode and "clean up" the face mix-up?

(My opinion is that this bug exists in prog-mode.el and thus a
workaround/fix should be provided at that level, not in a per-mode or
per-user customization.)


-- 
Raphael 'kena' Poss