[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#66050: Making perl-mode.el obsolete
From: |
Harald Jörg |
Subject: |
bug#66050: Making perl-mode.el obsolete |
Date: |
Sat, 23 Sep 2023 22:13:41 +0000 |
Stefan Kangas <stefankangas@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
bug#66050: Making perl-mode.el obsolete, Stefan Monnier, 2023/09/18
bug#66050: Making perl-mode.el obsolete,
Harald Jörg <=