From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#66050: Making perl-mode.el obsolete Date: Sun, 24 Sep 2023 18:12:49 -0400 Message-ID: References: <87il88vjvd.fsf@sappc2.fritz.box> <87fs3cv7mg.fsf@sappc2.fritz.box> <874jjka15f.fsf@oook.m.uunet.de> <87ttrjw997.fsf@oook.m.uunet.de> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7184"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 66050@debbugs.gnu.org, Jens Schmidt , Stefan Kangas To: Harald =?UTF-8?Q?J=C3=B6rg?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 25 00:14:05 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 1qkXMb-0001fs-As for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 25 Sep 2023 00:14:05 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qkXMP-0005lm-1F; Sun, 24 Sep 2023 18:13:53 -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 1qkXMM-0005lJ-Sv for bug-gnu-emacs@gnu.org; Sun, 24 Sep 2023 18:13: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 1qkXMM-0006ox-KR for bug-gnu-emacs@gnu.org; Sun, 24 Sep 2023 18:13:50 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qkXMY-0004Mw-2f for bug-gnu-emacs@gnu.org; Sun, 24 Sep 2023 18:14:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 24 Sep 2023 22:14: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.169559359716730 (code B ref 66050); Sun, 24 Sep 2023 22:14:02 +0000 Original-Received: (at 66050) by debbugs.gnu.org; 24 Sep 2023 22:13:17 +0000 Original-Received: from localhost ([127.0.0.1]:43710 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qkXLo-0004Lm-LD for submit@debbugs.gnu.org; Sun, 24 Sep 2023 18:13:17 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:38638) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qkXLi-0004LV-JH for 66050@debbugs.gnu.org; Sun, 24 Sep 2023 18:13:14 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 7ADC244221B; Sun, 24 Sep 2023 18:12:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1695593570; bh=yAbm+N4sboSR31ZU9SxBJAiXu+Ow1/JPJRKjzEep89g=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=IdHvzNg7YWaL5OmHlBABFvE1FrQXkUD9p/xMxjUO7CKxq1MMad5Nr27Ro5NlU62Wx EVh+4o8zcmLZoURdGjUfWVer3VLcs6Yr6WM6QniYMPulQbARODEPdzwEA4pSlXfkY8 fklUHc9qmC9fWHQ1bsYW6dZtlfr5xTdDI+YLPsX5U5M4CiOeRD7MZEi42//XDCHnK4 mahbX80EFhoKuHRKpDbtd6xcwDiIxvRxBlwWviv749EIvj5wjqTFgFjG83ciCRgqaN 50Xs0Q4dUCA+PKDXwV5xsbIQ0m20UN3x8wg6dPj6HiAUP/CLlr8E7Sql+S5qvMYN2s d25af7juTEAxA== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A5550442219; Sun, 24 Sep 2023 18:12:50 -0400 (EDT) Original-Received: from pastel (unknown [108.175.235.15]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7A765120224; Sun, 24 Sep 2023 18:12:50 -0400 (EDT) In-Reply-To: <87ttrjw997.fsf@oook.m.uunet.de> ("Harald =?UTF-8?Q?J=C3=B6rg?="'s message of "Sun, 24 Sep 2023 21:29:08 +0000") 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:271277 Archived-At: >>> 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... Levels are just not the right concept, because there are many ways to "measure" and hence order by levels. E.g. Most of the time, "level" is associated with the amount of effort to figure out where to highlight, which is related to how much understanding of the language is needed. So it ends up providing "lexical-level" information only at the lowest level and then as you move up the level it gets more fancy and start accounting for grammar and then static semantics (e.g. whether an identifier is a reference to a local or global var). Personally I want very little highlighting, but I'm usually more interested in the "higher-level" highlighting, so I end up having to choose the highest-level and then configuring most faces to be indistinguishable from `default` :-( > 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). I'm not talking about users creating a custom theme. I'm talking about cperl-mode providing a custom theme that gets it closer to something like `perl-mode`. > Emacs comes with themes which look better than anything I could create - A cutom theme is nothing more than a set of Custom settings (vars and faces), and users can enable *several* themes at the same time. So we can provide a `perl-mode` theme which just changes `cperl-mode` to look and behave somewhat like `perl-mode` and that doesn't prevent users from *also* using `modus-vivendi` or whichever "global color theme" they like. A "custom theme" is like a minor mode, except that it's more declarative so it better interacts with other user settings (or other themes which may partly overlap). > 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. I think you're overly pessimistic. A few tweaks here and there shouldn't cause too much noise, if they make things more regular/consistent. > 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. I guess using `font-lock-function-name-face` for [] does sound quite wrong, since it plays a very different role from "the place where an identifier is defined as a function-like thingy", which is what this face is typically used for elsewhere. I'd recommend to highlight them as something like keywords as well. [ BTW, ELisp mode uses `font-lock-regexp-grouping-construct` for some of that. ] "Types" also sounds odd for \d and friends but the harm is probably a bit more mild. > The substitution part can be actual Perl code, and cperl-mode will > fontify it as Perl code. IIRC `perl-mode` also tries to fontify the replacement part as Perl code (when it does contain Perl code). I can't remember if I managed to make it work for all the relevant cases, but I haven't heard any complaint from `perl-mode` users when I made this change, so if `cperl-mode` does it in more cases, I don't think `perl-mode` users will complain when switching to `cperl-mode`. Stefan