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 22:22:49 +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="26391"; 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 23:24:21 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 1rMF5Z-0006d6-7s for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Jan 2024 23:24:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rMF5D-0002Qg-0F; Sat, 06 Jan 2024 17:23: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 1rMF5B-0002Pp-A9 for bug-gnu-emacs@gnu.org; Sat, 06 Jan 2024 17:23: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 1rMF5B-0005zs-12 for bug-gnu-emacs@gnu.org; Sat, 06 Jan 2024 17:23:57 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rMF5F-00064T-Tq for bug-gnu-emacs@gnu.org; Sat, 06 Jan 2024 17:24: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: Sat, 06 Jan 2024 22:24: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.170457979523278 (code B ref 68246); Sat, 06 Jan 2024 22:24:01 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 6 Jan 2024 22:23:15 +0000 Original-Received: from localhost ([127.0.0.1]:60376 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMF4V-00063O-7y for submit@debbugs.gnu.org; Sat, 06 Jan 2024 17:23:15 -0500 Original-Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]:47536) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMF4T-00062v-G3 for 68246@debbugs.gnu.org; Sat, 06 Jan 2024 17:23:14 -0500 Original-Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2cd1eac006eso6022241fa.3 for <68246@debbugs.gnu.org>; Sat, 06 Jan 2024 14:23:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704579782; x=1705184582; 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=cEVB2m+0/K5ByPhVLII9X2jCjVYdrnqOv8OCt95VFao=; b=BZzyeY/KzP+MwIz8Z4u7mgu/4nZ1MR/IaGh6skYDXmWep4GdSH6SPljRo6XmmCZbZt cwks+2x9mcvvz5oaFQsMbtXKa46LQR5j00CBXWZ90g+A29rQGHaltv/SNwS5JrLVN/R6 mhPckUkQiLYfYv1Zb5oJptFDDylTPgzSg7cJTmA6GPzP5DbOjuZ+p/PybVipp+7Sdohf 4S9f5dT/5JK3X7oeg58GYRTM9odPUc9wje89oQcTNnVG9LQZOQXHhvCoTVrWv7/r3/No L/6007wETtHb8JVFDKRbEyP8cKqFW2esRkoVkuC+k2In2jLgREUo6kDQobnOhM1QReJG Ocow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704579782; x=1705184582; 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=cEVB2m+0/K5ByPhVLII9X2jCjVYdrnqOv8OCt95VFao=; b=pWxJdqDkON36Gi5yLX12DIggmKVppUhveYma1jEPBQDxb1YHw4o2agDFK7R8pxcD9u jqMj6eSnPzM4JKvsgcJ6jlpIjH0FJGtrLa2Pyn6oQzwwGiqRhI+HC6W7MMfGI6ObRlYI q/vgg+q0B2n8c5lE96wYEWxGJxteihwwPPmvJl3DJcP/usQ/ow2RdFnjumHkxcm5AQLs XtPYAuYlMLNopDjcVNFprNijLPVBNAVtifglZiMlJZ+j9r5/8M4xjL1+/pU42Zv+eZ1v QjN1dOZAUU7JpOsbjpgdR/gsrD7mdK1AIoRAf+xA/n+g1CJl0QD6ykejXSv8MftKk4qY zAHA== X-Gm-Message-State: AOJu0YzWRNqEhXETZJio4os9ptaweI9YPmB4ZzxyolHkeF9p8DAFa9zy UiNvdAKZJMjlx7KLM2SoRO1k6XhFRH/rZaSw5js= X-Google-Smtp-Source: AGHT+IEw+lAsiN3tPNdm1bSOZHVjTnE+T7pQezgNTOb3hF5oXb+2s6Be+gKQ6YQBtlGGTq9LAKDkY8JxukK8rOqf+jg= X-Received: by 2002:a2e:8555:0:b0:2cd:22e8:a71b with SMTP id u21-20020a2e8555000000b002cd22e8a71bmr393657ljj.85.1704579781612; Sat, 06 Jan 2024 14:23:01 -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:277479 Archived-At: On Sat, Jan 6, 2024 at 3:50=E2=80=AFPM Stefan Monnier wrote: > > > Personally, I think if Eglot, YASnippet and CEDET are all we > > actually know about, I think it's very simple to fix 2 out of three (ev= en > > _without_ the "base mode"). And the 3 out of 3 I _think_ I can > > fix once someone points me to what exactly it should do. > > I don't think embedding (repeatedly) in YASnippet, CEDET, Eglot, ffap, > lsp-mode, (and all the others that I don't happen to know offhand) the > knowledge that `FOO-ts-mode` is used for the same files as `FOO-mode` > qualifies as "fixing". Not ideal, yes. Depends on what needs to be done for each package. It would be good if we knew that. I'll only speak for Eglot, YASnippet and possibly for lsp-mode. These 3 packages need to know the language of the buffer they are operating on. That's ultimately and definitely what they want. They do that with major-modes, because that has very often been a good correspondence, often a 1-to-1, but not always. The N-to-1 problem is not new with ts modes, it has long existed (Yasnippet is turning 15!). > Instead, I'd call it "working around the lack of info which should be > provided by the mode". The way my patch does it may not be The Right > Way (tho the jury is still out on this), but at least it provides the > info at the right place. Yes. If by "at the right place" you mean "nearby the major modes definitions themselves", yes I agree. If you want to solve this problem cleanly, or more cleanly than it is also solved now, I'm all for it. I just think "extra parents" is a clumsy a abstraction, though it can be used as an implementation aid. For simplifying the existing ways these 3 packages already solve the problem, I propose that instead of calling 'derived-mode-add-pare= nts' directly near the mode definitions, we instead do something like: (set-language-for-mode 'foo-ts-mode 'foo) As a first implementation, this might just as well expand to (derived-mode-add-parents 'foo-ts-mode 'foo-mode) I.e. it will be 100% your solution. `derived-mode-p` will be affected as you want and hopefully everything will keep working as usual (not necessarily "start working" except for packages not aware of TS modes at all). But of course that's not all, because with very little work it also provides for: (get-language-for-mode 'foo-ts-mode) ; =3D> 'foo And _that's_ when Eglot, Yasnippet, very likely lsp-mode and possibly many others will see actual simplifications. If we like this idea, I also think supporting a :language keyword to 'define-derived-mode' is natural. Obviously, it would just expand to that 'set-language-for mode' and default to whatever comes before the "-mode" in the symbol. So in summary this is what I think -- from the perspective of these 2/3 minor modes. Yes this introduces the concept of "language", but I think -- in fact I'm sure given the interactions I've had with new Eglot users -- that "language" is a much simpler concept to grasp than "extra parents". Finally, how to give this to packages outside the tree? The usual route: do it in core and package it either in compat.el or in a :core GNU Elpa package, like we did for external-completion.el. Keep the derived-mode-add-parents (and add a "remove" counterpart), but suggest them as last resort options/hammers. Jo=C3=A3o