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: Sat, 6 Jan 2024 00:16:02 +0000 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="12721"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jan 06 01:17:12 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 1rLuNE-0002wK-ES for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Jan 2024 01:17:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rLuN1-0003EP-G5; Fri, 05 Jan 2024 19:16: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 1rLuN0-0003EG-2K for bug-gnu-emacs@gnu.org; Fri, 05 Jan 2024 19:16: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 1rLuMz-000614-Po for bug-gnu-emacs@gnu.org; Fri, 05 Jan 2024 19:16:57 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rLuN4-0003Qg-0q for bug-gnu-emacs@gnu.org; Fri, 05 Jan 2024 19:17:02 -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: Sat, 06 Jan 2024 00:17: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.170450018912693 (code B ref 68246); Sat, 06 Jan 2024 00:17:01 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 6 Jan 2024 00:16:29 +0000 Original-Received: from localhost ([127.0.0.1]:58147 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLuMW-0003Hw-QR for submit@debbugs.gnu.org; Fri, 05 Jan 2024 19:16:29 -0500 Original-Received: from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b]:57369) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLuMT-0003Ay-J5 for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 19:16:26 -0500 Original-Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-2cce6c719caso774021fa.2 for <68246@debbugs.gnu.org>; Fri, 05 Jan 2024 16:16:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704500175; x=1705104975; 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=R662cBevtu78MocBPURfWzwf3WYX+muP/lGQgZEB+dc=; b=nIjgSVZlFpbqi7iUQ/UfGIQ13Z64jcFWJcw0E8MnJ9S1g/zqhU34wLLfFB1d8tV7/2 Bsg15pXcuRwboKG8LRuI3fEKHVWSo+ISvKKwjqjZ67Xo2Bd+9HfxJ8YKjA6NYiPUstqI euT4uUbyOBE6yjmD7U4FX+V2LpLjQ6RrKPJxgIu7FlK04pT25HQSy9L/C/BwXTYypOyL LEvlz+QmJOHafcNgfM7XPnRTdKKcuQLvUldZx6M70IAxwZ5yY8NnhInSTMHzEZCk0Ir5 XQiFxwyjyUIwKDXlOwuLc3+l93dl9RhjTW0wrviXb2DG2tjzE02gxCVgvLvmBttfpu1+ 3E1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704500175; x=1705104975; 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=R662cBevtu78MocBPURfWzwf3WYX+muP/lGQgZEB+dc=; b=J3YGZGrTgXnhYNel6UhPlTBf05jnkdSIQJWFFm6e66qAoV7PQKmQ3PnqfvmCMuTaxB /2IEtQaOFMfSVq14+BJ3PKkt38B+fhhQOlZaDyEsRc52+Q3K6qV5AZMURelIcQlg69Tf L0u9PKXs+mj8nm2o+r5TFJs2AQH0rJTpKu1Mb7Uum/tg6Fneoq+xgdeUWmIgUJ5OO0Pg 1r/tBRU3p9BoveFmVTbl3L3FVbRGn6rmDnG7KX/HGE9m4RmVbGGwZj18Z1bwL5MzUm1g gkI/769R9ByheIo2L9224nmf+rNQfD2s2y3br3fV88zWSyKxoBKf4RpG+YhXYtO7g1f5 ABGA== X-Gm-Message-State: AOJu0YxA3BviVzsSLNQs19kApD8QDhPhX/CMmzRJr8InSmPW1Tihvw/E aXC2goi2hluyvCbZpVEVYEoyMK/nseRL78xgryg= X-Google-Smtp-Source: AGHT+IGU8u5WlgfGshe0BEN9s18qGzeDeCBt76TNbsb5+BTkGULh5RSJ/L5g45QsOI0R8KBqu3kzM8pU6pbdd1yQr5s= X-Received: by 2002:a2e:98d7:0:b0:2cc:d4e2:e0b1 with SMTP id s23-20020a2e98d7000000b002ccd4e2e0b1mr66812ljj.1.1704500174453; Fri, 05 Jan 2024 16:16:14 -0800 (PST) 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:277424 Archived-At: On Fri, Jan 5, 2024 at 11:51=E2=80=AFPM Stefan Monnier wrote: > > [ IMO, it would indeed be a good idea to try and write some abstraction > layer so we can share more code between modes parsing with > syntax-tables/tree-sitter/wisi/SMIE/younameit. It will also be very > useful when tree-sitter goes the way of the dodo. Very relevant. > But that's a difficult job, and with limited immediately-visible > benefits to the end users. In the mean time, we're stuck with major > modes that don't share much code. ] > > Whether it's worthwhile to have a `FOO-base-mode` or not depends on > the specifics, but it's largely an implementation detail. More > importantly it's not directly relevant to this here bug, because > I want to say "FOO-ts-mode is a kind of mode for FOO, so it's > a kind of FOO-mode". OK, so "kind". So you seem to want to FOO-mode designates a family of modes for FOO. That's reasonable but it has the confusing property that the name of the family coincides with the name of one of the members of the family. Using inheritance for that just seems a bit off, like a hack. Really what we wanted is a new variable called 'mode-family' and test against that. > There are very few YASnippets for FOO-base-mode, > instead they're all for FOO-mode. Similarly, Eglot doesn't have rules > for FOO-base-mode, only for FOO-mode. Right. But we can change Eglot and Yasnippet, can't we? I know what to do in Eglot, which is something like this: (defvar eglot-server-programs `(((rust-ts-mode rust-mode) . ("rust-analyze= r")) ((cmake-mode cmake-ts-mode) . ("cmake-language-server")) (vimrc-mode . ("vim-language-server" "--stdio")) - ((python-mode python-ts-mode) + (python-base-mode . ,(eglot-alternatives In Yasnippet, if I remember correctly (it was a long time ago), the snippet directory could either be renamed foo-base-mode or something in a .yas-parents inside that directory can be added containing "foo-base-mode". As to the problem that this doesn't work in Emacs < 30, we must either: * also keep the old definitions, or better * use compat.el like Eli suggested to bring in those new base modes (whereby compat.el could use derive-mode-add-parent itself, but for but adding foo-base-mode as a parent of foo-mode and foo-ts-mode instead). > That's why in my patch I add `python-mode` as an extra parent of > `python-ts-mode` even though they both share `python-base-mode` as > their parent. Right, that's what sounds hacky to me. They're siblings, but now one also is the parent of the other. Maybe it works, but is definitely odd. That said, if it works, I'm not really opposed to it. What other packages do you know like Eglot and Yasnippet which use major-mode in this way. > IOW, in my patch, I'm using `FOO-mode` not really as the name of a major > mode, but rather as the name of a *file type*. > I already mentioned this distinction in the bug-report where > I introduced `major-mode-remap-alist`: Emacs usually conflates > file-type and major-mode, which works great where there's only one major > mode for a given file type, but less great where there are > several alternatives. Agree, so your "file-type" seems to match my idea of "mode family". So a new variable called file-type would be the correct abstraction. And I don't see how "foo-base-mode" is much worse, modulo slightly more akward naming and backward compatibility problems that you would have anyway. Jo=C3=A3o