bug#66050: Making perl-mode.el obsolete

[Jens Schmidt]

Stefan Kangas <stefankangas@gmail.com> writes:

> Jens Schmidt <jschmidt4gnu@vodafonemail.de> writes:
>
>> cperl-mode already has some big-config-sweep-knobs, like it seems
>> (`cperl-hairy').  It would certainly be nice to also have some
>> "make-things-work-like-in-perl-mode-but-sans-its-bugs" knob if it came
>> to obsoleting perl-mode.  For me, the most important things to cover
>> here would be a nearly-identical look-and-feel for indentation and
>> syntax highlighting.
>
> Which features would be covered by `like-perl-mode-sans-bugs', that are
> not already covered by `cperl-hairy'?

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.

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

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.

2. Arrays and hashes should be highlighted just like scalars, in
   font-lock-variable-name-face.

3. Variable sigils ("$", "%", "@") should not be highlighted at all.

4. Builtins ("shift", "ref", "defined") should not be highlighted at
   all.

5. Package names should be highlighted as font-lock-constant-face rather
   than font-lock-function-face.

6. Unquoted hash keys before "=>" should not be highlighted at all.

7. Regexps should be highlighted as font-lock-string-face.

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!

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.

    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.

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.

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

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