From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.devel Subject: Re: Adding support for xref jumping to headers/interfaces Date: Tue, 16 May 2023 17:10:40 -0400 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25378"; mail-complaints-to="usenet@ciao.gmane.io" 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 To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 17 04:23:08 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 1pz6ol-0006Mc-O8 for ged-emacs-devel@m.gmane-mx.org; Wed, 17 May 2023 04:23:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pz6ny-00018W-8N; Tue, 16 May 2023 22:22:18 -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 1pz1wd-0000OO-Ev for emacs-devel@gnu.org; Tue, 16 May 2023 17:10:55 -0400 Original-Received: from mxout5.mail.janestreet.com ([64.215.233.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pz1wb-0005Uo-Hz for emacs-devel@gnu.org; Tue, 16 May 2023 17:10:55 -0400 Original-Received: from mail-yw1-f198.google.com ([209.85.128.198]) by mxgoog2.mail.janestreet.com with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) (Exim 4.96) id 1pz1wZ-008Nlh-00 for emacs-devel@gnu.org; Tue, 16 May 2023 17:10:52 -0400 Original-Received: by mail-yw1-f198.google.com with SMTP id 00721157ae682-5618c444144so20579377b3.0 for ; Tue, 16 May 2023 14:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; t=1684271452; x=1686863452; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jqFxWJ5lOobivN5Ra+YCbwLGSZRYBD2dKDfNaQI9FEQ=; b=AmFKeo9LXZOnp4sbW6k5HxiFfo052f+GPEJ2JdMI6q3Y6vlcZVC696Izu0py4ZMceJ pjH7XCxUCNqsgJ2HAUMOKHNQBvveOCofqTvpeP0Us1Vj4A0OX6IfBEK3anbe14L5+xKB lk+svtC1kKeyaxxj1cdaOPFaKPSAPSuRrXA68= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684271452; x=1686863452; h=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=jqFxWJ5lOobivN5Ra+YCbwLGSZRYBD2dKDfNaQI9FEQ=; b=SJSgKVHz/YN4OFilD4TCGp9Pd0DQ8rvKe1dypTLHcAGxcu4ZM67E5LpENdMg5HxZRC bIQra6OyRroXFNFBPKBWTXC7GKh79Uto0mQT6kVX0BB15CIlNJWGclVVtqmKmjVZ3yh4 PbnJIIkzOknV/l4TW2j0nNg96yTWB38QMAVDEnZynAyWE8riCv/lHL+Jo1fOsGIzd2E3 Wo7coTgW5NZzJkyjXF+gd4YyjTOy6wCAWbSXuFbpBhaemP/Q7Ex3sjg3wLNa+EKMf+fB p87Bu018oyq1zqTb4xwQJKTo4ot0L1WAh7/u9PjhGsefk5rgSunghhVgCx54TCZ/h8B7 8NhQ== X-Gm-Message-State: AC+VfDyoQdCSIjV0FLGuB2YXgFtckd6JbGVFgs9V6PRnhqO5FiDY0qIp 2Xd2nrQE2+tIQwbEzez2apeRCYzkQHMaUVX5nrJpGGp3Ag2ORh3mdvERaZ9vAkyBStF+ASGi60W Ash/pIhtdt9kVj9pkc74vnmc7lO0= X-Received: by 2002:a0d:f505:0:b0:55a:ad90:8df2 with SMTP id e5-20020a0df505000000b0055aad908df2mr33417270ywf.38.1684271451813; Tue, 16 May 2023 14:10:51 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7tirqXjLKBZ3p1Bfi5UsfkJKKoUXkcF7OJUdM173HGZcGFOGbX44xyg9y1AWbL8XQpxcX2i3YIA9CEh0si3TI= X-Received: by 2002:a0d:f505:0:b0:55a:ad90:8df2 with SMTP id e5-20020a0df505000000b0055aad908df2mr33417263ywf.38.1684271451605; Tue, 16 May 2023 14:10:51 -0700 (PDT) In-Reply-To: <95afa441-18ae-e62a-be16-be73a545bbba@yandex.ru> Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@janestreet.com; helo=mxout5.mail.janestreet.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, 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-Mailman-Approved-At: Tue, 16 May 2023 22:22:17 -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:306152 Archived-At: 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.