From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii 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 14:46:34 +0200 Message-ID: <83a5p6epcl.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31915"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68246@debbugs.gnu.org, casouri@gmail.com, joaotavora@gmail.com, monnier@iro.umontreal.ca, stefankangas@gmail.com To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 15 13:47:32 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 1rPMNI-000837-08 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 15 Jan 2024 13:47:32 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rPMN5-0000By-MB; Mon, 15 Jan 2024 07:47:21 -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 1rPMMp-00009o-7Z for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2024 07:47:05 -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 1rPMMo-0005An-Ux for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2024 07:47:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rPMMo-0001j5-GT for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2024 07:47:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 15 Jan 2024 12:47: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.17053228176622 (code B ref 68246); Mon, 15 Jan 2024 12:47:02 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 15 Jan 2024 12:46:57 +0000 Original-Received: from localhost ([127.0.0.1]:44890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPMMi-0001ij-OL for submit@debbugs.gnu.org; Mon, 15 Jan 2024 07:46:57 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38940) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPMMg-0001gB-KI for 68246@debbugs.gnu.org; Mon, 15 Jan 2024 07:46:55 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rPMMb-00059E-Dg; Mon, 15 Jan 2024 07:46:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=1jv9D9SPfWUitq3WrwEtFF2yyvAdV0Rqm9OIIoSlG5c=; b=JH4hDoo1KvdF npvMtpDjLvcqxsHwY0cdhwZMTBkxgAttPShSeikYqJfRkGcn2XEXUI744vmU4xzePdhfgEzKVeK8q sveS48rGOC15bfU6Gz2YnEAqPn+5zymObooN6ptBEKgp7ohj4M0Si2VC+jqUKgQFhVQ0l+ztuw3yQ DNbRGUtUcgGN/17bdtp2r+GHqmRC5C5tOCCH4E+U70m4LRnnM42cRBmXN9WY4rEaGFBVD54MIQHSW GNFM/S0bIXrDiida933v5dhcb0HQSFr7511c14esHTnmoZdBHV0APMydUS5vxIfMQkgrr0YuVx3oJ vMMM59TprrqXIAltTLNfzw==; In-Reply-To: (message from Dmitry Gutov on Mon, 15 Jan 2024 04:10:16 +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:278271 Archived-At: > 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. > > 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. 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.