From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: haj@posteo.de (Harald =?utf-8?Q?J=C3=B6rg?=) Newsgroups: gmane.emacs.devel Subject: Re: Handling extensions of programming languages (Perl) Date: Mon, 22 Mar 2021 15:08:53 +0100 Message-ID: <878s6fs2kq.fsf_-_@hajtower> References: <87o8ff560t.fsf@hajtower> <87im5lhi6i.fsf@rfc20.org> <87r1k94cnx.fsf@hajtower> <20a4ef1c-beaf-1d63-b984-12be9a856c86@gmail.com> <87h7l43fa1.fsf@hajtower> <87blbc33tm.fsf@hajtower> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22502"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Mar 22 15:56:52 2021 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 1lOLz9-0005jp-LX for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Mar 2021 15:56:51 +0100 Original-Received: from localhost ([::1]:41892 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lOLz8-00048G-Ka for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Mar 2021 10:56:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37136) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOLEx-00047K-74 for emacs-devel@gnu.org; Mon, 22 Mar 2021 10:09:07 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:39885) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOLEs-0000MO-DA for emacs-devel@gnu.org; Mon, 22 Mar 2021 10:09:06 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 6775C2400FD for ; Mon, 22 Mar 2021 15:08:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1616422134; bh=Xbe6/Sy5y0aUc6qfCbYc6qTHXd5Urdt0gGD8QNJ7s08=; h=From:To:Cc:Subject:Date:From; b=QZItpKCVddavuBoBEz0/L4cjE8aQ4hlivmFizArjiE1D8tBfzkBWHDA46aip4fg42 CWkFX8Edt2si/9eMz00jEsHte4e8rIWQvdBhd+cm33uJQmN1cexj7mJMWRvfqg5jMa GoQuk95YVfyFS1j7y+8emrAugFisO5On+EDhSaX84WZ8TdqLeqPnHovkYaC0a1lsyo nFTcMICl/cRjv2eehy/ixPx8T0uKFuemsfpws+uq4gfv7NyqFnTFeEy/qwLGnOu66Q ODZ9x7voGUCCo1LzSznM4/jvgUgoZFFYnP3xkHnLw1uwvujCNU1EXih8D4Sm+/Pdpz fQMhRox9PVY+Q== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4F3xF145sWz6tmq; Mon, 22 Mar 2021 15:08:53 +0100 (CET) In-Reply-To: (Stefan Monnier's message of "Sun, 21 Mar 2021 13:59:29 -0400") Received-SPF: pass client-ip=185.67.36.66; envelope-from=haj@posteo.de; helo=mout02.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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:266754 Archived-At: [I've added "Perl" to the subject since this is going specific] Stefan Monnier writes: > [...] >> Your last parens touch another interesting aspect: Can that stuff be >> used by cperl-mode.el _and_ perl-mode.el? > > For imenu and font-lock, I can't see why not. Nice. How would the set of shared functions be distributed? In a new, separate file which both modes `require'? That file would then also be part of a CPerl distribution on ELPA, I guess? In my opinion, it would make sense in any case to use the "perl" prefix for shared stuff. >> Well, as it turns out, the font-lock stuff "works" for both. It looks a >> bit weird with Perl mode because the "new" keywords like `method' have >> different faces than the "old" ones like `my'. > > I'm not sure why that would be: AFAICT, both `perl-mode` and > `cperl-mode` highlight keywords (like `sub`, `if`, `for`, ...) using the > `font-lock-keyword-face` (they generally use fairly different faces, but > this is a part where they agree ;-). Overall they agree, but there are differences in details (some might even be unintended). For new keywords and syntax there's indeed no need to use different faces, but they should be somewhat consistent to existing highlighting. Some results from first tests and debugging: - Declarators (like "my") are type-face in perl-mode, keyword-face in cperl-mode. I noticed this because the new "has" is fontified by perl-mode (though it isn't part of Perl) and the additions don't override it. CPerl mode abuses type-face for builtin functions, I wonder how much stir it makes if this is changed. - Names of packages are not fontified in perl-mode when they are `use'd or `require'd (on closer inspection, this is probably unintended: The first capture group is either an empty string or punctuation/space and should be shy). - In cperl-mode, ':' is a symbol, but a punctuation character in perl-mode. This makes interpretation of "\\_<" different. Perhaps changing cperl-mode's syntax table to making ':' punctuation would be the way to go - but punctuation also has its deficits for perl-mode, as apparent in "package Foo::Bar", so i would need more work. I haven't investigated further. >> For imenu, things are different: Perl mode uses >> `imenu-generic-expression', whereas CPerl mode uses a rather complex >> `imenu-create-index-function ', so that it can prepend the current >> namespace to the name of functions. > > If you code uses `add-function` on `imenu-create-index-function` it > should work in both cases (`perl-mode` simply keeps the default value > of `imenu-create-index-function` which is the function that implements > `imenu-generic-expression`). Ah, yes, of course. I didn't think of that (nor read the docs). The two modes have different styles how they present their results, though. Adding new entries needs some "rearrangement" to put it into the right place(s) in the index. >> And as for indentation... I'd say the code in both modes needs to catch >> up with current perl before we consider extensions. Maybe they could >> share functions or regular expressions how to find the beginning of a >> function, or how to identify closing braces which terminate a statement: >> The specification for this logic comes from Perl and should be the same >> for both modes. > > Consolidation between the two modes is progress, so you got my vote. Thanks! -- Cheers, haj