From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Harald =?UTF-8?Q?J=C3=B6rg?= Newsgroups: gmane.emacs.bugs Subject: bug#66050: Making perl-mode.el obsolete Date: Sun, 24 Sep 2023 21:29:08 +0000 Message-ID: <87ttrjw997.fsf@oook.m.uunet.de> References: <87il88vjvd.fsf@sappc2.fritz.box> <87fs3cv7mg.fsf@sappc2.fritz.box> <874jjka15f.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="40555"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 66050@debbugs.gnu.org, Jens Schmidt , Stefan Kangas To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Sep 24 23:30:25 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1qkWgK-000AR3-V3 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 24 Sep 2023 23:30:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qkWfn-0006Rz-Om; Sun, 24 Sep 2023 17:29:51 -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 1qkWfm-0006Rj-S6 for bug-gnu-emacs@gnu.org; Sun, 24 Sep 2023 17:29:50 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qkWfm-0005xj-K7 for bug-gnu-emacs@gnu.org; Sun, 24 Sep 2023 17:29:50 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qkWfy-00039r-95 for bug-gnu-emacs@gnu.org; Sun, 24 Sep 2023 17:30:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Harald =?UTF-8?Q?J=C3=B6rg?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 24 Sep 2023 21:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66050 X-GNU-PR-Package: emacs Original-Received: via spool by 66050-submit@debbugs.gnu.org id=B66050.169559097312082 (code B ref 66050); Sun, 24 Sep 2023 21:30:02 +0000 Original-Received: (at 66050) by debbugs.gnu.org; 24 Sep 2023 21:29:33 +0000 Original-Received: from localhost ([127.0.0.1]:43688 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qkWfU-00038o-Tb for submit@debbugs.gnu.org; Sun, 24 Sep 2023 17:29:33 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:44899) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qkWfP-00038X-Mh for 66050@debbugs.gnu.org; Sun, 24 Sep 2023 17:29:31 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id B152F240029 for <66050@debbugs.gnu.org>; Sun, 24 Sep 2023 23:29:09 +0200 (CEST) Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RtzfD5zXtz9rxL; Sun, 24 Sep 2023 23:29:08 +0200 (CEST) In-Reply-To: (Stefan Monnier's message of "Sun, 24 Sep 2023 11:58:48 -0400") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:271273 Archived-At: Stefan Monnier writes: >> It would need more work. An important step is to identify the features >> we should be able to switch off per customization. I am somewhat >> reluctant to add more options to cperl-mode if they can't be bundled >> (like `cperl-hairy' does): The possible combinations of options are a >> nightmare to document, to test, and also to learn for new users. > > BTW, "bundling" is what Custom themes are for. > At least to solve the "learn for new users" side of the problem. > Not to say we should add more options (or more fine-grained options), > but it can be helpful to simplify the code (a.g. avoid having to test both > `cperl-dont-be-hairy` and `cperl-highlight-variables-indiscriminately`). Agreed. cperl-mode has many customization options I've never tried (nor fully understood). These days, "Perl Best Practices" (the book, almost 20 years old by now) and perltidy (the tool) could be taken as guidelines for new users. Unfortunately, Perl has lots of very knowledgeable old users, some of which are rather religious in their opinions - and perltidy lets all of them have it their way. I *guess* that for new users a manual or tutorial would be helpful, but don't know whether I can spend the time to write it (nor whether I'm the right person to do it). >> Yes, that should be covered. The option name is somewhat ... weird, but >> I didn't find enough motivation to change it (or to fiddle with >> font-lock-level 3, which would be more in line with other modes). > > That's a downvote for font-lock levels from me. Oh - I guessed that ignoring font-lock-levels was one of the things you meant when you wrote that cperl-mode is different than other major modes... >> This seems doable. The easy way is to make cperl-hash-face and >> cperl-array-face customizable so that they can be "downgraded" to >> font-lock-variable-name-face. > > They're faces, so they are already customizable, e.g. via Custom themes. Sure. I think that creating custom themes might be a bit beyond what *users* of c?perl-mode might want to do (I myself never did that). Emacs comes with themes which look better than anything I could create - and adding four extra faces which fit these palettes needs experience I don't have. >>> 3. Variable sigils ("$", "%", "@") should not be highlighted at all. >> I doubt that this is worth the effort in cperl-mode... and guess it >> should be tolerable. The sigil *is* part of the variable, after all. > > FWIW, I agree. We don't have to satisfy all the wishlist items of > previous `perl-mode` users. >>> 4. Builtins ("shift", "ref", "defined") should not be highlighted at >>> all. >> This is an area where cperl-mode is a bit untidy. It has two different >> faces for builtins, depending on whether they can be overridden by user >> functions with the same name. Many occur in two lists for >> fontification, only the first one ever applies. This has *some* >> justification because builtins allow sloppy syntax (omitting >> parentheses). > > What part of this is "untidy" or "a mess"? I can see why you'd say it > w.r.t Perl having those fine distinctions, but the corresponding > features in `cperl-mode` seem to just reflect Perl's syntax&semantics. > Or is it the implementation part to distinguish those two kinds of > builtins messy? It is the implementation. There's some overlap in the "regex-opt" lists of keywords (e.g. "require", "for"). Some of the "builtin functions" are actually binary operands ("eq" and friends). "use" is fontified as a keyword, but "no" (which is sort of "do not use") is fontified as a non-overridable function. The builtins use font-lock-type-face, which isn't appropriate. "shift" is fontified as non-overridable, but it can be overridden in recent Perl versions. An overhaul of all of this would take some time, and probably a thick skin to weather the storm caused by cperl-mode users who are accustomed to the current colors. >> When we clean up this mess, adding a way to not >> highlighting them at all should not be too difficult. > > AFAIK that can also be solved by changing the faces' appearance, hence > without changing the code. Agreed. >>> 5. Package names should be highlighted as font-lock-constant-face rather >>> than font-lock-function-face. >> >> perl-mode uses font-lock-function-name-face in the package declaration >> but font-lock-constant-face in 'use' statements. I can't say whether >> that is intentional. >> >> Someone once suggested to use font-lock-type-face (because packages >> usually are classes, and classes are sort-of types). This is one of the >> cases where I doubt that adding more options will actually improve >> things. > > I think it's more important here to choose a "meaningful/consistent" > behavior than to reproduce what was done historically in `perl-mode` or > `cperl-mode`. Agreed! >>> 7. Regexps should be highlighted as font-lock-string-face. >> This can be added as an option with some effort. Regexps aren't >> strings, but alas, almost no syntax highlighter takes the same effort as >> cperl-mode to display them. > > Here again, I believe it's a small matter of changing faces. It is a bit more than _changing_ faces. In the match part, cperl-mode highlights metacharacters (|) as keywords, [] as functions, and character classes (\d \D \s and friends) as types. The substitution part can be actual Perl code, and cperl-mode will fontify it as Perl code. For example, the following substitution is rather colorful in cperl-mode but (sorry) dull in perl-mode: s/\d+|[IVXLCDM]+(\D)/sqrt(2) . "_$1_"/eri; Making these highlightings optional would, as far as I know, require to define an extra set of faces, which could then be mapped either to their cperl-mode values (cperl-mode style) or all to font-lock-string-face (perl-mode style). -- Cheers, haj