bug#34764: prettify-symbols-mode pollutes font-lock-extra-keywords

bug#34764: prettify-symbols-mode pollutes font-lock-extra-keywords

[Clément Pit-Claudel]

Hi all,

When turned off, prettify-symbols-mode removes 'composition' from font-lock-extra-keywords, but not prettify-symbols-start or prettify-symbols-end; as a result, every time prettify-symbols-mode is turned on, it adds two new elements to font-lock-extra-keywords.

(I ran into this issue because I added a watcher on font-lock-extra-keywords to debug an intermittent font-lock problem, and the increasingly long lists of prettify-symbol-* entries made things harder to read).

I'm happy to provide a patch, but I'm a bit puzzled by the implementation:

    (remove-hook 'post-command-hook #'prettify-symbols--post-command-hook t)
    (when prettify-symbols--keywords
      (font-lock-remove-keywords nil prettify-symbols--keywords)
      (setq prettify-symbols--keywords nil))
    (when (memq 'composition font-lock-extra-managed-props)
      (setq font-lock-extra-managed-props (delq 'composition
                                                font-lock-extra-managed-props))
      (with-silent-modifications
        (remove-text-properties (point-min) (point-max) '(composition nil))))))

Would it be simpler to just call font-lock-unfontify-region-function and remove all three properties from font-lock-extra-managed-props?

Cheers,
Clément.

In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
 of 2019-02-28 built on clem-w50-mint
Repository revision: 5d60229bf1a9a496102fc2a3ef9e57dcce7bef10
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Linux Mint 19.1

bug#34764: prettify-symbols-mode pollutes font-lock-extra-keywords

[Drew Adams]

> I'm a bit puzzled by the implementation:
> 
> (remove-hook 'post-command-hook
>              #'prettify-symbols--post-command-hook t)
>     (when prettify-symbols--keywords
>       (font-lock-remove-keywords nil prettify-symbols--keywords)
>       (setq prettify-symbols--keywords nil))
>     (when (memq 'composition font-lock-extra-managed-props)
>       (setq font-lock-extra-managed-props
>             (delq 'composition font-lock-extra-managed-props))
>       (with-silent-modifications
>         (remove-text-properties (point-min) (point-max)
>                                 '(composition nil))))))

I'm ignorant wrt prettify-symbols stuff.  But to me
it smells like a bug for some optional code (e.g. a
mode) to change a general setting such as `composition'
for `font-lock-extra-managed-props' etc. when it's done.

Should prettify-* assume it's the only code that cares
about property `composition'?  Or that it was the one
that added/set it in the first place?

Typically, I use a library-specific property instead
(e.g. `my-composition') and do whatever is needed to
give that property an effect like the general (global)
property, without interfering with that general property.

Maybe that's not appropriate for prettify-*.  Dunno.

Or I keep track of the initial state before adding
`composition', and then reset that property only if it
wasn't used to begin with (i.e., restore its value).

But that's not foolproof either, since some other code
can affect things after prettify-* is turned on, so
restoring to the state before it was turned on isn't
necessarily TRT.

Maybe such a save/restore approach is not easy/possible
for prettify-*.  Dunno.

bug#34764: prettify-symbols-mode pollutes font-lock-extra-keywords

[Clément Pit-Claudel]

Hi Drew,

On 05/03/2019 18.54, Drew Adams wrote:
> I'm ignorant wrt prettify-symbols stuff.  But to me
> it smells like a bug for some optional code (e.g. a
> mode) to change a general setting such as `composition'
> for `font-lock-extra-managed-props' etc. when it's done.

Thanks for pointing this out.  I agree that it's an issue, though fairly orthogonal to the specific issue I created the bug for (the two properties I would like to see removed from fl-extra-managed-props are both adequately prefixed with `prettify-symbol-').

> Should prettify-* assume it's the only code that cares
> about property `composition'?  Or that it was the one
> that added/set it in the first place?

Indeed, this general problem has dogged me in a number of plugins I wrote, too.

> Typically, I use a library-specific property instead
> (e.g. `my-composition') and do whatever is needed to
> give that property an effect like the general (global)
> property, without interfering with that general property.

I never thought about this solution.  This is great actually!   I'm aware of char-property-alias-alist, but I never quite realized that it provided an elegant solution to the problem of restoring font-lock-extra-managed-props when disabling a minor mode (the only user in the emacs source tree seems to befont-lock).  Is that the mechanism you had in mind?

> Maybe that's not appropriate for prettify-*.  Dunno.
> 
> Or I keep track of the initial state before adding
> `composition', and then reset that property only if it
> wasn't used to begin with (i.e., restore its value).
> 
> But that's not foolproof either, since some other code
> can affect things after prettify-* is turned on, so
> restoring to the state before it was turned on isn't
> necessarily TRT.
>
> Maybe such a save/restore approach is not easy/possible
> for prettify-*.  Dunno.

Right, I think that approach is doomed, because modes are not enable and disabled in a well-parenthesized manner (you can enable A, enable B, disable A, and disable B)

Thanks for the cool idea about char-property-alias-alist!
Clément.

bug#34764: prettify-symbols-mode pollutes font-lock-extra-keywords

[Drew Adams]

> > Typically, I use a library-specific property instead
> > (e.g. `my-composition') and do whatever is needed to
> > give that property an effect like the general (global)
> > property, without interfering with that general property.
> 
> I never thought about this solution.  This is great actually!   I'm
> aware of char-property-alias-alist, but I never quite realized that it
> provided an elegant solution to the problem of restoring font-lock-
> extra-managed-props when disabling a minor mode (the only user in the
> emacs source tree seems to befont-lock).  Is that the mechanism you had
> in mind?

No, in fact I wasn't aware of `char-property-alias-alist'. ;-)

I just meant in some way to try to have a library-specific
property control or replace a general property.  I don't
have in mind a general mechanism for doing that.

> > Maybe that's not appropriate for prettify-*.  Dunno.
> >
> > Or I keep track of the initial state before adding
> > `composition', and then reset that property only if it
> > wasn't used to begin with (i.e., restore its value).
> >
> > But that's not foolproof either, since some other code
> > can affect things after prettify-* is turned on, so
> > restoring to the state before it was turned on isn't
> > necessarily TRT.
> >
> > Maybe such a save/restore approach is not easy/possible
> > for prettify-*.  Dunno.
> 
> Right, I think that approach is doomed, because modes are not enable
> and disabled in a well-parenthesized manner (you can enable A, enable
> B, disable A, and disable B)

Yes.  But it kinda depends on how "big", longlasting or
important a (minor) mode is.  If it's something that
you tend to leave on a lot, as a basic Emacs customization
then you can sometimes live with just restoring the
previously ~virgin state when you toggle it off briefly.

But yeah, it depends.
 
> Thanks for the cool idea about char-property-alias-alist!

It was your idea!  Let us know how you make do with it.

bug#34764: prettify-symbols-mode pollutes font-lock-extra-keywords

[Clément Pit-Claudel]

On 06/03/2019 01.23, Drew Adams wrote: 
> No, in fact I wasn't aware of `char-property-alias-alist'. ;-)
> 
> I just meant in some way to try to have a library-specific
> property control or replace a general property.  I don't
> have in mind a general mechanism for doing that.

Font font-lock-extra-managed-props, at least, char-property-alias-alist seems perfect: you can declare my-abc to be an alias of abc, add my-abc to char-property-alias-alist when the minor mode gets activated, remove it when it gets deactivated, and as a bonus when clearing fontification font-lock will only clear the instances of abc that it applied itself. Very neat.

Clément.

bug#34764: prettify-symbols-mode pollutes font-lock-extra-keywords

[Drew Adams]

> > No, in fact I wasn't aware of `char-property-alias-alist'. ;-)
> >
> > I just meant in some way to try to have a library-specific
> > property control or replace a general property.  I don't
> > have in mind a general mechanism for doing that.
> 
> Font font-lock-extra-managed-props, at least, char-property-alias-alist
> seems perfect: you can declare my-abc to be an alias of abc, add my-abc
> to char-property-alias-alist when the minor mode gets activated, remove
> it when it gets deactivated, and as a bonus when clearing fontification
> font-lock will only clear the instances of abc that it applied itself.
> Very neat.

Yes, font-lock is a special case, because it already
deals in such a general way with a _list_ of properties,
"managing" them similarly.

Beyond that, one's code needs, one way or another, to
ensure that a library-specific property can have the
effect of the general, global one.  That's not built-in,
AFAIK.
_________

There is another case, which I forgot to mention, where
there is something general and built-in, but not
only for properties.  That's `buffer-invisibility-spec'.

By that I mean that you can add your own entries to
that spec, and you can remove them.  Other entries are
not affected.  (There are even specific functions to
add and remove.)

Something similar happens with hooks.

These are all places/constructs designed to be
modified by more than one library for more than one
purpose.  They are all, in a general sense, "hooks".

Another example, in the realm of properties, is the
exceptional way we treat property `face': code generally
handles both the case where the property value is a
single symbol (e.g. `lazy-highlight') and the case where
the value is a list of such.  Again: easy to add and
remove, without affecting what might be there from other
code.

A property whose value is expected/allowed to be a list
of values, each of which can determine the behavior,
is more flexible.

Whether this could or should be generalized, I don't
know.  But it sure is easier to keep the effects of
some code (e.g. a mode) separate in the cases where
we've planned ahead for a list of behavior-modifying
entries rather than just a single such.

bug#34764: prettify-symbols-mode pollutes font-lock-extra-keywords

[Lars Ingebrigtsen]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> Font font-lock-extra-managed-props, at least,
> char-property-alias-alist seems perfect: you can declare my-abc to be
> an alias of abc, add my-abc to char-property-alias-alist when the
> minor mode gets activated, remove it when it gets deactivated, and as
> a bonus when clearing fontification font-lock will only clear the
> instances of abc that it applied itself. Very neat.

Sounds like a good idea.  Did you work up a patch along these lines?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#34764: prettify-symbols-mode pollutes font-lock-extra-keywords

[Clément Pit-Claudel]

On 2019-10-30 15:30, Lars Ingebrigtsen wrote:
> Clément Pit-Claudel <cpitclaudel@gmail.com> writes:
> 
>> Font font-lock-extra-managed-props, at least,
>> char-property-alias-alist seems perfect: you can declare my-abc to be
>> an alias of abc, add my-abc to char-property-alias-alist when the
>> minor mode gets activated, remove it when it gets deactivated, and as
>> a bonus when clearing fontification font-lock will only clear the
>> instances of abc that it applied itself. Very neat.
> 
> Sounds like a good idea.  Did you work up a patch along these lines?

No, I didn't; I didn't find the time to :/