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 18:32:56 +0100 Message-ID: <87y2efqek7.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> <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="4344"; 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 18:37:54 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 1lOOV0-000130-J1 for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Mar 2021 18:37:54 +0100 Original-Received: from localhost ([::1]:50484 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lOOUz-0002jF-Ji for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Mar 2021 13:37:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44702) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOOQM-0007hZ-0p for emacs-devel@gnu.org; Mon, 22 Mar 2021 13:33:06 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:56223) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOOQI-0000mV-Sb for emacs-devel@gnu.org; Mon, 22 Mar 2021 13:33:05 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 65EC4160061 for ; Mon, 22 Mar 2021 18:32:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1616434378; bh=Y+2TVKriYbOkQFkNIZnFcoyKbrGWGf9uORoXrpeE/n4=; h=From:To:Cc:Subject:Date:From; b=lBR12mVee8r8xwTahxRJ6f8/SQFaTXEa8yB3J5+3+yqPodaF2JQxMdZNfZNrBKIjj gO9D7erzRiZXRrKO5woHAuaiZRsI8ZlMMqE3zniSFjzWV8I5154goBpt6nzU8P1WYs qHhOzkN5rmIUuVAGyq7G7nobSqGI3dpH3li2qHQKGEnE5oi9k5Qozl8mrrVRV2Q8fX YNInHv1yVz9o2f9wdhO1lNxRZvOXKY/M9t8EPn+y5ftoAVQrSiVj9PudyFoSQQ7XBL BCUXb0XwAk2unXaoqm9fREAKdJWpoSZozQ9qTeWmgi5tPH3hgbLOrgzStCI/R5c/x6 AMWuAbVR6f1iQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4F41mT42Cgz6tmX; Mon, 22 Mar 2021 18:32:57 +0100 (CET) In-Reply-To: (Stefan Monnier's message of "Mon, 22 Mar 2021 10:48:07 -0400") 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, 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:266764 Archived-At: Stefan Monnier writes: >>> For imenu and font-lock, I can't see why not. >> Nice. > > Beware: I might just be blinded by optimism. Optimism is my second name! (My first name is "Unwarranted") >> 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 would prefer this behavior (not being able to disable it) for things that come with new Perl versions, but not for extensions. If you run an older Perl version (which happens all the time because distributions take time to catch up) it might behave strange, but I think that this is ok as a reminder that "at some time you will need to change this anyway". For extensions it is really difficult to find out whether they might collide with another extension. Sometimes new extensions quickly rise in popularity but need different handling. A typical example is exception handling with Try::Tiny which is lightweight and nice and all, but it comes with the pitfall that the try block, different from all other extensions for exception handling with try/catch/finally, _requires_ a semicolon. > I think the most natural/convenient form of an extension that can be > enabled or not would be as a minor mode. I've been hoping that this is acceptable. It brings a lot of infrastructure and therefore consistency for users. > 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). I am leaning towards a completely separate file, but maybe not right now. In both cases the adventurous users who're using cperl-mode directly from the repository will then need to pick two files instead of one. If, one day, cperl-mode is made available via ELPA, this should not necessary require moving perl-mode to elpa as well. >> [...about discrepancies in syntax highlighting ...] > > I think such discrepancies are just misfeatures, so it would be nice to > fix them (ideally by choosing that one that seems less arbitrary). Agreed. > Using type-face for `my` or `local` doesn't seem useful, so we > should probably change them to keyword. That was my first thought as well. But then, the declarators appear in places where other languages have their types. And then again, there are (various, of course) Perl extensions which provide a type system for Perl, so you can write "my Str $string" or even "my ArrayRef[Int] $ref". I guess I need to *see* it for some time to find out whether in "my Str" both parts should have the same color or better shouldn't. >> 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. I agree. CPerl mode uses different faces for "overridable" and "nonoverridable" builtins, but this distinction isn't that valuable these days (and it also changes between Perl versions). I've also received feedback that this distinction should go away. IIRC the non-"standard" colors of CPerl mode occasionally annoyed people which use Emacs with many different programming languages. > [...] >> - 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. > >> [...] > > 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". ] Good point! For the moment I'll be a coward and avoid that decision by honing the regular expressions with that differnce in mind :) >> 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 ;-) That's probably an acceptable way forward. Time to roll up my sleeves ... and grab some more coffee. -- Cheers, haj