[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.