From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Adding support for xref jumping to headers/interfaces Date: Mon, 13 Nov 2023 03:02:57 +0200 Message-ID: <098566e5-50aa-d742-e4d5-7ecc8b3e2ec2@gutov.dev> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8914"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: Spencer Baugh , emacs-devel@gnu.org To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 13 02:03:35 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 1r2LMU-00025N-GK for ged-emacs-devel@m.gmane-mx.org; Mon, 13 Nov 2023 02:03:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r2LM4-0004YK-W5; Sun, 12 Nov 2023 20:03:09 -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 1r2LM2-0004XW-1T for emacs-devel@gnu.org; Sun, 12 Nov 2023 20:03:06 -0500 Original-Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r2LLz-0000Ub-LP for emacs-devel@gnu.org; Sun, 12 Nov 2023 20:03:05 -0500 Original-Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.west.internal (Postfix) with ESMTP id CCCB6320027A; Sun, 12 Nov 2023 20:03:00 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Sun, 12 Nov 2023 20:03:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1699837380; x=1699923780; bh=6PpG2xZ0MNIodEo3GEVv+L0A2LkFHqVlyup jLHGMvKs=; b=eakEm0od6Tq5s7qjU1KGbXszAEZN9YSmPL64Sy/9EAibKR1slRm s5MQGoP6dc9QevCIUsAbQEQOeDWfSOOXftGjMD/unhaJIRnlm0Vlcwl60/CwOGaH pg+tYzESajc7yL3TSeN+KZY9uOlD6+LuCFqIzXFdsInM6BSHkXT1KYW3ZPxXvAeZ MfWOSUj4Nis9XrWoFUHzpEymWuPJtbYEkYcTGWJzH/ZGFlsdo12X3ym3RmoaAkmu 5ZhgImm/Vb/ntT7frZ9902s2Ln1Nv5OgQQzVhodYUTjDtT3gKFXjgcxM4W+vV6Xp jfkwyLFJVbl3UyFjMfA4XJ8egt3wmWqxo0A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1699837380; x=1699923780; bh=6PpG2xZ0MNIodEo3GEVv+L0A2LkFHqVlyup jLHGMvKs=; b=SN18xxpx3rXxXgdHXsdzJAZnSvVM8+Fy9G+hrgvuX0vjn6HNHrS 5/0xqR0++FxpWeJK5dJfVkKHizkhZeVzfvXDqiZBT6QE+I/ccJbpnpyYjHXYUF/I rpGJTUKacAbmdk1Up3CgxpAV4GZ0flW3qAcWFPikMLXryA2QKC+fTvCH/p3JR1bg T+NaWn6k2KM9lPB6yPjn8G3zBT/bNNMoJaocd26C7WDCghsUOOKdH2csHhsrelCD UCVUcXbfbrBGencb6BYJI2Nd9jomoexMy0ljGSvX+hGjjPmQQSL0hQOtmzv19BXO 8/yDxMh978t0qtMKcBF0e0PSq9BjD1rzTOw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddvledgfedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhephfffheeljeffgeffueeghfekkedtfffgheejvdegjeettdduheeufffggfef jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 12 Nov 2023 20:02:59 -0500 (EST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=64.147.123.25; envelope-from=dmitry@gutov.dev; helo=wout2-smtp.messagingengine.com X-Spam_score_int: -53 X-Spam_score: -5.4 X-Spam_bar: ----- X-Spam_report: (-5.4 / 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, NICE_REPLY_A=-2.553, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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:312673 Archived-At: On 12/11/2023 04:25, João Távora wrote: > On Sun, Nov 12, 2023 at 2:10 AM Dmitry Gutov wrote: >> >> On 12/11/2023 04:08, João Távora 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? 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. >>> 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 in >> 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. 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. 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.