From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" 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 21:32:22 -0500 Message-ID: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83bk9wq9ho.fsf@gnu.org> Reply-To: Stefan Monnier 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="27581"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, joaotavora@gmail.com To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 16 03:33: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 1rPZGd-0006r4-JB for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 16 Jan 2024 03:33:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rPZGD-0006GS-1B; Mon, 15 Jan 2024 21:33: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 1rPZGB-0006GF-Kt for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2024 21:33:04 -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 1rPZGB-0003yD-C1 for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2024 21:33:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rPZGA-0003EM-5L for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2024 21:33:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 16 Jan 2024 02: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.170537235812388 (code B ref 68246); Tue, 16 Jan 2024 02:33:02 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 16 Jan 2024 02:32:38 +0000 Original-Received: from localhost ([127.0.0.1]:47349 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPZFl-0003Dk-Rj for submit@debbugs.gnu.org; Mon, 15 Jan 2024 21:32:38 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:4187) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPZFg-0003CZ-GN for 68246@debbugs.gnu.org; Mon, 15 Jan 2024 21:32:35 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id AD857100054; Mon, 15 Jan 2024 21:32:25 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1705372344; bh=q3BDAZ8RLiLrYQl75priEYhl6wT7XQcmou7sK/Gy2OY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=awk4jVdJrECp6dv543H07sQdJxY1j+iZyj25XiZJLyU0XYOk9YeUhmN4P4RdIGA9B 4FZAfe30p9abBGwJ34nobHqFPRMuPzu6LnSh7r1ndQKjOOYY9aE6u3L1RwmfsT0Mdm upfnvbahmpq4+OsdtuJ6c1otr4s5eoZf1Ydj6tn52LnJiN0IRD+KGeuA+8nkk83c9I S2OZPpmQugomToWgNOksSEie0JaZPF9LaIZrfM10oHe3bQkZ28h2Jjslo/OXtXh+9N l1Fn94YR/FF20v6VOefmvFdcBJaihFedznsD5xQ+SKsNTP7lrtqy7JTRYt6q4eqjx2 R8SW/7b+/74hg== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8CD3D10001D; Mon, 15 Jan 2024 21:32:24 -0500 (EST) Original-Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3E02912062F; Mon, 15 Jan 2024 21:32:24 -0500 (EST) In-Reply-To: (Stefan Kangas's message of "Mon, 8 Jan 2024 11:18:41 -0800") 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:278314 Archived-At: >> Please don't call it "language". That'd be confusing. LSP is about >> programming languages, so "language" is natural there. But in Emacs, >> a major mode is more general than that. For example, it is not >> unthinkable to consider mail-mode to be the extra-parent of >> message-mode (or vice versa) -- but what is the "language" in that >> case? > Isn't the language for such modes in this paradigm just the empty set? I'm not too worried about those cases, indeed. I'm more worried about the taxonomy of languages. We currently have the taxonomy of major modes, with which we're pretty familiar, and we've had many years to learn about its downsides, complexity, as well as how to deal with them, but for languages we're only familiar with the easy cases, which makes us judge the idea in a way that may prove naive. IME, deciding what is the type of the content of a buffer is usually trivial but with some notable caveats, such as XPM or Postscript files, or "container formats" (like `.deb` or `.odt`, as well as things like DocBook which can be considered either as their own format or as XML), or "sublanguages" such as C being a subset of C++, or Javascript being a subset of Typescript. And I suspect the info we need will not always be quite the same. So while there might be a good case to be made to add some API functions to query the language/type(s) of a given buffer (I'm not sure we'd need the language of a given major mode, OTOH), or to find the preferred mode(s) for a given language/type, I think it's worthwhile to try and tweak our major mode taxonomy because it is information we must have and information we know we will always have, so we should strive to make it as good as we can. It shouldn't make it any harder to add language/type API functionality. On the contrary it should make it easier. [ As suggested elsewhere in this thread, we could even try and merge those taxonomies, e.g. using extra parents of the form `LANG-lang`. ] As I said at the very beginning of this long thread, I'm not completely sure how well my proposal will play out: the upsides are in plain sight, but it may bump into real problems. [ I'm actually surprised by Eli's optimism about it =F0=9F=99=82 ] But we won't know until we try it. Stefan