Package: emacs;
Reported by: Stefan Kangas <stefankangas <at> gmail.com>
Date: Sun, 17 Sep 2023 12:49:02 UTC
Severity: wishlist
View this message in rfc822 format
From: Harald Jörg <haj <at> posteo.de> To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de> Cc: 66050 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>, Stefan Monnier <monnier <at> iro.umontreal.ca> Subject: bug#66050: Making perl-mode.el obsolete Date: Sun, 24 Sep 2023 00:02:52 +0000
Jens Schmidt <jschmidt4gnu <at> vodafonemail.de> writes:
> [...]
> Just to avoid misunderstandings: I have tried so far everything with
> `cperl-hairy' unchanged from default nil. I guess that non-nil makes
> cperl-mode even more electric, etc., which is actually the opposite
> direction of what I'm heading for.
Indeed. I always use `cperl-hairy' and am not really aware how
cperl-mode looks without it, but I know that it is still more colourful
than perl-mode.
>> Is it just a matter of setting some already existing options or is
>> "more work" needed?
>
> That's more a question for Harald, I think, since I'm not very well
> acquainted with cperl-mode.
It would need more work. An important step is to identify the features
we should be able to switch off per customization. I am somewhat
reluctant to add more options to cperl-mode if they can't be bundled
(like `cperl-hairy' does): The possible combinations of options are a
nightmare to document, to test, and also to learn for new users.
> I can state only what I have noticed this afternoon, after some very
> cursory comparison and review. Hoping this is the right place for such
> a wish list:
>
> 1. All scalar references should be hightlighted with
> font-lock-variable-name-face.
>
> Seems that `cperl-highlight-variables-indiscriminately' provides that.
Yes, that should be covered. The option name is somewhat ... weird, but
I didn't find enough motivation to change it (or to fiddle with
font-lock-level 3, which would be more in line with other modes).
> 2. Arrays and hashes should be highlighted just like scalars, in
> font-lock-variable-name-face.
This seems doable. The easy way is to make cperl-hash-face and
cperl-array-face customizable so that they can be "downgraded" to
font-lock-variable-name-face.
cperl-mode.el goes to great lengths to identify usage of array and hash
variables in situations where they don't look like arrays (for example,
$var is a scalar, but $#var belongs to an array), and this
distinction is helpful for Perl beginners (it was for me).
But I see that these two extra faces of cperl-mode are somewhat
nonstandard, and they don't play well with all of the Emacs themes (nor
can we expect the developers of themes to take these faces into
account).
> 3. Variable sigils ("$", "%", "@") should not be highlighted at all.
I doubt that this is worth the effort in cperl-mode... and guess it
should be tolerable. The sigil *is* part of the variable, after all.
> 4. Builtins ("shift", "ref", "defined") should not be highlighted at
> all.
This is an area where cperl-mode is a bit untidy. It has two different
faces for builtins, depending on whether they can be overridden by user
functions with the same name. Many occur in two lists for
fontification, only the first one ever applies. This has *some*
justification because builtins allow sloppy syntax (omitting
parentheses). When we clean up this mess, adding a way to not
highlighting them at all should not be too difficult.
> 5. Package names should be highlighted as font-lock-constant-face rather
> than font-lock-function-face.
perl-mode uses font-lock-function-name-face in the package declaration
but font-lock-constant-face in 'use' statements. I can't say whether
that is intentional.
Someone once suggested to use font-lock-type-face (because packages
usually are classes, and classes are sort-of types). This is one of the
cases where I doubt that adding more options will actually improve
things.
> 6. Unquoted hash keys before "=>" should not be highlighted at all.
They are highlighted as strings because the *are* strings. This is not
implemented in perl-mode, and it causes misinterpretations like in
Bug#45083: Not highlighting barewords but also preventing them to be
picked up by some other highlighting rule might be tricky.
> 7. Regexps should be highlighted as font-lock-string-face.
This can be added as an option with some effort. Regexps aren't
strings, but alas, almost no syntax highlighter takes the same effort as
cperl-mode to display them.
> When I switch on cperl-mode, there is little left which is *not*
> highlighted ...
>
> 8. Re-indentation of blocks should not merge else/elsif keywords with
> preceeding curlies.
>
> 9. Re-indenting a region should not adjust positions of after-code
> comments.
>
> Ah, cperl-style "PBP" covers 8. and 9. above!
You are welcome :)
> 10. Some parts of cperl-mode look, well, over-engineered. Function
> `cperl-find-pods-heres' is a stunning 1000+ lines long and obviously
> features regexps with more than 20 subres.
I agree that this function isn't a piece of beauty. It was written
before non-capturing groups were added to Emacs and never thoroughly
reengineered. This makes maintenance of that part difficult, but should
not affect users.
> BTW, on Image/ExifTool.pm as of version 12.16 I get errors in "emacs
> -Q" when switching on cperl-mode, I think because of that function.
It would be an interesting exercise to find out which options cause
this. I can reproduce it (it spits out an unjustified error message,
but apparently without any consequences). It does not happen with my
settings, and it does not happen if I explicitly call
cperl-fund-pods-heres with any settings.
> 11. Last not least, these pseudo-variables on the page labeled "Short
> extra-docs." always bug me. Packing arbitrary documentation in
> variables seems rather strange and rather non-standard.
Strange and non-standard for sure, but harmless.
> While that does not sound much:
>
> - I have the impression that, despite so many options in cperl-mode
> being available, just the right ones to "turn cperl-mode into
> perl-mode" are missing. But that could also be because I haven't
> found them yet ...
Correct, such an option does not exist.
> - There's probably more to it than that. Having some
> `like-perl-mode-sans-bugs' umbrella would be not only helpful to make
> this more easily customizable, but also to have something to "attach"
> future development to. Not sure how to express that better.
I am not sure I understand what this means. perl-mode does not
understand new syntax like the "class" feature - but that's not a bug,
it just has never been implemented. Should these things be treated
"like in cperl-mode" (because in cperl-mode they are implemented), left
as they are in perl-mode today, or would perl-mode users want to decide
how support should look like for new language features?
--
Cheers,
haj
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.