From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Date: Fri, 5 Jan 2024 11:27:53 +0000 Message-ID: References: <83edeww73j.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="11189"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68246@debbugs.gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jan 05 12:29: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 1rLiO5-0002TZ-MB for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Jan 2024 12:29:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rLiNn-0003HW-7v; Fri, 05 Jan 2024 06:28: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 1rLiNl-0003HO-Ss for bug-gnu-emacs@gnu.org; Fri, 05 Jan 2024 06:28: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 1rLiNl-0003ar-Ju for bug-gnu-emacs@gnu.org; Fri, 05 Jan 2024 06:28:57 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rLiNp-0008NS-Qo for bug-gnu-emacs@gnu.org; Fri, 05 Jan 2024 06:29:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Jan 2024 11:29: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.170445410032152 (code B ref 68246); Fri, 05 Jan 2024 11:29:01 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 5 Jan 2024 11:28:20 +0000 Original-Received: from localhost ([127.0.0.1]:56534 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLiN9-0008MW-E1 for submit@debbugs.gnu.org; Fri, 05 Jan 2024 06:28:19 -0500 Original-Received: from mail-lf1-x135.google.com ([2a00:1450:4864:20::135]:55344) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLiN5-0008MH-UY for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 06:28:17 -0500 Original-Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-50ea226bda8so1558024e87.2 for <68246@debbugs.gnu.org>; Fri, 05 Jan 2024 03:28:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704454086; x=1705058886; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=EBSO/1HD7H2/cI4nZMXMa7JvEAXuoQJjvE216y09Ap8=; b=ZjWfZ8Eg9wNVPuBMGYpQ3Vjvu2ZPCvmogK0SFyRbxNDiVU3eZ6zpqcubstMPnkkp/q a8MRgoO/hpvvCHgcW2BFBFNvbil7vm1PJS/vaSlsrt30vm3MSUHyPHK/O8LFHIjyDzdC N3/Rd+M8Y8zg7dW7rbS7jDzWS2AOjGl4gWMB0YTDesJKA57Xah7Ep4uWHSv9JaEG4Ksy 7gXyoO76mxW6GlJKdFDhBXY9VP6dzZ3ZWDwMm1m6/dU0JovVNkEDvCI3wfrnWWUPN4GH VhyD5qRJCXTe345zeCGKqplTMwIAAJDhtqSxwoHUcFF7F4PKE4+mx6424DWTI5uqgNv0 Gg9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704454086; x=1705058886; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=EBSO/1HD7H2/cI4nZMXMa7JvEAXuoQJjvE216y09Ap8=; b=v2Qi6/2RYT1Yw2MU/VZfBSz6ohR6T102XQ8uR9IEY9MOXLjTwIDtS8vhNmTSQqSpxe e5ILTiSFLBIc2+EuFnbzP9C83UQoS4Zj7Fu/CjxTTJwYiYSZgOvqpb1XJy1e6oEk3kd8 epuKFndcA47u2jjdmZXLx0I8ebYZx/z19L7Fw9Mmhm9Pw+Z0K3sEiFajA3BLo4k4ISuO K1WrekxCKEEtHPF/uRbu9h8PsiiNYbGw5QPozUxIEXoe4tVlHcQtUOceD7quKZBDnNIS 83VFR904OaGqZIwj+Ul5SKopP47CUoj5gTVwXYdxsSVOctp4Ir93pMXQ+l/ZlsQaEoQp CCBA== X-Gm-Message-State: AOJu0Yxj5KpS3j+oXWerVqKeXmqfsjmm0fPmpfTPjgvnzdrgS4H1bbEG kvSMgGav9lNdzc7i8PxM73iYPftn6eqT0ajXTWY= X-Google-Smtp-Source: AGHT+IFDpUB7Lki2ZkFrZGroRMcRlGUgJ1UdsH37NevWdvZYkaBRyagHJ0yj0WfiiwB8YEIiBhpS1Yiy0Q9CzKfvl60= X-Received: by 2002:ac2:4e13:0:b0:50e:7711:45c with SMTP id e19-20020ac24e13000000b0050e7711045cmr1259771lfr.77.1704454085450; Fri, 05 Jan 2024 03:28:05 -0800 (PST) In-Reply-To: <83edeww73j.fsf@gnu.org> 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:277380 Archived-At: On Fri, Jan 5, 2024 at 7:51=E2=80=AFAM Eli Zaretskii wrote: > > > Cc: 68246@debbugs.gnu.org > > From: Jo=C3=A3o T=C3=A1vora > > Date: Thu, 4 Jan 2024 23:48:48 +0000 > > > > We _don't_ want x-mode-hook to run when we activate > > x-ts-mode. Or do we? > > We don't, because FOO-mode-hook usually assumes all kinds of things > that are generally not true for FOO-ts-mode. Indeed. Sorry for the long mail, here's a TL;DR: let's experiment, but maybe tighten up the docs to state 'define-derived-mode' is parenting and 'add-derived-mode-parents' is more like adoption. Possibly add 'remove-derived-mode-parent' for safety and fixing existing bugs. Now I've read the patch and the misgivings are back. It uses `derived-mode-add-parents`, whereas by "adding the inheritance ourselves", I was suggesting going to each `define-derived-mode` of each 'foo-ts-mode' and really putting in 'foo-mode' as a parent. So this is the multi-file macro-expanded moral equivalent of the symbol-name hack I was talking about 'd-m-add-parents' is a very new util in our tree, and I suppose it has been discussed. It's not really full inheritance as given by normal parenting, it's more like "adult adoption" :-) I guess we can try it, and even like it, but can we be sure of all the semantic impacts? If you ask me, authors should prioritize getting their hands dirty and extract commonality for the foo-ts-mode and foo-mode one by one. Name such modes foo-base-mode or base-foo-mode maybe. This is what was done for lisp-data-mode which now parents most (all?) Lisp modes, so much that the other day I could write a functional 2 line Clojure-mode based on lisp-data-mode. The situation is that camp is much cleaner now, and it wasn't a very difficult change. base-foo-mode is a natural place for setup that is common to both foo-mode and foo-ts-mode to exist. There is a good number of things that are independent of the particular implementation of parsing (lisp-based vs ts-based). Is it too late for the ts-modes to be looked at like that? It seems our approach to TS modes often/always looks like 'foo-rewrite-completely-using-ts-while-at-it-mode'. Maybe for some modes this makes sense IMO, like C and C++ modes. Inadequate parenting is a real problem. The lisp-mode example 2-3 years ago, but also recently the parenting the js-json-mode <-> js-mode relation has caused a so-far unsolved problem in Eglot described in bug#67463. That bug can also really only be solved by "getting hands dirty" or by introducing some remove-derived-mode-parent counterpart to the new derived-mode-add-parents. If that's how we want to view "derived-mode-p" from now on. Maybe it is. But it should be well explained in the docs of both define-derived-mode and derived-mode-p that you don't need the former to get the latter and that d-d-mode bakes in much more powerful relation that add-derived-mode-parents doesn't fully emulate. And that remove-derived-mode-parent can sever that part of the relation (and only that part). > It should modify our .dir-locals.el and Eglot's database to > remove special entries for TS modes As Dmitry mentioned: if that is done just like that it will break Eglot's support of ts modes in any Emacs which doesn't have Stefan's patch. But we could easily add some compatibility code to Eglot that does the same thing as the patch in ad-hoc fashion, and then remove that code (much later) on. Also, I know this mail is long enough, but apropos Eglot's database, it's getting quite large as you may notice. Another, much more natural way to simplify it would be, if major-modes started setting eglot-server-program (singular) buffer-locally variable which takes precedence over eglot-server-programs. Jo=C3=A3o