bug#66050: Making perl-mode.el obsolete

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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

Levels are just not the right concept, because there are many ways to
"measure" and hence order by levels.

E.g. Most of the time, "level" is associated with the amount of effort
to figure out where to highlight, which is related to how much
understanding of the language is needed.  So it ends up providing
"lexical-level" information only at the lowest level and then as you
move up the level it gets more fancy and start accounting for grammar
and then static semantics (e.g. whether an identifier is a reference to
a local or global var).

Personally I want very little highlighting, but I'm usually more
interested in the "higher-level" highlighting, so I end up having to
choose the highest-level and then configuring most faces to be
indistinguishable from `default` :-(

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

I'm not talking about users creating a custom theme.  I'm talking about
cperl-mode providing a custom theme that gets it closer to something
like `perl-mode`.

> Emacs comes with themes which look better than anything I could create -

A cutom theme is nothing more than a set of Custom settings (vars and
faces), and users can enable *several* themes at the same time.  So we
can provide a `perl-mode` theme which just changes `cperl-mode` to look
and behave somewhat like `perl-mode` and that doesn't prevent users from
*also* using `modus-vivendi` or whichever "global color theme" they like.

A "custom theme" is like a minor mode, except that it's more declarative
so it better interacts with other user settings (or other themes which
may partly overlap).

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

I think you're overly pessimistic.  A few tweaks here and there
shouldn't cause too much noise, if they make things more
regular/consistent.

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

I guess using `font-lock-function-name-face` for [] does sound quite
wrong, since it plays a very different role from "the place where an
identifier is defined as a function-like thingy", which is what this
face is typically used for elsewhere.
I'd recommend to highlight them as something like keywords as well.
[ BTW, ELisp mode uses `font-lock-regexp-grouping-construct` for some
  of that.  ]

"Types" also sounds odd for \d and friends but the harm is probably
a bit more mild.

> The substitution part can be actual Perl code, and cperl-mode will
> fontify it as Perl code.

IIRC `perl-mode` also tries to fontify the replacement part as Perl code
(when it does contain Perl code).  I can't remember if I managed to make
it work for all the relevant cases, but I haven't heard any complaint
from `perl-mode` users when I made this change, so if `cperl-mode` does
it in more cases, I don't think `perl-mode` users will complain when
switching to `cperl-mode`.


        Stefan