bug#66050: Making perl-mode.el obsolete

[Stefan Monnier]

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

BTW, "bundling" is what Custom themes are for.
At least to solve the "learn for new users" side of the problem.
Not to say we should add more options (or more fine-grained options),
but it can be helpful to simplify the code (a.g. avoid having to test both
`cperl-dont-be-hairy` and `cperl-highlight-variables-indiscriminately`).

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

That's a downvote for font-lock levels from me.

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

They're faces, so they are already customizable, e.g. via Custom themes.

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

FWIW, I agree.  We don't have to satisfy all the wishlist items of
previous `perl-mode` users.

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

What part of this is "untidy" or "a mess"?  I can see why you'd say it
w.r.t Perl having those fine distinctions, but the corresponding
features in `cperl-mode` seem to just reflect Perl's syntax&semantics.
Or is it the implementation part to distinguish those two kinds of
builtins messy?

> When we clean up this mess, adding a way to not
> highlighting them at all should not be too difficult.

AFAIK that can also be solved by changing the faces' appearance, hence
without changing the code.

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

I think it's more important here to choose a "meaningful/consistent"
behavior than to reproduce what was done historically in `perl-mode` or
`cperl-mode`.

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

Here again, I believe it's a small matter of changing faces.


        Stefan