GNU bug report logs - #66050
Making perl-mode.el obsolete

Previous Next

Full log

View this message in rfc822 format

From: Harald Jörg <haj <at> posteo.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 66050 <at> debbugs.gnu.org, Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>, Stefan Kangas <stefankangas <at> gmail.com>
Subject: bug#66050: Making perl-mode.el obsolete
Date: Mon, 25 Sep 2023 09:18:26 +0000

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

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

Oh, i see.  And I agree.

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

Ah - I understand.  Indeed, this looks like the way to go!

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

...and also I have a thick skin, so this won't stop me :)

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

Yes, that's not a "correct" use of `font-lock-function-name-face` - but
it has been like this for ages.  I think it makes sense to highlight
*all* characters which aren't taken literally in the search pattern
since this is a frequent source of beginner problems.

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

So this would be a general improvement for cperl-mode!

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

I find it actually defendable.  Within the realm of the regular
expressions language, "digits" or "spaces" are sort of "types" (and
there's no dedicated font-lock-regexp-* face for those).

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

Oh - I couldn't see it with my example.  Perhaps I miss a setting.

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

I agree.

-- 
Cheers,
haj

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.