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: Sat, 20 Jan 2024 09:03:43 +0200 Message-ID: <83bk9gv640.fsf@gnu.org> References: <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <8e6935bc-2a60-4a14-8e63-d6057a7e2af7@gutov.dev> <1a0802a1-7c25-4188-9984-f54b0e56ab5e@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31662"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68246@debbugs.gnu.org, dmitry@gutov.dev, casouri@gmail.com, monnier@iro.umontreal.ca, stefankangas@gmail.com To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jan 20 08:05:17 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 1rR5Pn-0007ya-Lc for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 20 Jan 2024 08:05:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rR5Pb-0007ML-UY; Sat, 20 Jan 2024 02:05:03 -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 1rR5PX-0007Hq-O1 for bug-gnu-emacs@gnu.org; Sat, 20 Jan 2024 02:04:59 -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 1rR5PX-0000Wq-FI for bug-gnu-emacs@gnu.org; Sat, 20 Jan 2024 02:04:59 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rR5PZ-0004MO-S0 for bug-gnu-emacs@gnu.org; Sat, 20 Jan 2024 02:05:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Jan 2024 07:05: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.170573425516696 (code B ref 68246); Sat, 20 Jan 2024 07:05:01 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 20 Jan 2024 07:04:15 +0000 Original-Received: from localhost ([127.0.0.1]:60744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rR5Oo-0004LD-QL for submit@debbugs.gnu.org; Sat, 20 Jan 2024 02:04:15 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58084) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rR5Om-0004L0-Jy for 68246@debbugs.gnu.org; Sat, 20 Jan 2024 02:04:13 -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 1rR5Od-0000IR-UH; Sat, 20 Jan 2024 02:04:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=tKfIaRZJx5Kot/L1m8LPvkVcQGWdJmywHNZhjNtHZ9U=; b=LybEDq04cgUJIgY5sv2o aBWXTGZFcf9n7lRygxy8sNKRQvwP8Y76PFnjPktFnEDRaheIXzJl7FZgPwiOZijdugh0xGxbmDwYw drxpaFPZyAYfdYKcrzFybdPZfd4edb6P8xalVKJsUjYZb5dCcBiaNkQB1g6WZBZI1c9X/u6WWY5Gr Ok8mnhF0ez+Zy11PnkU59Svp+eSAm48H6OXTYZQyXUcwGhsBxoTiS/lcwsQm8h2PGV/n4HKHViB7W ffUM4K1i0vMEaeZ8CiNBauwH23fUcgFw3pwAfQo4Jej1R69cYcke6WOhD2NaWAlwq6WHtk2RepqJD dPxrVnD9f9qS2w==; In-Reply-To: (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Fri, 19 Jan 2024 22:47:07 +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:278563 Archived-At: > From: João Távora > Date: Fri, 19 Jan 2024 22:47:07 +0000 > Cc: Dmitry Gutov , Eli Zaretskii , > Stefan Kangas , 68246@debbugs.gnu.org, casouri@gmail.com > > On Fri, Jan 19, 2024 at 6:05 PM Stefan Monnier wrote: > > > > I.e. can you clearly paint a way forward from it that solves the "what > > > is this language in this buffer", "what is the language for this > > > major-mode" and the "what mode should I use for that > > > language" problems? > > > > As already explained ad-nauseam, my patch has no intention to solve > > those problems, but I can't see any way in which it gets in the way of > > solving them, if you care to solve them. > > The patch is intended to solve problems in Eglot, Yasnippet, > ffap and so on. This problem always includes with "what is this > language in this buffer", i.e. number 1 in the preceding list. > That's what the problem is, no less. The fact that these packages > have always resorted to using `derived-mode-p` to solve that > problem is an unfortunate consequence of the longstanding > conflation between modes and languages that you yourself > identified. > > But it's not the right solution, never was. Your patch contributes > to the perpetuation of this "wrong" solution, and I think > we should face that frontally. Your opinions on this are well-taken and have been noted many messages ago. You made them abundantly clear. There's no need to re-iterate them time and again. > After it lands, derived-mode-p will cease to mean "A derived > from B via defined-derived-mode, so you can trust hook for B > runs in hook for A and a lot of other things". It will mean > something else. Indeed, and it was not meant to mean what you suggest it should mean. > * if it lands, we should document very well what that new meaning > of "-mode" is. Also make some "provided-mode-walk-parents" > so that at least problem 2 can be solved, by string-matching > the symbol name of what will now be an even more enshrined > convention. As to problem 3, maybe, it can be written off to > "major-mode-remap-alist" (which I doubt will ever see much > adoption) Feel free to suggest improvements and clarifications to the documentation in these matters. > * if it doesn't land, we should look at some solution that solves > 1 2 and 3 cleanly. I think Dmitry's patch is a decent start. Since it will land, there's no need yet to look for alternatives. We will consider alternatives or other ways to fix this when we have data (as opposed to just theoretical discussions) to support the need for such changes. (This, too, has been mentioned several times already.) > * in the meantime, we should continue using base modes as we > already are. In fact, the -base-mode convention is a > much better convention to enshrine, it doesn't require any > special caveats regarding hooks and dir-locals and changes > to the *Help* of a major mode function description. We already use base modes where it makes sense. It sounds like your opinion is that we should use it much more radically, with which I disagree and will object to introduction of base modes that server no useful purpose by themselves. I believe I've made that clear as well. I hope this will allow us finally to put this longish discussion to rest, at least until we have actual data to discuss what and how needs to be changed.