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 14:45:31 +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> <834jfoq86m.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="37673"; 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 15:46:14 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 1rMqtJ-0009aV-TE for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Jan 2024 15:46:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rMqt6-0007Z0-MN; Mon, 08 Jan 2024 09:46:00 -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 1rMqt1-0007Yl-U6 for bug-gnu-emacs@gnu.org; Mon, 08 Jan 2024 09:45: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 1rMqt1-00048V-LY for bug-gnu-emacs@gnu.org; Mon, 08 Jan 2024 09:45:55 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rMqt7-0004JG-Ro for bug-gnu-emacs@gnu.org; Mon, 08 Jan 2024 09:46: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 14:46: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.170472515916317 (code B ref 68246); Mon, 08 Jan 2024 14:46:01 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 8 Jan 2024 14:45:59 +0000 Original-Received: from localhost ([127.0.0.1]:35644 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMqt4-0004ET-Li for submit@debbugs.gnu.org; Mon, 08 Jan 2024 09:45:59 -0500 Original-Received: from mail-lj1-x229.google.com ([2a00:1450:4864:20::229]:57386) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMqt2-00042T-Jo for 68246@debbugs.gnu.org; Mon, 08 Jan 2024 09:45:57 -0500 Original-Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-2cce6c719caso19905141fa.2 for <68246@debbugs.gnu.org>; Mon, 08 Jan 2024 06:45:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704725144; x=1705329944; 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=6gfEcqvawwJ3kUqnOI6nwLO/5t6So0AfaJZXt4GfGQA=; b=KdMog+QHCO3twG3fIti39bFQtQd48kXyCfElN+Ae6zVh/FH913rI1s5pxwO8HCz6dl kM1LsHV478VOdXwUD/PAA2mZfXqteUCgOztjsyfK7+fNPltZrWv+6L83ww2XnBbLByhi gC9zsuX0BBAY4i2DOuofqHWMNgKB7RWTbdX0VS6RZ75o1mamiSdLhgLCKuENSVueHKeA CZluZAch99q6G7x8uwQESDvO1T6R8Df/qvHyrbBqlKVojQRMH2ixpkdFRlVIvI44/u6X lTK0nzz5ke3TjFjYpKm1t5rXFwRw921GPRrwE+O8Abjyx9mNK3D0GU62PejN8sGmKJuq MOeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704725144; x=1705329944; 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=6gfEcqvawwJ3kUqnOI6nwLO/5t6So0AfaJZXt4GfGQA=; b=FQnnycP+kp0yxbFnzUR63eoOgl14E3UKNj3oHBxtq62k0oCtEEchv581AFvXZm/9k6 lS+6VXVKZy2Rqb+SQLO9sMDCzZVDJ3gpwiQPJkNxoEz3Yld3EwovnRXgD8u0PhQ3Uex1 Y/VoM2/Pu/zELAQkc7979Y/4ZD9vCXnitbUclKc3b/sFBhZICooM7jcXjgtMxXvPJXzZ KTxwdeUu/wE8Tzd5aOjFDRcFJKw60mt+IMJBT+KlhCSgt1OpOwYxxe/6v10ETOuJu/Pp PAxkKku2e9TiPsExwdAxii0kvyBmMKl2kQf6BJVMPsdxX7t0Su/ptB2DtzAF4xY12vHn kFqg== X-Gm-Message-State: AOJu0YzXLbjAd17nHuKohFQA25kqA701xwJBV0fsMtOxqcku2akNIXvN Dt8wLSCQGyvIbvQOF7DOIE0RrIiteL8/vMHYraE= X-Google-Smtp-Source: AGHT+IFUtXBfPLvEpFlL/wFo2gHlmzwOo085XTqDQlSd9zfP7/mEp/eiBpSHApjWYoZ7UeQJAZhpicuBJZ+XQkb3UPY= X-Received: by 2002:a2e:be8d:0:b0:2cd:4c5c:7b8b with SMTP id a13-20020a2ebe8d000000b002cd4c5c7b8bmr1251231ljr.34.1704725144066; Mon, 08 Jan 2024 06:45:44 -0800 (PST) In-Reply-To: <834jfoq86m.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:277561 Archived-At: On Mon, Jan 8, 2024 at 1:14=E2=80=AFPM Eli Zaretskii wrote: > > > 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. > > It's "leaky" because it "leaks" the idea that it should be a > "language". Oh right, of course. Who came with this "leaky" idea that there are programming languages are 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. > > Eglot should not rely on the assumption that the "language", whatever > it is, is included verbatim in the mode's symbol name. Neither should > Eglot assume anything else about the name of the mode. You could have capped it off with "neither should it work" for maximum consistency. Else, it has to have this database itself. And so does Yasnippet and likely others. This is what Stefan had to say about it: > > 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". So that's why I formalized what others had already proposed, but you bash it with whatever random CS adjectives you find at hand. > > 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? > > Eglot provides hooks to do that. ??? I think it's better to not answer when you don't have an answer.