Does Emacs need two Perl modes?

Does Emacs need two Perl modes?

[Peter Oliver]

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]

The recent thread about cperl-mode being improved to understand new Perl syntax got me wondering…

Does it still make sense for Emacs to include two different Perl modes?  Is it time to make cperl-mode the default, and to deprecate perl-mode?

-- 
Peter Oliver

Re: Does Emacs need two Perl modes?

[Po Lu]

Peter Oliver <p.d.oliver@mavit.org.uk> writes:

> The recent thread about cperl-mode being improved to understand new
> Perl syntax got me wondering…
>
> Does it still make sense for Emacs to include two different Perl
> modes?  Is it time to make cperl-mode the default, and to deprecate
> perl-mode?

I think it makes sense, because otherwise a great deal of our valuable
time will be wasted debating which one to remove.

That alone makes keeping both worthwhile.

Re: Does Emacs need two Perl modes?

[Jens Schmidt]

On 2023-06-18  12:14, Peter Oliver wrote:

> Does it still make sense for Emacs to include two different Perl modes?  
> Is it time to make cperl-mode the default, and to deprecate perl-mode?

But then there are those, like me, who tried `cperl-mode', found it too 
(shamlessly generalizing here) electric, dwimmy, flashy, whatever, and 
who ruefully returned to `perl-mode', not wanting to invest any time to 
de-electrify, de-dwim, de-flash `cperl-mode'.

Why not leave `perl-mode' in self-maintenance mode as long as users are 
happy with it?

I won't say "no" when we talk about giving `cperl-mode' preference in 
`auto-mode-alist', though.

Re: Does Emacs need two Perl modes?

[Corwin Brust]

On Sun, Jun 18, 2023 at 7:56 AM Jens Schmidt
<jschmidt4gnu@vodafonemail.de> wrote:
>
> On 2023-06-18  12:14, Peter Oliver wrote:
>
> > Does it still make sense for Emacs to include two different Perl modes?
> > Is it time to make cperl-mode the default, and to deprecate perl-mode?

I was thinking about this just yesterday while whipping up this rather
naive patch for cperl (adding class/method/ADJUST and async/await):
https://bpa.st/VPAW4

I agree with Po - it's better not to spin wheels on this.   If someone
comes along with a consolidation patch that might be able to make both
perl-mode and cperl-mode users happy I'm sure lots of Perlers will
want to talk about how that would be for us -- in the meanwhile I
think there are both lower hanging and juicer fruits to stretch for.

[snip]
> Why not leave `perl-mode' in self-maintenance mode as long as users are
> happy with it?

+1

> I won't say "no" when we talk about giving `cperl-mode' preference in
> `auto-mode-alist', though.

Wow, that'd be *nice*.  Well before I'd learned any elisp at all I had
learned to type (defaias 'perl-mode 'cperl-mode) to make a fresh Emacs
ready to use :D  (I like cperl for the same reason you don't, lol)
While I'd be completely in favor of putting cperl-mode into
auto-mode-alist, I'm not sure it's TRT.  My sense has been that
perl-mode is wired up by default specifically because it's the less
frills choice, and thus more likely to perform well on older and
underpowered systems.

Enhancing cperl-mode (was: Re: Does Emacs need two Perl modes?)

[Harald Jörg]

Corwin Brust <corwin@bru.st> writes:

> I was thinking about this just yesterday while whipping up this rather
> naive patch for cperl (adding class/method/ADJUST and async/await):
> https://bpa.st/VPAW4

Nice!

Are you going to commit this?  I'm working on adapting cperl-mode to
Perl 5.38 as well, and unsurprisingly my patch looks very similar (but
isn't committed yet either).

> [...]
> My sense has been that perl-mode is wired up by default specifically
> because it's the less frills choice, and thus more likely to perform
> well on older and underpowered systems.

The performance was indeed a point of criticism when I started using
cperl-mode.  But that was in another century - I doubt that it is a
serious issue today.

But yes, perl-mode is less ambitious (e.g. it doesn't look into regular
expressions and doesn't offer code reformatting).  Its code is cleaner,
and it uses the "Simple Minded Indentation Engine", which in many cases
gets it right.

I guess that in some areas both Perl modes will converge (for example,
they are using the same test suite).  Once the tree-sitter grammar for
Perl is reasonably complete (it isn't today), both modes might want to
use that.  Also, I've been dreaming of adding support for Perl's syntax
extensions as minor modes which can be activated on top of perl-mode and
cperl-mode.
-- 
Cheers,
haj

Re: Enhancing cperl-mode (was: Re: Does Emacs need two Perl modes?)

[Corwin Brust]

Wonderful seeing this.. we are clearly thinking along very similar
lines! --more--

On Mon, Jun 19, 2023 at 9:34 AM Harald Jörg <haj@posteo.de> wrote:
>
> Corwin Brust <corwin@bru.st> writes:
>
> > I was thinking about this just yesterday while whipping up this rather
> > naive patch for cperl (adding class/method/ADJUST and async/await):
> > https://bpa.st/VPAW4
>
> Nice!
>
> Are you going to commit this?  I'm working on adapting cperl-mode to
> Perl 5.38 as well, and unsurprisingly my patch looks very similar (but
> isn't committed yet either).

I'd be very happy to defer to your efforts; if you would like to take
the lead on this I'm happy to help all I can, like please absorb what
you will from my version.  As you can see, I've not even bothered to
fix trivial things like line length in my rush to see the new keywords
"light up" :)

If you aren't excited by this prospect then sure, I'll do my best to
make my patch tidy and so forth.  (Starting checking for a rebase vs
master, I guess; it's effectively made against the release branch).

>
> > [...]
> > My sense has been that perl-mode is wired up by default specifically
> > because it's the less frills choice, and thus more likely to perform
> > well on older and underpowered systems.
>
> The performance was indeed a point of criticism when I started using
> cperl-mode.  But that was in another century - I doubt that it is a
> serious issue today.

I agree with you, but then there's the whole "survivorship bias" as
was just mentioned.  I *do* have a fairly speedy workstation..

[..]

> I guess that in some areas both Perl modes will converge (for example,
> they are using the same test suite).  Once the tree-sitter grammar for
> Perl is reasonably complete (it isn't today), both modes might want to
> use that.  Also, I've been dreaming of adding support for Perl's syntax
> extensions as minor modes which can be activated on top of perl-mode and
> cperl-mode.

I have the same theory/vision.

I have long term vision/hopes, and too, I've also been of adding
support for syntax.pm keywords via minor-modes, probably via some new
hooks?  I have the idea of a "amada" of cperl-syntax-FOO minor modes
mirroring the CPAN modules using syntax.pm.  I hooks call while
setting up font-locking could be a feasible way, but I'm still trying
to parse the parsing (sorry if I crashed ur tokenizer there).  More
specifically, I'm not clear on the interaction/use subrs vs calling
hooks to add/tweak font-locking and what all, exactly, is happening at
compile time.  (Is this effectively impossible? Will we wreck
performance?)

I do know I haven't found an incantation to make updating the
font-lock setup "live"; I have to re-launch Emacs as I go to test
these changes.

Excited to hear the extent you'd like to work on this!

Re: Enhancing cperl-mode

[Harald Jörg]

Corwin Brust <corwin@bru.st> writes:

> Wonderful seeing this.. we are clearly thinking along very similar
> lines! --more--

:D

> I'd be very happy to defer to your efforts; if you would like to take
> the lead on this I'm happy to help all I can, like please absorb what
> you will from my version.  As you can see, I've not even bothered to
> fix trivial things like line length in my rush to see the new keywords
> "light up" :)

I'll then happily take your patch as an additional check list that I
haven't missed anything!

> [...]
>> Also, I've been dreaming of adding support for Perl's syntax
>> extensions as minor modes which can be activated on top of perl-mode and
>> cperl-mode.
>
> I have the same theory/vision.
>
> I have long term vision/hopes, and too, I've also been of adding
> support for syntax.pm keywords via minor-modes, probably via some new
> hooks?  I have the idea of a "amada" of cperl-syntax-FOO minor modes
> mirroring the CPAN modules using syntax.pm.

...or more generally, stuff like Moose where the "keywords" (has,
extends etc) technically are imported subroutines, but they "feel" like
keywords.

> I hooks call while
> setting up font-locking could be a feasible way, but I'm still trying
> to parse the parsing (sorry if I crashed ur tokenizer there).  More
> specifically, I'm not clear on the interaction/use subrs vs calling
> hooks to add/tweak font-locking and what all, exactly, is happening at
> compile time.  (Is this effectively impossible? Will we wreck
> performance?)
>
> I do know I haven't found an incantation to make updating the
> font-lock setup "live"; I have to re-launch Emacs as I go to test
> these changes.

For font-locking, there are two mechanisms which can be used by minor
mode hooks: First, there's font-lock-add-keyword /
font-lock-remove-keyword which works for all, well, "keywords" (which
most of the syntax extensions provide).  Second, the MATCHER in
font-lock can be a function (as already used in the ominous
cperl-fontify-update) which can work on variables which in turn can be
modified by minor modes, or even hooked into.  So yes, it can be done
"live", but it needs preparation.  I made a proof-of-concept, but the
implementation is crap.  It still hangs around at
https://github.com/HaraldJoerg/cperl-mode/, but I more or less stopped
working on it when I started to contribute to the savannah repository.

Open a file which uses Moose, or Zydeco, or Function::Parameters, or any
of the keyword sets it understands... and it automatically highlights
the extensions.  Instead of minor modes it uses commands
cperl-activate-keyword-set, cperl-deactivate-keyword-set, and
cperl-reset-keyword-sets.  This is a bad idea, but back then I didn't
understand minor modes.

I'm a bit stuck with indentation, where the code in cperl-mode is
messy.  Keywords that are followed by a { code block } sometimes need a
semicolon, and sometimes they don't, and cperl-mode needs to understand
this in order to decide whether the next line is a continuation line or
a new statement.

> Excited to hear the extent you'd like to work on this!

I am interested to work on this, only have been distracted a lot by
non-elisp projects.  The upcoming Perl 5.38 made me re-activate my elisp
activities.  I'm also interested to get cperl-mode published via ELPA,
so that it can be used once Perl 5.38 is out.
-- 
Cheers,
haj

Re: Enhancing cperl-mode

[Corwin Brust]

On Mon, Jun 19, 2023 at 11:41 AM Harald Jörg <haj@posteo.de> wrote:
>
> Corwin Brust <corwin@bru.st> writes:

> "live", but it needs preparation.  I made a proof-of-concept, but the
> implementation is crap.  It still hangs around at
> https://github.com/HaraldJoerg/cperl-mode/, but I more or less stopped
> working on it when I started to contribute to the savannah repository.
>

POC is much; thank you, friend I am warned  :D
I will report back.

>
> I'm a bit stuck with indentation, where the code in cperl-mode is
> messy.  Keywords that are followed by a { code block } sometimes need a
> semicolon, and sometimes they don't, and cperl-mode needs to understand
> this in order to decide whether the next line is a continuation line or
> a new statement.

I will come back on this another time (if someone wiser doesn't reveal
more than --I think-- I know before that).

> activities.  I'm also interested to get cperl-mode published via ELPA,
> so that it can be used once Perl 5.38 is out.

Sounds like a good plan and I'm proud to be a part of it <g>

Indeed,
> --
> Cheers,
> haj
Corwin

Re: Does Emacs need two Perl modes?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > But then there are those, like me, who tried `cperl-mode', found it too 
  > (shamlessly generalizing here) electric, dwimmy, flashy, whatever, and 
  > who ruefully returned to `perl-mode', not wanting to invest any time to 
  > de-electrify, de-dwim, de-flash `cperl-mode'.

Nobody has an obligation to do it.  Nonetheless, the Emacs developers
still do have the option of doing it.

Adding options to Cperl mode that will make it as convenient as Perl
mode (or perhaps even more so) for users like you may be less work in
the long run than maintaining Perl mode as well.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)