From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Handling extensions of programming languages (Perl) Date: Mon, 22 Mar 2021 10:48:07 -0400 Message-ID: References: <87o8ff560t.fsf@hajtower> <87im5lhi6i.fsf@rfc20.org> <87r1k94cnx.fsf@hajtower> <20a4ef1c-beaf-1d63-b984-12be9a856c86@gmail.com> <87h7l43fa1.fsf@hajtower> <87blbc33tm.fsf@hajtower> <878s6fs2kq.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="26068"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: haj@posteo.de (Harald =?windows-1252?Q?J=F6rg?=) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Mar 22 16:04:59 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 1lOM71-0006f4-Af for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Mar 2021 16:04:59 +0100 Original-Received: from localhost ([::1]:39616 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lOM70-0006kx-82 for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Mar 2021 11:04:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47656) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOLqv-000811-MB for emacs-devel@gnu.org; Mon, 22 Mar 2021 10:48:22 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:34220) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOLqq-0006KY-34 for emacs-devel@gnu.org; Mon, 22 Mar 2021 10:48:18 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id BB54B80A59; Mon, 22 Mar 2021 10:48:10 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 28F80805EF; Mon, 22 Mar 2021 10:48:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1616424489; bh=SVGg5zapRLSALuxg/aLKmJyGkejR/GgUtKognhpWUF4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=nbNjEphGdrHSjtjkit0iWVYxl2z4LIq2okC6aN9JlvEh4Mq34RMMRb0CYVCUbdtLW QOmrgxYlq++fXNkg5TVrKDn7njhZ6THVnBTsw0Et0L0Akt9YeLfNrX2t3vWbd5/siA lit5iWElTC57H2oUqrSiDX+ctJZopedeE0JqADIwQGGokdNA/j4s3UPLHIt7QYmOnH yvhN31/VUh/q8V3zlZ1ZZkhzJiiEgXIp2WgdA4lssHqV6AlAMle7GD6+GwAhqd6nlr i3BVUQJDx+r/6+pNmzd198rtHln8nKFX1pGc9p/FKngPuRML3P9KC+UhhtWh/eEpxg uSy/w3pC5E74Q== Original-Received: from alfajor (unknown [216.154.43.249]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E053F1202D7; Mon, 22 Mar 2021 10:48:08 -0400 (EDT) In-Reply-To: <878s6fs2kq.fsf_-_@hajtower> ("Harald =?windows-1252?Q?J=F6rg?= =?windows-1252?Q?=22's?= message of "Mon, 22 Mar 2021 15:08:53 +0100") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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:266755 Archived-At: >> For imenu and font-lock, I can't see why not. > Nice. Beware: I might just be blinded by optimism. > How would the set of shared functions be distributed? Good question. I guess it largely depends on the size, the way you intend to distribute it, the possible bad interaction with other Perl extensions, ... E.g. for an extension which doesn't collide with any other known Perl extension, you could imagine enabling it by default (and maybe even forego offering a way to disable it). I think the most natural/convenient form of an extension that can be enabled or not would be as a minor mode. And as for where to put the code, it could be in a completely separate file, or directly in `perl-mode.el` (which `cperl-mode.el` could require: it's a mere 50kB compared to `cperl-mode.el`s 300kB). > 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. I think such discrepancies are just misfeatures, so it would be nice to fix them (ideally by choosing that one that seems less arbitrary). Using type-face for `my` or `local` doesn't seem useful, so we should probably change them to keyword. > CPerl mode abuses type-face for builtin functions, I > wonder how much stir it makes if this is changed. Try it ;-) Unsurprisingly, I vote for using the font-lock-builtin-face for them. > - 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). Sounds like a bug, indeed. > - In cperl-mode, ':' is a symbol, but a punctuation character in perl-mode. Ah, right, this could make it significantly harder to share code between the two major modes. I don't think either choice is clearly superior, but we should make them agree on the syntax-table. > 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. I suspect it can also impact other parts of the code (since it impacts things like `forward-sexp`). I think my recommendation would be to change `perl-mode` to agree with `cperl-mode` since `perl-mode.el` is much smaller so the amount of breakage should be correspondingly smaller. [ Also, from a user's point of view it's good that `C-M-x` skips over the whole of "Foo::bar" instead of stopping after "Foo". ] > 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. Then again, you could focus on making it "work well" for one of the modes (presumably `cperl-mode`) and content yourself with "works" for the other ;-) Stefan