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: Fri, 05 Jan 2024 17:34:34 +0200 Message-ID: <838r53vlo5.fsf@gnu.org> References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> 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="13776"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68246@debbugs.gnu.org, monnier@iro.umontreal.ca 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 Fri Jan 05 16:35:11 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 1rLmE2-0003Js-P4 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Jan 2024 16:35:10 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rLmDr-0000qr-Qt; Fri, 05 Jan 2024 10:34: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 1rLmDq-0000qh-TU for bug-gnu-emacs@gnu.org; Fri, 05 Jan 2024 10:34:58 -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 1rLmDq-0003P8-Bl for bug-gnu-emacs@gnu.org; Fri, 05 Jan 2024 10:34:58 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rLmDu-000071-DO for bug-gnu-emacs@gnu.org; Fri, 05 Jan 2024 10:35: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: Fri, 05 Jan 2024 15:35: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.1704468901421 (code B ref 68246); Fri, 05 Jan 2024 15:35:02 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 5 Jan 2024 15:35:01 +0000 Original-Received: from localhost ([127.0.0.1]:57625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLmDs-00006i-Kg for submit@debbugs.gnu.org; Fri, 05 Jan 2024 10:35:01 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43436) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLmDo-00006T-Ry for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 10:34:58 -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 1rLmDe-0003OJ-FD; Fri, 05 Jan 2024 10:34:46 -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=1lWxnn+LPsWs25U9PIviQPoE1gV2vd5ks3pKmYCiZUo=; b=ejI761QxM9JE711d5vZ3 Jwq5wJ2bsecqGYZqnz+5/UtQQQQ0Vi0RY7z3fVTFOvVc1+iGQnIC9xoS1+FG6rRSWirEIk46xM0rF XgRm24NC6BXu4UFjaLnlXgdAH4FDdyYSRM3X2VAxKdsOFUPbvXznbCL0fNULO+rDi0pa3j1/3cIy0 oD+o9zF4219hYXS/GfyojNBKuiAEtRNxqCGkLdY98gZhtkR0AFpmV0Di4xfqF1ulTFUlhgvRhIX61 4z++7H2U90WRCW9G4DpRBQSaJ8PXShok/Cmj9674mofXiZXZr7VHz2iO+OqDvHhaKxkd+1VMpjpXF jhxyqNERr6fT/w==; In-Reply-To: (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Fri, 5 Jan 2024 15:16:30 +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:277396 Archived-At: > From: João Távora > Date: Fri, 5 Jan 2024 15:16:30 +0000 > Cc: monnier@iro.umontreal.ca, 68246@debbugs.gnu.org > > On Fri, Jan 5, 2024 at 1:26 PM Eli Zaretskii wrote: > > > That's right -- but it's justified. The commonality is usually either > > very thin or almost non-existent. If you think about it, you will > > understand: where the traditional modes use regexps and syntax-ppss, > > the TS modes use parser-related primitives. > > I _have_ thought about it. And I started from evidence that > not everything a major mode dedicated to a language supplies > is directly related to the parser implementation. Many things > are, but not all. So reimplementing a full major mode just > for changing the praser backend might not make sense. Experience shows that eventually most if not all of that goes back to how the mode parses or analyzes the text (a.k.a. "source code"). > > How can you find common > > grounds between these so different bases for implementation? > > Very easily, I think. Stefan's patch is one such example. > What it is fixing? Tools that want this common ground and haven't > found it, of course! What Stefan's patch fixes is the features that depend only on the mode's symbol, but don't call any mode-specific functions or examine its data structures. > Take inserting comments via comment-dwim. Even comment-dwim already shows a problem: it must determine whether point is inside a comment, and TS and non-TS modes do that radically differently. The commonality could of course be increased by refactoring the existing stuff so that it uses more abstract interfaces, which could then be implemented separately for TS and non-TS modes. But that requires some motivation, and for now I see no such motivation where different people maintain the traditional and TS modes. Such refactoring is not an easy business, so without the motivation I see no way for that to happen any time soon. > Or invoking LSP in any mode for another example. LSP only cares for the language, so of course it can benefit from Stefan's patch, because all that matters is the mode's symbol. > Or consulting documentation. Again, only the mode's symbol is important. > Or anything we've built (including muscle memory) that lives on top > of syntactic abstractions like forward-sexp. Here you already bump into a problem, because most languages have no notion of "sexp", so making a TS mode do the same as a traditional mode is not easy at all. > Basically any preference that the major-mode expresses regarding an > orthogonal facility (minor mode or not) should, in principle, be > shared. I invite you to compare CC mode with c-ts-mode, and see for yourself how the common grounds are very small. It seems surprising at first sight, but once you look at the code, it is very clear. > At the very least, it seems a common hook would be useful, and that's > what an empty foo-base-mode() would give. Where a base mode makes sense, sure. But even that causes problems, since the base mode leaves some stuff not set up, and this various things that you'd want to do in a mode hook are impossible in the base-mode hook.