all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Harald Jörg" <haj@posteo.de>
To: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
Cc: 66050@debbugs.gnu.org, Stefan Kangas <stefankangas@gmail.com>,
	Stefan Monnier <monnier@iro.umontreal.ca>
Subject: bug#66050: Making perl-mode.el obsolete
Date: Sun, 24 Sep 2023 00:02:52 +0000	[thread overview]
Message-ID: <874jjka15f.fsf@oook.m.uunet.de> (raw)
In-Reply-To: <87fs3cv7mg.fsf@sappc2.fritz.box> (Jens Schmidt's message of "Sun, 17 Sep 2023 22:59:19 +0200")

Jens Schmidt <jschmidt4gnu@vodafonemail.de> writes:

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

Indeed.  I always use `cperl-hairy' and am not really aware how
cperl-mode looks without it, but I know that it is still more colourful
than perl-mode.

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

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.

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

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

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

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.

cperl-mode.el goes to great lengths to identify usage of array and hash
variables in situations where they don't look like arrays (for example,
$var is a scalar, but $#var belongs to an array), and this
distinction is helpful for Perl beginners (it was for me).

But I see that these two extra faces of cperl-mode are somewhat
nonstandard, and they don't play well with all of the Emacs themes (nor
can we expect the developers of themes to take these faces into
account).

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

> 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).  When we clean up this mess, adding a way to not
highlighting them at all should not be too difficult.

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

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

They are highlighted as strings because the *are* strings.  This is not
implemented in perl-mode, and it causes misinterpretations like in
Bug#45083: Not highlighting barewords but also preventing them to be
picked up by some other highlighting rule might be tricky.

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

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

You are welcome :)

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

I agree that this function isn't a piece of beauty.  It was written
before non-capturing groups were added to Emacs and never thoroughly
reengineered.  This makes maintenance of that part difficult, but should
not affect users.

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

It would be an interesting exercise to find out which options cause
this.  I can reproduce it (it spits out an unjustified error message,
but apparently without any consequences).  It does not happen with my
settings, and it does not happen if I explicitly call
cperl-fund-pods-heres with any settings.

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

Strange and non-standard for sure, but harmless.

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

Correct, such an option does not exist.

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

I am not sure I understand what this means.  perl-mode does not
understand new syntax like the "class" feature - but that's not a bug,
it just has never been implemented.  Should these things be treated
"like in cperl-mode" (because in cperl-mode they are implemented), left
as they are in perl-mode today, or would perl-mode users want to decide
how support should look like for new language features?

-- 
Cheers,
haj





  parent reply	other threads:[~2023-09-24  0:02 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-17 12:47 bug#66050: Making perl-mode.el obsolete Stefan Kangas
2023-09-17 16:34 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-17 18:20   ` Stefan Kangas
2023-09-17 20:59     ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-22  7:39       ` Stefan Kangas
2023-09-24  0:02       ` Harald Jörg [this message]
2023-09-24 15:58         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-24 21:29           ` Harald Jörg
2023-09-24 22:12             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-25  9:18               ` Harald Jörg
2023-09-25 10:09                 ` Mauro Aranda
2023-09-25 10:34                   ` Harald Jörg
2023-09-18 14:11 ` Corwin Brust
2023-09-20 18:34   ` Richard Stallman
2023-09-20 23:26     ` Stefan Kangas
2023-09-21  0:08       ` Corwin Brust
2023-09-21  0:16         ` Stefan Kangas
2023-09-21  0:37           ` Corwin Brust
2023-09-21  0:49             ` Stefan Kangas
2023-09-21 14:13           ` Mauro Aranda
2023-09-21 14:20             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-21 20:14               ` Mauro Aranda
2023-09-24  5:30                 ` Stefan Kangas
2023-09-24 22:21             ` Harald Jörg
2023-09-24 22:40               ` Mauro Aranda
2023-09-25  8:33                 ` Harald Jörg
2023-09-25 13:04                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-24 22:54               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-25  8:40                 ` Harald Jörg
2023-09-18 16:14 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-24  0:44   ` Harald Jörg
2023-09-24  7:31     ` Stefan Kangas
2023-09-24 16:01       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-26  9:02       ` Richard Stallman
2023-09-23 22:13 ` Harald Jörg
2023-09-24 10:41   ` Stefan Kangas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874jjka15f.fsf@oook.m.uunet.de \
    --to=haj@posteo.de \
    --cc=66050@debbugs.gnu.org \
    --cc=jschmidt4gnu@vodafonemail.de \
    --cc=monnier@iro.umontreal.ca \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.