From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Date: Mon, 15 Jan 2024 20:32:27 +0200 Message-ID: <4cda8b54-ede1-4fe3-b54d-7b6937453592@gutov.dev> References: <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> <83a5p6epcl.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3252"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 68246@debbugs.gnu.org, casouri@gmail.com, joaotavora@gmail.com, monnier@iro.umontreal.ca, stefankangas@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 15 19:33:27 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 1rPRm1-0000cF-Ej for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 15 Jan 2024 19:33:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rPRlg-0001sG-Nf; Mon, 15 Jan 2024 13:33: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 1rPRle-0001ro-Tm for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2024 13:33: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 1rPRle-0008Hg-LG for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2024 13:33:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rPRle-0005PH-7G for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2024 13:33:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 15 Jan 2024 18:33:02 +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.170534356220754 (code B ref 68246); Mon, 15 Jan 2024 18:33:02 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 15 Jan 2024 18:32:42 +0000 Original-Received: from localhost ([127.0.0.1]:46821 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPRlJ-0005Of-Ie for submit@debbugs.gnu.org; Mon, 15 Jan 2024 13:32:42 -0500 Original-Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:48045) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPRlH-0005OS-I7 for 68246@debbugs.gnu.org; Mon, 15 Jan 2024 13:32:40 -0500 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 358063200ADF; Mon, 15 Jan 2024 13:32:33 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 15 Jan 2024 13:32:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1705343552; x=1705429952; bh=pOBQ8sK1RYybQPI+vwSm4mQrAgnYllpIxs80rCHoZNg=; b= DkCrSVlQwdJBXl1bq7LxREVamfzdQJC6iHSKmpS9sualA6UYGtL+iwiROoaPIHC2 0XacE/nT04AmHw9RQmvTLHq2nsogV3m2Gx3vzWxJJw9hlDF9cFpJfc6Trn2E0gZc zcbZmSEQ01GaEXm7b9PPbY6lsUjQ6KDKfVqEm6S+4aRegYCYTQYIc1p5sCFjSVH5 dX5HG3esyHQ8ShnDsJSFVTQsvIPHiVmvcfto6L63sRutzEU1bPcn4SuUU846Hxml cRiVhdvizQdaA0jXV8gtFtbPFnQatEAre6rMhYhg9dezsyxVKEuA9ubaRp3ufs8I qHKCQBrBN50dGOt4iGmPgg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1705343552; x= 1705429952; bh=pOBQ8sK1RYybQPI+vwSm4mQrAgnYllpIxs80rCHoZNg=; b=g M2PczBl1AmBtFWHzQCak/keUSOQewGbUTaMXnmZBJzS3dOh/qI3MAr1Hc+RnmgYe 0KozVZkGVh98xCRuaKGXUpZq8R7CIX+9C2t6n5fXIUO/00Rz6f9+HAhWtsc/9AmZ 8WDc1JK9AHlHItp2ZWPckoX8NoioHlXhTILqIvCFlx2Ts9+hWyMtoyQEEhjWwUSP lpBsiDmm3LgCXdotA0AN7bfLJaLkjXQOmGW0GHAfv4QLSMajLkkdkBZeJGmmudQf yIEeRjAzVHNFloGFIA/FBZBqhL30Wia8aiC6rBp5y9fOY7G6EvkmlrwW371DW6F+ 9LS5+D/U704+7R0Mdfc/g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejuddguddugecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveeg udejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 15 Jan 2024 13:32:30 -0500 (EST) Content-Language: en-US In-Reply-To: <83a5p6epcl.fsf@gnu.org> 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:278295 Archived-At: On 15/01/2024 14:46, Eli Zaretskii wrote: >> Date: Mon, 15 Jan 2024 04:10:16 +0200 >> Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca >> From: Dmitry Gutov >> >>>> 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. >> >> I rather wouldn't rely on that. > > Why not? The decisions we made are not arbitrary. Given the best > consensus (or lack thereof) we could arrive upon after careful > consideration of the issues, it is perfectly fine to expect feedback > to set us straight if we made a mistake. Because the corresponding downsides are already known. They are not catastrophic ones, however, and as such they won't be critical in day-to-day usage (prompting fewer users to bother with bug reports). And if one builds a chair with 5 legs, it will likely be not as convenient to use, but not many people will go and tell the author that the chair has an extra leg - it's obviously intentional. Nor we are quick to change our mind based on such feedback, as bug#61177 and bug#61177 demonstrate. >>> 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. >> >> It's not like we don't have an existing solution for this: if there are >> two different modes to configure, change the settings for both modes, or >> alter two hooks. > > This doesn't solve the problem at hand, since the differences between > the modes are not limited to these simple aspects. I don't understand your response. The original description says: packages tend to behave poorly because they do not understand that a buffer in `js-ts-mode` contains Javascript Presumably, a call like (derived-mode-p 'js-mode) fails. The packages can change it to (derived-mode-p '(js-mode js-ts-mode)), and it will succeed. Yes, it's a bit more work, but they will have to do it anyway to support Emacs 29.1 for a number of years. > Less magical and more verbose, but being explicit can >> be good. >> >>>> 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. >> >> Here's a draft patch of how a "language" could work. It doesn't alter >> every entry, but it is backward compatible. > > Like I said: it is heavier, so we should only do that if the simpler > method don't work well enough. So thanks, but let's try the existing > simpler solution first and see if we need something better. Indeed it's heavier because it's not just a fix, but a whole new feature. I suggest people try it out and see how they like it. If not, well...