From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Date: Tue, 9 Jan 2024 22:24:56 -0800 Message-ID: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.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="33235"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= To: Dmitry Gutov , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 10 07:26: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 1rNS2k-0008Q2-Sh for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 10 Jan 2024 07:26:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rNS2J-0001Yb-D0; Wed, 10 Jan 2024 01:25:59 -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 1rNS2H-0001YJ-9d for bug-gnu-emacs@gnu.org; Wed, 10 Jan 2024 01:25:57 -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 1rNS2G-0000fl-1f for bug-gnu-emacs@gnu.org; Wed, 10 Jan 2024 01:25:57 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rNS2M-0001Fk-BP for bug-gnu-emacs@gnu.org; Wed, 10 Jan 2024 01:26:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Jan 2024 06:26: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.17048679134745 (code B ref 68246); Wed, 10 Jan 2024 06:26:02 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 10 Jan 2024 06:25:13 +0000 Original-Received: from localhost ([127.0.0.1]:41604 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNS1Z-0001ES-Db for submit@debbugs.gnu.org; Wed, 10 Jan 2024 01:25:13 -0500 Original-Received: from mail-ed1-x534.google.com ([2a00:1450:4864:20::534]:60510) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rNS1X-0001EB-Fd for 68246@debbugs.gnu.org; Wed, 10 Jan 2024 01:25:12 -0500 Original-Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-55745901085so4686064a12.0 for <68246@debbugs.gnu.org>; Tue, 09 Jan 2024 22:25:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704867897; x=1705472697; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:from:to:cc:subject:date :message-id:reply-to; bh=j5iI09/l5MXMtLEEkzU4ObF1okRiBMIrRidsUcKzdHw=; b=fL3IXdORutvcbvHTE0Ekc81yAgQbnmqpPZ7hPojUOJ+T0EegGjOwQskqAWJ+5Tl5WW AkVaVRNwwSG5983iFoJdg007ovMb/WgmyGVDRCUvxbV7RnFnQz0BJvD1ghuU7afFxYCT VVFDDmWTtjnPmrPcPBCn9MfCnhWk/cHntPBw4w+BqcbVkQG30xXUf8aONNCN6VsTerim IvGz65pAL2VxUoeUZjryt6ncbljrfYMn+F5Bjc3LghlDK5nln9Hr0wcAmZ/kuzdAusIX 1hxZjUz+saK3977d6wUZB6uFo+Kwy7rOoKFwKGkquJFjAfJx1cPLCLEOcysaq64obIsS VthQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704867897; x=1705472697; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=j5iI09/l5MXMtLEEkzU4ObF1okRiBMIrRidsUcKzdHw=; b=O7F4Yf+dAr1MkfxsWHHrFKYp7hltsW5YhcldySdCKDJZ/CtKawXhiaTO7FPQ9l1dQC W04NiWICqJjO+ygSRhw8pbZEVJcxt2ieGDykW8aSLcSeTpde3zvKpecv+NXxvlc4gj0i geXxflmkmWEI5B3qr1RuAe4i8Kk34wyJhLauHEL5gBemK9/iPRIs5C5IxH9UQdBpxKVH EkJpmLNtjC74RUHQV2MI3UiIuVGpO0weZ3fk0Vm9jnKYHBhWiC8g7c0Fix0NgTp0LaVY fRKzQQHftBuz1mCbfJdpkM0dtMNHXL/og+n2JlDfway6CNJweIPI1Jx0CWbkZLx9JMk1 xZXw== X-Gm-Message-State: AOJu0YzaE5NoJO+naCzH6lcPkkxrkRwggiBlV8gM7Y36QO3E+/TNFBPm JziYUMxTlYqYDFWCxPsnmgv0qxZ/o3ywQmJp/gM= X-Google-Smtp-Source: AGHT+IFz2NK2FpxgckqnS7yvLp+euE+++51h7zP2PgBkR97jBWnSUsQA6aeJXK1tZK56Y7RztnYN8lIlCHEZ9Oh/s9I= X-Received: by 2002:a50:96c1:0:b0:557:d5c1:a4ae with SMTP id z1-20020a5096c1000000b00557d5c1a4aemr112487eda.47.1704867897054; Tue, 09 Jan 2024 22:24:57 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 9 Jan 2024 22:24:56 -0800 In-Reply-To: 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:277682 Archived-At: Dmitry Gutov writes: >> The current bug-report*is* about "finding the language" but the code >> that needs that info luckily doesn't need "the language" it just needs >> to know "does the current buffer contain language FOO", which is an >> easier problem, which I propose to solve with `derived-mode-p`, since >> that's what we've been using all these years. I can see the logic in that, however recently the situation has changed such that many major modes will exist both in standard and treesitter variants. If there was ever a good time to take a step back and consider doing something differently, this would be it, I think. > TBF, I don't quite like the "subtleness" of this solution. The > inheritance hierarchy of the modes is an implicit thing, and the fact > that js-mode-hook would run in js-ts-mode in Emacs 30 but not in Emacs > 29 would likely trip over a lot of people. Especially those who read > recipes on the Internet. I also misunderstood this at first: the major mode hooks would not be run in Stefan M's proposal. Perhaps the fact that two of us have had the same misunderstanding tells us something about the complexity of that solution. > Also, "what language is this" does happen to be a meaningful question. > Eglot's example aside, we can have other tools, databases, etc. I can't speak for Stefan M but AFAIU he agrees that "which language corresponds to this mode" is something we want to answer. He just proposes using the taxonomy we already have for this, instead of adding a new one. I.e. the difference is: (derived-mode-p 'foo-mode) vs (language-for-mode-p 'foo) Monnier T=C3=A1vora Either of those would answer the question "does the current buffer contain language FOO". The former reuses the old taxonomy, the right introduces a new one. > Finally, if we did have "languages" as an entity, we could have some UI > for the user to choose the mode for a language - something like Debian's > 'update-alternatives'. And it would also serve to list the supported > languages, I guess. This is a good point. Also to install extensions for those languages. Or we could use it to implement the VSCode-like prompt "hey this seems to be language , do you want to install support for it?". At the same time, I don't think anything technically stops us from using `foo-mode' for this either. We would just have to be more careful in how we present it to users, to avoid any confusion. FWIW, I tend to slightly prefer the solution proposed by Jo=C3=A3o, since i= t makes things simpler and less confusing in some ways: (derived-mode-p 'foo-mode) does what you expect, and in every mode where that sexp evaluates to t, `foo-mode-hook' is also being run. It also has less potential for breakage, since only new stuff will use it. At the same time, I don't want to just discard the argument that simply sticking with what we have is even simpler. It obviously is in some ways. But I'm not convinced that this level of simplicity doesn't have a cost that rears its head in the form of complexity elsewhere. Basically, the biggest weakness of Stefan M's solution is the biggest strength of Jo=C3=A3o's and vice versa: "backwards-compatibility" (if we ca= n call it that) vs "clean taxonomy".