emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Corwin Brust
Subject: Re: Enhancing cperl-mode (was: Re: Does Emacs need two Perl modes?)
Date: Mon, 19 Jun 2023 09:58:46 -0500

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!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]