From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Adding support for xref jumping to headers/interfaces Date: Wed, 17 May 2023 14:46:05 +0300 Message-ID: <83lehnxjsy.fsf@gnu.org> References: <83bklin83z.fsf@gnu.org> <865ybmu2ha.fsf@stephe-leake.org> <39e25c9a-b4cc-a0ce-3f2a-1d2a1fc243d0@yandex.ru> <83pm9sfxfa.fsf@gnu.org> <861qm4tkih.fsf@stephe-leake.org> <71ea5e83-183f-2ae3-8146-6a31045a0309@yandex.ru> <834jqzafse.fsf@gnu.org> <83h6uv47e8.fsf@gnu.org> <4639d7ca-2109-864c-33c0-38e65f26f262@yandex.ru> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29764"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dgutov@yandex.ru, stephen_leake@stephe-leake.org, john@yates-sheets.org, rms@gnu.org, fgunbin@fastmail.fm, casouri@gmail.com, emacs-devel@gnu.org, azeng@janestreet.com To: Spencer Baugh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 17 13:48:25 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 1pzFdo-0007Xm-M4 for ged-emacs-devel@m.gmane-mx.org; Wed, 17 May 2023 13:48:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pzFd5-0007oP-Nd; Wed, 17 May 2023 07:47:39 -0400 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 1pzFd4-0007lz-13 for emacs-devel@gnu.org; Wed, 17 May 2023 07:47:38 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pzFd2-0007nB-Pn; Wed, 17 May 2023 07:47:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=swkzYN1LOCpgcWKY71Drthg6t3OaYNvwpgqo97PMBEo=; b=FuuqKme3sawZ daODZqZXte307c6QuaFw2mQPTqCBLDLnTDnogCu/iozrxEJxlJP56Ago+3aEKFMI8JDST+nv97ecB ZMxrlh7d4l/YxEv+7oE0VM+aYVIhr6r0OFWWc4gCN0jRmMsW++QQAVRBWCI7qrXe34PYr/dQ3kutg pTBPFveDeKYFw4fDNQSxI+2fVp83eKt3U3ZZFPdJs4TvMCRcUF6uYvsu2V5bi0lHZCSeNENGVmFex MUMktKHB/swM+qsrEScDRyWMu44z938TA5ognA76ZJRz2mKyxTuctOM5It+MWPTMx3J4zw4N/qjqj dLkTzLgXaG6Ex5XpCRkQow==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pzFbQ-0003s5-AL; Wed, 17 May 2023 07:46:14 -0400 In-Reply-To: (message from Spencer Baugh on Tue, 16 May 2023 17:10:40 -0400) 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:306158 Archived-At: > From: Spencer Baugh > Date: Tue, 16 May 2023 17:10:40 -0400 > Cc: Eli Zaretskii , stephen_leake@stephe-leake.org, john@yates-sheets.org, > rms@gnu.org, fgunbin@fastmail.fm, casouri@gmail.com, emacs-devel@gnu.org, > azeng@janestreet.com > > An option I didn't mention originally: Perhaps xref-find-definitions > could just show both implementation and interface. That would remove > the need for any new keybindings. The UI might be worse but perhaps > it could be improved. > > This is inspired by this comment: > https://github.com/joaotavora/eglot/issues/302#issuecomment-534202561 > > The relevant excerpt: > > By the way, on a tangent, I think it's a mistake on LSP's part to > > import C++/Java's ecosystem of possible symbol loci. In Common Lisp, > > there are many different types of construct associated with a symbol > > and they are all "definitions". A good IDE like SLIME will use > > something akin to xref-find-definitions (indeed xref is modelled after > > SLIME) and categorize them properly in the result buffer if there is > > more than one. So the command should have been textDocument/definition > > with some kind of subtype parameter, or at least this is where xref > > should evolve to, i.e. xref should keep the single command > > xref-find-definitions and maybe augment it with some "definition-type" > > parameter. IME, in at least some OOP environments, definition and interface are considered to be very different things. It is possible that CL is not one of them (after all, the OOP model of Lisp is quite different from that of, say, C++ and Java). So I'm not sure lumping these two together will be welcome by everyone. Especially since you seem to suggest that the format of the *XREF* buffer also be changed to include the indication of which is which.