all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Corwin Brust <corwin@bru.st>
To: "Harald Jörg" <haj@posteo.de>
Cc: emacs-devel@gnu.org
Subject: Re: Enhancing cperl-mode (was: Re: Does Emacs need two Perl modes?)
Date: Mon, 19 Jun 2023 09:58:46 -0500	[thread overview]
Message-ID: <CAJf-WoR5Rs3C4Gmy0Be56XpdhZu-N_72WK97BN3hyswO1j=dHQ@mail.gmail.com> (raw)
In-Reply-To: <878rcfbjwg.fsf_-_@oook.m.uunet.de>

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	other threads:[~2023-06-19 14:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-18 10:14 Does Emacs need two Perl modes? Peter Oliver
2023-06-18 12:15 ` Po Lu
2023-06-18 12:56 ` Jens Schmidt
2023-06-19 13:01   ` Corwin Brust
2023-06-19 14:34     ` Enhancing cperl-mode (was: Re: Does Emacs need two Perl modes?) Harald Jörg
2023-06-19 14:58       ` Corwin Brust [this message]
2023-06-19 16:41         ` Enhancing cperl-mode Harald Jörg
2023-06-19 21:49           ` Corwin Brust
2023-06-20  2:57   ` Does Emacs need two Perl modes? Richard Stallman

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='CAJf-WoR5Rs3C4Gmy0Be56XpdhZu-N_72WK97BN3hyswO1j=dHQ@mail.gmail.com' \
    --to=corwin@bru.st \
    --cc=emacs-devel@gnu.org \
    --cc=haj@posteo.de \
    /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.