Check for font-lock-defaults before enabling #55
Conversation
|
I am currently trying to figure out why the test for ... let's not repeat that mistake. Please explain the why in the commit message. I think turning the mode should not silently fail. The user should be informed about what's wrong and |
Fair enough, but how? Messages are easily overlooked, the warnings package is suboptimal and throwing an error, even the |
|
IMO it is okay to use |
|
Ah you didn't notice that I did spin out the whitespace fix into a separate commit and then rebased the rest of your commit on top of that and pushed the result, and also added the |
|
OK, I think I finally figured the Git stuff out. Is the error message fine for you? |
|
Yes. One last thing, please use |
When using `enriched-mode` in addition to `text-mode` or alike, `font-lock-mode` will be set, but `font-lock-defaults` will not be. Therefore to detect whether font-lock can be used safely to add extra keywords, it's necessary to check both `font-lock-mode` and `font-lock-defaults`. See also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42138 for extra context.
|
Forgot to mention I did that change as well. |
|
Thanks! |
|
I had to revert this because of #56. |
|
Haha, so much about signalling a user error being the cleanest solution. |
|
In any case, the error there is for the globalized mode, so a full solution would need to add some check for the globalized version to only be enabled when it makes sense to do so. |
`hl-todo-mode' depends on `font-lock-mode'. Enabling the former in a buffer that does not use the latter likely removes text properties that were put in place using some other mechanism. So now we abort if this is about to happen. We cannot just check the value of `font-lock-mode' because apparently that may be non-nil even though that mode is not actually in effect or about to be put into effect. It is unclear why that is so. It is also unclear why we already did check for `font-lock-mode' (but seemingly too late). At least `font-lock-specified-p' seems to serve our purpose, so use that. See #55 and https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42138.
Yes, it worked very well! We immediately got notified about the regression, while I still knew what this is about.
... that we both failed to test this properly. Anyway, I (force) pushed a new version. |
|
Thanks, that seems to do the trick (although I'm not happy with using |
That cannot happen. It is not possible to turn on the mode and if the mode is never in the turned on state, then it can never be turned off. You can just try again to turn it on, which will fail again. |
|
Yeah, you're right. Personally I prefer to put something raising an error into a |
|
I had to revert my version as well. I didn't remember this when you opened your pull-request but This does lead to conflicts such as the one with |
Currently there is an incompatibility between hl-todo-mode and enriched-mode, hl-todo-mode doesn't do a sufficient check whether font-lock-add-keywords can be used and wipes out the fontification done by enriched-mode, meaning no more pretty colors when opening
etc/enriched.txt. This PR fixes this. See also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42138.