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?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Date: Sun, 14 Jan 2024 23:40:17 +0000 Message-ID: <871qajfpr2.fsf@gmail.com> References: <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40859"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 15 00:41:35 2024 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 1rPA6h-000ATz-3f for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 15 Jan 2024 00:41:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rPA6D-000321-Oy; Sun, 14 Jan 2024 18:41:05 -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 1rPA6A-00031T-TT for bug-gnu-emacs@gnu.org; Sun, 14 Jan 2024 18:41:03 -0500 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 1rPA6A-0006Gz-J8 for bug-gnu-emacs@gnu.org; Sun, 14 Jan 2024 18:41:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rPA69-0007Xf-Qy for bug-gnu-emacs@gnu.org; Sun, 14 Jan 2024 18:41:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 14 Jan 2024 23:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68246 X-GNU-PR-Package: emacs Original-Received: via spool by 68246-submit@debbugs.gnu.org id=B68246.170527562828924 (code B ref 68246); Sun, 14 Jan 2024 23:41:01 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 14 Jan 2024 23:40:28 +0000 Original-Received: from localhost ([127.0.0.1]:44242 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPA5b-0007WS-K8 for submit@debbugs.gnu.org; Sun, 14 Jan 2024 18:40:28 -0500 Original-Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]:54593) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPA5Z-0007WC-1t for 68246@debbugs.gnu.org; Sun, 14 Jan 2024 18:40:25 -0500 Original-Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-33678156e27so7028990f8f.1 for <68246@debbugs.gnu.org>; Sun, 14 Jan 2024 15:40:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705275619; x=1705880419; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=2me5OmxSWCOjNKBbjo+e+JNIN3/Vz8Gj+CuESO44OPg=; b=BzipV2vjv7fvGVguAILD9GZ8r9fAKHwSkMgW3S5xDTmrNp03BUIWgZGKCfwzJEzuX7 kdfy9fuMx7LWzW3AdFIaisHPaKp2misrtxe6ZZa2VFjuz3gH/3+eF8TCdqvGCmkjSJNB NGQpFwCMAHcosEwqd+G6N+VLjLVB9xA0L2ct9YWDSbu9KH1PNZTdB203uts7hkWIGEpf nCHHt7+a3dHRzkszXjT1Sp0t9RYmHQNzjz3sxDp+cOzwUmnRPjdZVuFnk8KxesHxsCog sG0MpqyvE9cGvwFDmkuErrES4BadxUbuXWq9zQC92I42s0LzFC1SJ/tJkz1zifQKwvlM am7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705275619; x=1705880419; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=2me5OmxSWCOjNKBbjo+e+JNIN3/Vz8Gj+CuESO44OPg=; b=k9KTmPBK1XzHAl/dmDxat5Pu2NeuKVSNPtbxk6ff1ZhiiKpuiTtr2P3KS7/DT0qYDr jyEmjBiZw0lCXWZx1P9iHnr0baEEnY89Qvke3tlhe2NWinr24cntBSblDsYhyp7GlQAW 1GkHpPWogLe+1PfI/dXINkhBfIe8Fv+fsR72bp7h7KgZGy2p39I1eJkbyUq2xNe/uWpx 9by9RLWRUiVPAu6c37nHfgvamih+wIXbWGuA9szn2Yq0c67pFwdoCmQiYhdvlgm61Zd9 YntFNZezI/qxAhmlWzyN7thmcs6lHcJlnDtnZenE5kDtBuJ1WB3sU8+fXEdnJqjiY0/T VuZw== X-Gm-Message-State: AOJu0Yyo3jGvsIfXjnAT9TUpQ4u+3qsBSywg8yiH5sooxnWmNb5vNz+n cb0rLWk5nc/OGaZYc7I83MbDEJk816k= X-Google-Smtp-Source: AGHT+IFL5TSCLtn6wNb4LuMQMwQtoJUK4vB4xjG0IzSCKzlQlASzCTWdzcZ5RDBOCR/Dw2Y+AB0eeg== X-Received: by 2002:a5d:4843:0:b0:337:6258:4e76 with SMTP id n3-20020a5d4843000000b0033762584e76mr2530349wrs.112.1705275618865; Sun, 14 Jan 2024 15:40:18 -0800 (PST) Original-Received: from krug ([87.196.72.99]) by smtp.gmail.com with ESMTPSA id x18-20020adfffd2000000b003377680c55bsm10262372wrs.16.2024.01.14.15.40.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Jan 2024 15:40:18 -0800 (PST) In-Reply-To: <83edekfldq.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 14 Jan 2024 09:02:25 +0200") 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:278241 Archived-At: Eli Zaretskii writes: >> However it is not easy to quantify confused users looking to understand >> the new meaning of things in dir-locals.el. Or users wondering why they >> need to set Eglot variables in both 'c++-mode-hook' and >> 'c++-ts-mode-hook' when all they see is 'c++-mode' in >> 'eglot-server-programs'. > > Those users will hopefully submit bug reports or otherwise complain on > the Emacs mailing lists, and then we will know. You also know this doesn't always happen. A confused user has a certain probability of using those channels, and that is most definitely not 100%. But I will make sure to send any Eglot confusion this way yes. >> There are better alternatives to this patch: >>=20 >> 1. The base modes, which are substantially _already_ in place. They >> follow the naming convention -base-mode. After giving more >> thought to your earlier objection about derived modes overriding >> variables, it doesn't make sense (I can elaborate if you want :-) ). > > The recommendation is to use base modes where it makes sense, and the > installed changes around derived-mode-add-parents don't in any way > preclude having a base mode and don't make it harder. But I don't > think we should force everyone in this situation to invent a base mode > as the sole means for solving this. We can invent for them. There's very little to invent. Earlier you seemed to view a base mode as a receptacle for common code. It _can_ be that (and _should_ where applicable). But it doesn't _have_ to be. An empty base mode is useful just for its hook and its behaviour in dir-locals, for example. So, find two modes for the same language foo, make an empty foo-base-mode: (define-derived-mode foo-base-mode prog-mode "Base mode for Foo") Then ask the authors of 'foo-mode', 'foo-ts-mode', 'foo-nongnu-mode', etc to put foo-base-mode in their mode definitions. If they refuse or are unresponsive, consider insinuating 'foo-base-mode' in them (after asking why, of course). If this insinuation is acceptable for complex "extra parents", why shouldn't it be acceptable for normal parents? This is not technically hard to do, a simple add-function works (and it's also self-documenting). >> 2. Explicitly associating some major modes with languages or file types. >> This doesn't seem hard and other further uses like suggesting modes >> or packages to a new user based on languages have been proposed. > > This is IMO a heavier and more thorough change, especially since Emacs > doesn't have the notion of "language". This discussion shows that its > advantages are not evident, and moreover we don't even have a clear > shared view what will that entail. It's not an extremely heavy change, at least not when compared to extra parents at least. But yes, we should be careful how to implement it. The advantages are evident though. Eglot and Yasnippet would be much simpler to configure. Even simpler with a language-specific hook. But "base mode" approach, which has a significant deployment already, is basically the "languages approach" in slightly more verbose naming. > So I think Yuan is right: let's see what happens with what we have on > master, and take it from there. OK, experimenting in master is what master is good for, after all. Could be effective (even too much, as the recent register imbroglio clearly showed). But I think the practical subtleties (like dir-locals merging, potential Eglot fallout) need to be highlighted somewhere or at least announced in emacs-devel. Also I for one would like to understand the how consistently these extra-parents are going to be used in the future: the symbol named 'foo-mode' is about to be promoted to something above just _a_ major-mode for Foo, and I'd like to see that cleanly described somewhere. Jo=C3=A3o