Don't use different face for overridable and nonoverridable keywords

[choroba]

I find other categories more important for a programmer, e.g. "takes more than one argument" versus "takes 0 or 1 arguments", because they are parsed differently when used without parentheses. Another interesting distinction is "uses $_ by default". I'd rather see different faces for these groups, or maybe make it configurable which distinction is displayed by using cperl-nonoverridable-face versus font-lock-type-face.

[HaraldJoerg]

Indeed, the distinction between "overridable" and "nonoverridable" keywords seems pretty arbitrary (why is shift shown as nonoverridable but bless isn't? Even if there is some distinction deep in Perl's C code, I bet that most users don't care). Also, some of the functions are actually infix operators (for example, le and family), and I plan to put Perl 5.32's isa in that same category.

Most of that stuff dates back to the previous century and was maintained in manually optimized (so: hard to read, even harder to change) regular expressions: back then, computers weren't as fast as they're today, and speed was an issue.

In the current code, the regular expressions have been reverse engineered into their lists of keywords (starting here) and the optimized regular expressions are built at runtime. You could now even supply your own lists in your init.el.

I do, on the other hand, hesitate to make it configurable which distinction is displayed. cperl-mode comes with 69 configuration variables, which I find confusing enough, and already has some faces beyond the number supplied by font-lock. If you choose one of your interesting distinctions, I'd simply whip up a branch for that... maybe we could also start a poll (but where? Perlmonks is only a small subset of Perl users) which distinction they want to see.

[choroba]

some distinction deep in Perl's C code

In fact, it's been documented in CORE.

[HaraldJoerg]

Thanks for the pointer! This is an indication that Perl users don't care too much and supports your suggestion to just eradicate the distinction. The list changes between versions: for 5.24, shift is in the list, it vanished in 5.26. No-one ever complained that shift is displayed in the wrong shade of green now.

Walking through the perldelta.pod is something on my TODO list anyway, but I would have discarded that change as irrelevant to cperl-mode.... if we implement your suggestion, it actually is.

[HaraldJoerg]

In a related discussion on the Emacs developer list, it was suggested that CPerl mode should move towards the "common" use of faces, i.e. no longer (ab)use font-lock-type-face for over-writable functions. I think this makes sense, in particular since we have various type systems for Perl which could make good use of font-lock-type-face.