From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Harald_J=C3=B6rg?= Newsgroups: gmane.emacs.devel Subject: Re: Enhancing cperl-mode Date: Mon, 19 Jun 2023 16:41:22 +0000 Message-ID: <87352nbe19.fsf@oook.m.uunet.de> References: <16da6ae7-66d8-fc43-cb84-6d104d3a2ef8@mavit.org.uk> <4d18a051-07d5-fba7-1c36-ae2eb72bf71c@vodafonemail.de> <878rcfbjwg.fsf_-_@oook.m.uunet.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4821"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Corwin Brust Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jun 19 18:42:18 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qBHxJ-00013q-R4 for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Jun 2023 18:42:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qBHwX-0004g7-8z; Mon, 19 Jun 2023 12:41:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qBHwV-0004fa-8T for emacs-devel@gnu.org; Mon, 19 Jun 2023 12:41:27 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qBHwT-0000yA-06 for emacs-devel@gnu.org; Mon, 19 Jun 2023 12:41:27 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 0DAC4240027 for ; Mon, 19 Jun 2023 18:41:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1687192883; bh=ot7qi2/tXa4yIDB9OLzDoeEPsQ3uj/ZzZ3SiN6mzzUs=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=c3p1zW27g6cTfd248S3kul82TD5KzbbQPcNZUsLr6ktuHNGg/QxZXtjR96CeWLKit lSMQ9tHWZQ2cyxq4wANu+lUnxndlcwW9aIUVj892VWkC/iEEdrH1Rqwn6Jz7TeuQM6 GqDRvMJtmwwdUGIrMg1dSX1TfZVilgROlvYwINgRupJsXwTf8uah3YGoNMKhKDyaYz 4xW3Uun30HGL2Rxbn9W/g8VGhQwXbsm+KCGOYTe0rRy4bg5oLw43oSr4Mx1X9Q/s7Q UX7INPFnp59Tn60Hn4M2eO6M/XtbWr5LpXFohZUJXl0DakALElDFpbe+2ogwoDoV+A 5mxml9va3y3/g== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4QlFry388rz9rxS; Mon, 19 Jun 2023 18:41:22 +0200 (CEST) In-Reply-To: (Corwin Brust's message of "Mon, 19 Jun 2023 09:58:46 -0500") Received-SPF: pass client-ip=185.67.36.65; envelope-from=haj@posteo.de; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:307052 Archived-At: Corwin Brust 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