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: Mon, 8 Jan 2024 10:50:57 +0000 Message-ID: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.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="15040"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68246@debbugs.gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 08 11:52:20 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 1rMnEx-0003i5-5Q for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Jan 2024 11:52:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rMnEg-0001k5-8Q; Mon, 08 Jan 2024 05:52:02 -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 1rMnEa-0001bF-53 for bug-gnu-emacs@gnu.org; Mon, 08 Jan 2024 05:51:56 -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 1rMnEZ-0004W9-Sc for bug-gnu-emacs@gnu.org; Mon, 08 Jan 2024 05:51:55 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rMnEf-0007OZ-Vb for bug-gnu-emacs@gnu.org; Mon, 08 Jan 2024 05:52: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: Mon, 08 Jan 2024 10:52: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.170471108528354 (code B ref 68246); Mon, 08 Jan 2024 10:52:01 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 8 Jan 2024 10:51:25 +0000 Original-Received: from localhost ([127.0.0.1]:35299 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMnE4-0007ND-TQ for submit@debbugs.gnu.org; Mon, 08 Jan 2024 05:51:25 -0500 Original-Received: from mail-lj1-x230.google.com ([2a00:1450:4864:20::230]:43065) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMnE1-0007Ma-Jr for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 05:51:22 -0500 Original-Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2ccc6e509c8so23609271fa.0 for <68246@debbugs.gnu.org>; Mon, 08 Jan 2024 02:51:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704711069; x=1705315869; 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=pv2FP9pHKWznrLnnt0hfwN9F+UhDvUWPFogBRky2Hcs=; b=G8WzrVm+3rYfRTIBBhNpGcEibQ2kbV08txAqAEsP920hVUFcHRJIYOmkbmIozXSgh2 PK10GAuYTU+qFHsUxopHhw0N4TaWGZslzvP/pMvWJbXekzGuV7AJnY4sl00xFgRGfNMO 1FJsmm6PGLCp/2U+BiaOEDYzIRlmBF2F6mFEIHd8NHrK6W+Puej2/Eh0cW3Hmk475thO 6YzQXhBCM20si3kZXODUi38w9kn1QIUnQrvi4NN6gtlrbMiV2gGvKHwksYiTPenSH3G4 4xmjyRx0rGoOVmYYt2Ky/+do4zviZrIjjGcaD5gKZkRDutQypl5JPpgDCuVlNw4ttCq/ CFbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704711069; x=1705315869; 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=pv2FP9pHKWznrLnnt0hfwN9F+UhDvUWPFogBRky2Hcs=; b=QEyFtwV3iJGl0Txh9YhTzqLwicHuZhk3rZ4UmBZR8zjwWTiZUYD+nWXooQ7mporcMy lFg17k8bH6zd0+xAT/paQvbt1BsXEH5hzg097DikgCb0ja9OMCqc9Olzs2GCpmPnb0Wv g9d3BqZneK2MU4lmuS/LZkC+XjNgQ04XF6kePBQ7ioPYIf1unN5DUG3nniq+GGbkYLby wKqkEgoPxYNG+wWu0y7A3BLfMPzVMs2z9ZrWImo35TRpGNOhvhl4KhzfjrlvpN6HPJW4 gzEP4DKxVZmkl0f4tDiqa1yiZjVBzxA19L4tfgqJ0anVO3nx2ZDyh5Dv9ooqVmeIT62l 4b/Q== X-Gm-Message-State: AOJu0YxInGEl4KeYn/ED7U4LtZlJ2bPlaEtEt+KZ+1bbaDs97264jqw1 iPbHLQj1h85HY8fylq4o1n988wTiZuoUp+ArBCY= X-Google-Smtp-Source: AGHT+IFE7Kx3w9u0LsUCFZRw+qbTkgMso4ht+1U9z2uEmvpT8w2nwGXixM9/ZgAZ4jBXsjj0z/VEiPwrPRueBwSpjME= X-Received: by 2002:a2e:870c:0:b0:2cd:1993:e5e2 with SMTP id m12-20020a2e870c000000b002cd1993e5e2mr3320432lji.16.1704711068863; Mon, 08 Jan 2024 02:51:08 -0800 (PST) In-Reply-To: <83h6joqz0t.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:277545 Archived-At: On Mon, Jan 8, 2024 at 3:34=E2=80=AFAM Eli Zaretskii wrote: > That's not useful, since, for example, TS and non-TS mods for those > "no-language" modes will still want to be treated the same in some > situations, like .dir-locals.el. Yup, so pass them same :language to them and call `get-language-for-mode` somewhere in the .dir-locals.el machinery? Else suggest to use the base mo= de, if it exists. If it doesn't exist, create it? > It attempts to abstract a trait that isn't abstract, by going in the > opposite direction of that used for abstractions. It's interesting how you state a simple get/set is a "leaky abstraction", but then also not an abstraction at all. Let's put it like this: Eglot should probably fix this actual code: (replace-regexp-in-string "\\(?:-ts\\)?-mode$" "" (symbol-name sym)) to find the language to report to the server. Users should also be relieve= d to write or read :languageId in complicated fashion in eglot-server-program= s. Stefan's doesn't really address this. Fine. But it _will_ affect eglot-server-programs. In fact someone (TM) should come up with a docstrin= g change to e-s-p that at least hints at this concept of "extra parents", since it will start taking effect immediately for some modes, for some Emacs versions. What if an Eglot users wants some server just for the non-TS mode? Or a Yasnippet user some snippets for such a mode? Or even just regular user some directory-local variable value? The fact is that Eglot users, who are sometimes are surprised by mode inheritance as it is will see a more complicated concept come into force (in some Emacs versions, not all). This concept will apply to the python-mode/python-ts-mode pair but not the clojure-mode/clojure-ts-mode one. The following becomes harder to decipher: (add-to-list 'eglot-server-programs (foo-mode "Fooey" "stdio")) It may or may not go together with the typical: (add-hook 'foo-mode-hook 'my-foo-eglot-config) depending on whether the user has Stefan's patch, whether it patches "foo-ts-mode" and depending on the mode the user is running. The more I think about this, the more I think this is problematic. But if you guys are so confident, sure, let's try it. If nothing bad happens great, else I guess I'll refer users to this thread. Jo=C3=A3o