bug#66050: Making perl-mode.el obsolete

["Harald Jörg" <haj@posteo.de>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

Agreed.

cperl-mode has many customization options I've never tried (nor fully
understood).  These days, "Perl Best Practices" (the book, almost 20
years old by now) and perltidy (the tool) could be taken as guidelines
for new users.  Unfortunately, Perl has lots of very knowledgeable old
users, some of which are rather religious in their opinions - and
perltidy lets all of them have it their way.

I *guess* that for new users a manual or tutorial would be helpful, but
don't know whether I can spend the time to write it (nor whether I'm the
right person to do it).

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

Oh - I guessed that ignoring font-lock-levels was one of the things you
meant when you wrote that cperl-mode is different than other major modes...

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

Sure.  I think that creating custom themes might be a bit beyond what
*users* of c?perl-mode might want to do (I myself never did that).
Emacs comes with themes which look better than anything I could create -
and adding four extra faces which fit these palettes needs experience I
don't have.

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

It is the implementation.

There's some overlap in the "regex-opt" lists of keywords
(e.g. "require", "for").  Some of the "builtin functions" are actually binary
operands ("eq" and friends).  "use" is fontified as a keyword, but "no"
(which is sort of "do not use") is fontified as a non-overridable
function.  The builtins use font-lock-type-face, which isn't
appropriate.  "shift" is fontified as non-overridable, but it can be
overridden in recent Perl versions.

An overhaul of all of this would take some time, and probably a thick
skin to weather the storm caused by cperl-mode users who are accustomed
to the current colors.

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

Agreed.

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

Agreed!

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

It is a bit more than _changing_ faces.  In the match part, cperl-mode
highlights metacharacters (|) as keywords, [] as functions, and
character classes (\d \D \s and friends) as types.  The substitution
part can be actual Perl code, and cperl-mode will fontify it as Perl
code.

For example, the following substitution is rather colorful in cperl-mode
but (sorry) dull in perl-mode:

   s/\d+|[IVXLCDM]+(\D)/sqrt(2) . "_$1_"/eri;

Making these highlightings optional would, as far as I know, require to
define an extra set of faces, which could then be mapped either to their
cperl-mode values (cperl-mode style) or all to font-lock-string-face
(perl-mode style).

-- 
Cheers,
haj