From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Adding support for xref jumping to headers/interfaces Date: Mon, 13 Nov 2023 01:24:39 +0000 Message-ID: References: <835ybb3txt.fsf@gnu.org> <83wn3q311i.fsf@gnu.org> <412afa2d-5dbc-52da-39c4-99be3873929c@yandex.ru> <83o7p20wdi.fsf@gnu.org> <72b09256-5a1b-8962-9e3c-7d2ffd0dc0d7@yandex.ru> <83ilf925n8.fsf@gnu.org> <95afa441-18ae-e62a-be16-be73a545bbba@yandex.ru> <54cb435f-4d51-4c0d-43d8-2991dd7ee6bd@gutov.dev> <4b0b05a2-8c83-7026-4310-327d595dfd8a@gutov.dev> <87cywg8mx0.fsf@catern.com> <098566e5-50aa-d742-e4d5-7ecc8b3e2ec2@gutov.dev> 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="20901"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Spencer Baugh , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 13 02:22:51 2023 Return-path: Envelope-to: ged-emacs-devel@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 1r2Lf8-0005FS-NA for ged-emacs-devel@m.gmane-mx.org; Mon, 13 Nov 2023 02:22:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r2LeB-0003pI-O8; Sun, 12 Nov 2023 20:21:51 -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 1r2Le9-0003ox-Ge for emacs-devel@gnu.org; Sun, 12 Nov 2023 20:21:49 -0500 Original-Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r2Le7-0004Yh-Pc for emacs-devel@gnu.org; Sun, 12 Nov 2023 20:21:49 -0500 Original-Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-507975d34e8so5608435e87.1 for ; Sun, 12 Nov 2023 17:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699838506; x=1700443306; darn=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=TVD3SOWWzs7cNWpQyOd3YRMxW7zzdkXu95Gu+czjzkM=; b=L833ZEKH+2VR8W+34g4dOP6p3go40+c7eVuQSrSo4yCEOjJQpP4bDUuDfrQp+PtraM wdas+dqXGwCiq/7LLiNyCF350MFqyefuFLIE/KOLKW/SHNPHEZFAUFMyKz7dnVmWDx2w v5S0A5GF1+4qL++TJKUaDVUlBnz7chs/RiOJdgq4gC2HcQi8WYBGund6YS7hYp13gshk gL/Mq64i69BPwHxx8PdRDl091sv7utTe4Z9AXkxyoz07bl8hLyWGPG8SZViOxTF2vg5e ODW4cL583A2QJ1+vOxfozCQVL9vLuYWH3RkuZLD3YlgiZwfNLEDAHwH6SJ7AmI1lrGgD xtww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699838506; x=1700443306; 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=TVD3SOWWzs7cNWpQyOd3YRMxW7zzdkXu95Gu+czjzkM=; b=nCoWLUuffWNpdk34cd+xxd2K4G4roj/ijt1oTa+Diud5HJIe9fVn/8o38f4oQipO69 Xnz4IXw3Lyjpp6q/TjGpcTrwsJOcRt7OLMvxVzt8Y4l254KgnxmDCKLhnlv+RBhvnMnJ PnZniy6U0nG7EVUs1ETBP6AcgoudvSyIv+9e41R39Zw87x7DYBUgTtEbrY8wdUSCdaWz ryWqEgpaEk44yGEgYSg4Xdrebp5oMMdoYb3pLLu/70ReytLqRkVHjcfSetPgDZnwTanf FMvR6pnOE3WWoA4XzdnYK3mvNMZ921zzxF6IVhh4fa8gPbPg/MBkVS3jEW8CeyY73cuv BpuQ== X-Gm-Message-State: AOJu0YwnykHeumWbFfXYg152pg4kRr8HY3tKI39rqgyKB2iaFbR9/zxE 9MA/de4u3NiCrB6EzZFglWa0I8XAh0amMv1iyGs= X-Google-Smtp-Source: AGHT+IGY/t5/ro8NqTKkV+dJLMcum10Az41g8o3bHjbF2/21vvQLc2yuIg3LZ/BbJ8Kkz/ABWoGAnOlDFhQLs7e3+bs= X-Received: by 2002:a05:6512:214d:b0:507:9d5d:5901 with SMTP id s13-20020a056512214d00b005079d5d5901mr3316769lfr.7.1699838505634; Sun, 12 Nov 2023 17:21:45 -0800 (PST) In-Reply-To: <098566e5-50aa-d742-e4d5-7ecc8b3e2ec2@gutov.dev> Received-SPF: pass client-ip=2a00:1450:4864:20::12b; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x12b.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:312676 Archived-At: On Mon, Nov 13, 2023 at 1:03=E2=80=AFAM Dmitry Gutov wro= te: > > On 12/11/2023 04:25, Jo=C3=A3o T=C3=A1vora wrote: > > On Sun, Nov 12, 2023 at 2:10=E2=80=AFAM Dmitry Gutov = wrote: > >> > >> On 12/11/2023 04:08, Jo=C3=A3o T=C3=A1vora wrote: > >>> Noooo. Eglot only does LSP things! > >> > >> Server-specific extensions are LSP things, in my book. Okay, it might > >> not be in eglot.el itself, but then someone will create > >> eglot-superduperclang.el to support those extensions. > > > > Could be, but why can't this code live in c++-ts-mode? > > What about c++-mode users? Or the devoted sm-c-mode aficionados? Happy to put it an a superduperclang.el file required by both of them. I have my doubts Alan would like that, it took too much discussion just to convince him to set a flymake variable some years ago. > And it would be odd if c++-ts-mode would only function as expected > together with Eglot -- at the very least, it will be a challenge to > explain this to the users. It would function OK without it. Just as it does now. Just no cross-referencing support. Much like python.el works without a python interpreter, but better with it. > >>> The major mode may do that if > >>> it has another alternative backend, or if it knows it is using LSP > >>> with a specific language server, like 'superduperclangdfork'. > >> > >> I'm pretty sure major modes that are specific to the language server i= n > >> use are a bad idea. > > > > You may have misunderstood my suggestion. > > > > I'm saying code specific to certain languages, LSP-based on not, > > should always live in major mode files and have major-mode prefixes. > > We're not just talking about features specific to a language, but > features specific to a certain potential future version of a language > server, which might or might not be available through a certain LSP > client/Xref backend, someday. > > Otherwise we could just add those commands now, right? > > Aside from the issue of multiple major modes existing for a number of > important languages. > > > It's always been like this. The LSP server program doesn't have > > to be available for themajor mode to work, but it works better > > with it. > > And the "...but it works better with it" has often been expressed in > terms of minor modes. E.g. SLIME/Sly/CIDER/lots of others. Yes, you can use an extra minor mode if you want or not. But Eglot by itself is not that minor mode. > Etags might be put into that category too (you have to build tags first > to use it) -- and all of its language-specific concerns (how to build > tags, for example? which flags are preferred) never found its way its > major modes. > > > Major modes already do this. For example, you don't _have_ to > > have a Python interpreter program to use python-mode.el to edit > > Python code, but having one enables M-x run-python of course. > > And run-python uses comint.el which is a library that python.el > > relies on. > > The Python interpreter always came pre-installed with Python. Yes, but you don't have to install Python to edit python code in Emacs, do you? > Anyway... this was a digression that's probably not important for now. > Whether the new advanced commands are defined in Eglot or in major > modes, should have no bearing on what we do now, or whether we add a new > set of "common" commands to xref.el. I think it does, because the new advanced commands may become just as popular or more as what you say as "common" commands. This is the "slippery slope" part of my argument. The other part of my argument is that the "common" commands you want to import from LSP isn't really that great and that you don't _need_ to, because major modes. Also I think that this particular decision doesn't need to be taken now. Whichever way we go, it won't invalidate what's in the Git branch right now. Jo=C3=A3o