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

Previous Next

Full log

Message #55 received at 66050 <at> debbugs.gnu.org (full text, mbox):

From: Harald Jörg <haj <at> posteo.de>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 66050 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#66050: Making perl-mode.el obsolete
Date: Sat, 23 Sep 2023 22:13:41 +0000

Stefan Kangas <stefankangas <at> gmail.com> writes:

> I don't think it makes sense for us to spend our meager resources
> maintaining two major modes for Perl.  I would like to gauge what people
> think about obsoleting perl-mode.el.

I'm not the right person to talk about obsoleting, since I have never
used perl-mode.el.  When I started using Emacs for Perl, usenet was
still a thing.  Ilya Zakharevich (the long-time maintainer of
cperl-mode.el outside of Emacs) was active in the Perl newsgroups and
very helpful, so I started with cperl-mode.el and never looked back.

But I think that making cperl-mode.el acceptable for users of
perl-mode.el is doable and might be worth the one-time effort.

> [...]
> Here are some additional observations:
>
> - cperl-mode.el sees more maintenance than perl-mode.el, in large part
>   thanks to the efforts of Harald Jörg.

I intend to continue maintaining cperl-mode.el, though I've been a bit
distracted this year.

> - The Perl community tends to favor cperl-mode over perl-mode.
>   perl-mode is seen as lacking in features compared to cperl-mode, and
>   no significant development has taken place to bridge the gap.

The extra features of cperl-mode are also a source of criticism... and
they come at a cost of some arcane elisp code.  Yet, it should be easier
to add options to switch *off* unwanted features in cperl-mode than to
add them to perl-mode.  So collecting such unwanted features, as
suggested later in this thread, is a good start!

> - cperl-mode.el used to be maintained outside of Emacs, but this is no
>   longer the case.  All relevant development has been merged into and
>   takes place in emacs.git.

In my opinion, this makes sense.  Several Emacs developers have
continually worked on cperl-mode.el to care for obsoletions or
modernizations.  I don't think a place outside of emacs.git could
provide this.

> - Perl, while historically important to hacker culture and still widely
>   used in some quarters (e.g. Debian), is seeing much less use today
>   than it used to.  This will negatively affect the amount of help we
>   can expect with maintaining these modes from others.

I guess that's true.  Also, neither Perl mode systematically tracked the
development of Perl for a decade or so, it will take some time to
re-build confidence.

> - Instead of maintaining perl-mode.el, I'd rather see that people worked
>   on a new perl-ts-mode.el.  From a web search, more than one treesitter
>   grammar exist; I have no idea which one is the most promising or how
>   mature any of them are.

https://github.com/tree-sitter-perl/tree-sitter-perl is very actively
developed, also following the "actual" Perl grammar in Perl's perly.y
source.  I consider it promising.  However, we've already identified a
shortcoming of the tree-sitter approach regarding Perl: Many Perl
extensions from CPAN _extend_ the syntax with new keywords and
constructs.  It is possible to accound for those extensions in Elisp,
even dynamically on a per-buffer basis, but very difficult to do for
tree-sitter grammars which need to be "built" from C-code and
"installed" as dynamic libraries.

-- 
Cheers,
haj

Previous Next

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