GNU bug report logs - #34764
prettify-symbols-mode pollutes font-lock-extra-keywords

Previous Next

Full log

Message #11 received at 34764 <at> debbugs.gnu.org (full text, mbox):

From: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>, 34764 <at> debbugs.gnu.org
Subject: Re: bug#34764: prettify-symbols-mode pollutes font-lock-extra-keywords
Date: Tue, 5 Mar 2019 22:50:28 -0500

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.