bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Clément Pit-Claudel
Subject: bug#34764: prettify-symbols-mode pollutes font-lock-extra-keywords
Date: Tue, 5 Mar 2019 22:50:28 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]