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.bugs Subject: bug#2544: 23.0.60; Could etags please try find a local tag first? Date: Tue, 20 Jul 2021 19:22:41 +0300 Message-ID: References: <7f9b11c90903021336o775a3f75i8bd89f3ae4540cb7@mail.gmail.com> <878s22nyuj.fsf@gnus.org> <8335sa70wp.fsf@gnu.org> <417d5d01-c3a9-a75e-b134-7f1847749842@yandex.ru> <83lf615hfk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13197"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 Cc: larsi@gnus.org, matzikratzi@gmail.com, 2544@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jul 20 18:23:10 2021 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 1m5sWT-0003Bh-Tm for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 20 Jul 2021 18:23:09 +0200 Original-Received: from localhost ([::1]:60514 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m5sWS-0007AO-QM for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 20 Jul 2021 12:23:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39486) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5sWM-0007A5-Gy for bug-gnu-emacs@gnu.org; Tue, 20 Jul 2021 12:23:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51880) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m5sWM-0007in-9Y for bug-gnu-emacs@gnu.org; Tue, 20 Jul 2021 12:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m5sWL-0002D9-RY for bug-gnu-emacs@gnu.org; Tue, 20 Jul 2021 12:23:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 20 Jul 2021 16:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 2544 X-GNU-PR-Package: emacs Original-Received: via spool by 2544-submit@debbugs.gnu.org id=B2544.16267981728468 (code B ref 2544); Tue, 20 Jul 2021 16:23:01 +0000 Original-Received: (at 2544) by debbugs.gnu.org; 20 Jul 2021 16:22:52 +0000 Original-Received: from localhost ([127.0.0.1]:35193 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m5sWB-0002CV-Jv for submit@debbugs.gnu.org; Tue, 20 Jul 2021 12:22:51 -0400 Original-Received: from mail-wm1-f53.google.com ([209.85.128.53]:36413) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m5sW9-0002CI-7L for 2544@debbugs.gnu.org; Tue, 20 Jul 2021 12:22:49 -0400 Original-Received: by mail-wm1-f53.google.com with SMTP id l17-20020a05600c1d11b029021f84fcaf75so1844245wms.1 for <2544@debbugs.gnu.org>; Tue, 20 Jul 2021 09:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SvEL1dKWHry7Hw8YduIweMQsNzt0vLj8VotL0lGb90M=; b=HagZXVAh1tIMhi7/eEJSLLiw0lDfKG51oLM8MsD4acmxrCv9obLkqjhaFyy/LNN1jm 9OCj49XYbad8XXE+DAP/ds92whZF7x2Gjx2ReEyVnP1RKFfBqE4d70l72Bf2Dn+5o9R3 IqvsBoC49xuSDltcl0PjR8XCn2pK7RQu/2xOqsjNgiIPlXhk/q9pcCtnkwmNt4dmRIRM JTp0plTQGEwELa8FGbB27EbzWCYGza/SFi8F4gQo78/H/7FxI7+fRohXbx+n7ABlI3tQ B2crx8hPiPQmKzsUNHBeJwuW/VZUBiD4bnjUIu60ntwVqWWmtwqBIKsayOOaBR6cukFz X04A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SvEL1dKWHry7Hw8YduIweMQsNzt0vLj8VotL0lGb90M=; b=G4ETowRRUj8ub1lPBoDNLEJVktT+4YOpZj0hbiUdhtmH0lLMwl3rGSHrkLU6cRL/BV 9tj+8Och8AOdUkl8XdhIJelUnEmzg7wvooKLZXA6hxwFbnsuKm/F5G3UUV4bRPSWPa3Y iked8lX0U8EF/xq5aHRHMcvh6fBZhLePRHsbai/8cKOgAVqZhniGOi5aqB9x9LFUOpbO I2lvb9E5tngG9ZvIircxMOqFJkiVTg5aUOHc/x5gHaPwDUVLVMThThig8FW4gfzjwJyc wKi2YPF/Rn672ACCtKzbUvzi4BVKKizFrZaymxTNCBk57OxQ3TNWtDQMxhANuZNFPjAF eebQ== X-Gm-Message-State: AOAM5338VrB8ysm0Ozv2VTIDR+OqsuIk1Wh+YxHLUu9TlfHImeoqh4FX UpB8/Js3drGOKCUkltMGoCIb1RkUDPg= X-Google-Smtp-Source: ABdhPJwtRmgj82ZDcIKuTkX2UgOvea2jGrforQiTsVa5nBc/FYIsxwiapEp9znHl2K6MaZzY37k1/g== X-Received: by 2002:a7b:c351:: with SMTP id l17mr32708163wmj.120.1626798163334; Tue, 20 Jul 2021 09:22:43 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id e3sm24289928wra.15.2021.07.20.09.22.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jul 2021 09:22:42 -0700 (PDT) In-Reply-To: <83lf615hfk.fsf@gnu.org> Content-Language: en-US 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" Xref: news.gmane.io gmane.emacs.bugs:210377 Archived-At: On 20.07.2021 14:54, Eli Zaretskii wrote: >> Cc: matzikratzi@gmail.com, 2544@debbugs.gnu.org >> From: Dmitry Gutov >> Date: Tue, 20 Jul 2021 02:00:31 +0300 >> >> On 19.07.2021 18:56, Eli Zaretskii wrote: >>> As for the original request: I guess we could satisfy that by having >>> Xref sort the matches so that those in the current buffer come first >>> in the display we show in the*XREF* buffer? Dmitry, would it make >>> sense to add such an option, and if so, would it be hard to do so? In >>> xref--alistify, perhaps, or in xref--analyze? >> >> It would probably better work as an etags option (residing next to >> etags-xref-find-definitions-tag-order): Xref, in general, cannot know in >> advance whether a given tags resides in the current buffer, and >> following all tags is relatively costly. > > But then this feature will be reserved only for the etags backend, no? > > Maybe there should be a backend-specific sorting method or something? Not 100% sure how that could work, but I'm reasonably certain that "prioritize hits in the current file" is mostly relevant to etags. Because when one uses more precise backends, "find definition" gets fewer hits, and you don't really need to choose which ones to start with -- the current file or otherwise. Even if there are exceptions, I think only etags has the problem mentioned below. Other backends could simply always prioritize the current file, no user option needed. >> I was thinking to suggest having that behavior on by default (and maybe >> avoid adding a new variable altogether), but it seems to conflict with >> the intention behind etags-xref-find-definitions-tag-order, so probably not. > > Right. ^^^ the aforementioned problem.