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: Please do not deprecate perl-mode in favour of cperl-mode Date: Sun, 03 Dec 2023 13:20:56 +0000 Message-ID: <875y1fzakn.fsf@oook.m.uunet.de> References: <5d846dd1b7a8b557073b317863bc590a@purelymail.com> <83ttoz7ohj.fsf@gnu.org> <432593e94d8f9316cce77962a0598c23@purelymail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31500"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , "Paul W. Rankin" To: "Paul W. Rankin" via "Emacs development discussions." Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 03 14:21:34 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 1r9mPe-0007yf-Pm for ged-emacs-devel@m.gmane-mx.org; Sun, 03 Dec 2023 14:21:34 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r9mPA-0004Nd-Fd; Sun, 03 Dec 2023 08:21:04 -0500 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 1r9mP9-0004NS-6U for emacs-devel@gnu.org; Sun, 03 Dec 2023 08:21:03 -0500 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 1r9mP5-0005fy-55 for emacs-devel@gnu.org; Sun, 03 Dec 2023 08:21:02 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id E1CAF240028 for ; Sun, 3 Dec 2023 14:20:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1701609656; bh=7C7fNqCrWssFjeXGXn1vpUCN2TqQDVhNo0SC9YarJt0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=jA+Y0h8bI3Xnv+bfAP8PQ0k1KgpTTBo0cH9Z3U4BR4/3lx5kuwyWTU5TuESVsl8Us v3nXDcna1CuFB62F3iuAI0uWvB9wuoUg079W+sK+0p0HsMZ05K1cjEx98emMF7E8rz sgpNkoRvEXvBn6wgEf8ECLkf2UzGSmpFeBqTmHhy04rPxaVxqibz0sCKumP9vkT5+E I8VAvbhXp4V7tREodrvvo1DBB6jqNNtXbKp3J64WkpThFnYheKU8qC59U+diFXNRuy bLoEDWn2es3aDND+UiSGOzvlfX36o9uIRJgHZx20sAQjkLtuJ8aMjjg87d5U5g/AuO /x3ThE3iUOugA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4SjnVc3djkz6txb; Sun, 3 Dec 2023 14:20:56 +0100 (CET) In-Reply-To: <432593e94d8f9316cce77962a0598c23@purelymail.com> (Paul W. Rankin's message of "Sun, 03 Dec 2023 18:21:19 +1000") Received-SPF: pass client-ip=185.67.36.65; envelope-from=haj@posteo.de; helo=mout01.posteo.de X-Spam_score_int: -53 X-Spam_score: -5.4 X-Spam_bar: ----- X-Spam_report: (-5.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=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable 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:313490 Archived-At: "Paul W. Rankin" via "Emacs development discussions." writes: > On 2023-12-03 17:07, Eli Zaretskii wrote: >>> C Perl Mode has several quirks that make it behave unlike a normal >>> Emacs >>> Major mode, including: >>> - unorthodox code indentation >>> - behaviour of TAB on region does not perform indent-region >>> - use of specific faces instead of font-lock-* faces >> What if CPerl mode would optionally support the above as well? >> Would >> it be acceptable then for you to switch? > > I would love to take advantage of whatever CPerl Mode advantages exist > if CPerl Mode could do the things that Perl Mode does. And I think it > should be easy and clear to the user how to set these options. > > Here's a minimal example of perl code that indents in a way I find > unexpected in CPerl Mode (e.g. the trailing paren should line up with > the start of the statement): > > $r->get( > '/test' > ); This is how Perl mode indents it, isn't it? CPerl mode has several predefined indentation styles, a recent addition is to indent according to Damian Conway's "Perl Best Practices". This can be activated with (cperl-set-style "PBP"). It _should_ be the default these days, but it isn't for compatibility reasons. in PBP style, indentation is like this: $r->get( '/test' ); > I also found weird behaviour with Electric Pair Mode; when point is at > `|' here and `{' is inserted, I get `{|}}', which seems incorrect > because it unbalances the braces (Perl Mode inserts `{|}'): > > $r->get( > '/test', > sub { > | > } > ); This would indeed be a bug. Unfortunately, I can not reproduce it. If you have a recipe to demonstrate the bug, then a bug report would be welcome! > One more thing... > > CPerl Mode has a feature the applies the `underline' face to leading > whitespace before point and there doesn't appear to be an option to > disable this. It's not a huge thing, but Whitespace Mode provides this > feature and it's just a weird addition to hardcode and not use > something called `cperl-leading-whitespace-face'. This seems to have been fixed already by Stefan Kangas. It used to be the customizable face `cperl-invalid-face' but is gone now, in favor of the option `show-trailing-whitespace'. >>> I don't wish to dampen the enthusiasm of the originator of this >>> Perl->C >>> Perl idea, but I would implore you to please first address C Perl >>> Mode's >>> shortcoming as a 1:1 replacement for Perl Mode before the >>> baby/bathwater? C Perl Mode should at least work as well as Perl Mode >>> before deprecation is considered. >> Deprecation doesn't mean removal. Even obsolete packages are still >> available, and some of them will not be removed. So if you insist on >> using Perl mode, you will be able to do so for the years to come, even >> if we deprecate and obsolete it. > > This is cool. My opinion is that CPerl Mode is (currently) too weird > and idiosyncratic to be Emacs's default mode for perl (e.g. what the > heck is `cperl-hairy' or `cperl-fontify-m-as-s'?) and will likely lead > to more confusion than productivity/joy. But maybe if someone wants to > take a hard look at CPerl Mode from a user friendliness perspective? I find the documentation of `cperl-hairy' and its customization interface not too bad - but I am the wrong person to ask. Anyways: CPerl mode has accumulated lots of options over the years. Many of them, for example `cperl-fontify-m-as-s', can be safely ignored and left at their defaults. We will have more options to allow CPerl mode to look like Perl mode. `cperl-fontify-trailer' is the first of the new options, to account for the different treatment of text after __END__ or __DATA__ tokens. -- Cheers, haj