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

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

bug#22867: cperl-mode: Commit d0ad6306 suppresses fontification of hash/


From: Lars Ingebrigtsen
Subject: bug#22867: cperl-mode: Commit d0ad6306 suppresses fontification of hash/array declarations
Date: Fri, 04 Sep 2020 05:46:03 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Harald Jörg <haj@posteo.de> writes:

>> Is the fix worse than the problem?  If yes, maybe it should be reverted?
>
> The fix isn't _worse_.  Strings like "%s" and "%d" in the argument
> list of printf being fontified as hashes is indeed idiotic.  Also,
> more than once I was annoyed by fontification in POD sections.

The change in the offending commit just ensured that we don't re-fontify
already-fontified stuff as hashes.  This means that the reason stuff
like "my %foo = ..." isn't fontified as a hash is because something has
already fontified it as something else, so I wondered whether just
flipping the order of some of these regexp would do the trick.  After
poking around a bit, I came up with this patch:

diff --git a/lisp/progmodes/cperl-mode.el b/lisp/progmodes/cperl-mode.el
index 5dee5007e2..7a1c2e4d24 100644
--- a/lisp/progmodes/cperl-mode.el
+++ b/lisp/progmodes/cperl-mode.el
@@ -5776,8 +5776,8 @@ cperl-init-faces
                  t-font-lock-keywords)
                cperl-font-lock-keywords cperl-font-lock-keywords-1
                cperl-font-lock-keywords-2 (append
-                                          cperl-font-lock-keywords-1
-                                          t-font-lock-keywords-1)))
+                                          t-font-lock-keywords-1
+                                          cperl-font-lock-keywords-1)))
        (if (fboundp 'ps-print-buffer) (cperl-ps-print-init))
        (if (or (featurep 'choose-color) (featurep 'font-lock-extra))
            (eval                       ; Avoid a warning


It seems to fix all the test cases in Harald's .pl file, and the cperl
test file still passes (but its coverage isn't, ahem, extensive).

Does anybody see any problems with just doing fixing it like this?  I
had a peek at a couple of other perl files here, and nothing immediately
looked wonky, but I'm a bit out of practice writing perl...

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





reply via email to

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