Received: (at 28407) by debbugs.gnu.org; 25 Jun 2022 15:14:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 25 11:14:28 2022 Received: from localhost ([127.0.0.1]:46035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1o57US-0007ax-FV for submit <at> debbugs.gnu.org; Sat, 25 Jun 2022 11:14:28 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41278) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1o57UP-0007aj-QV for 28407 <at> debbugs.gnu.org; Sat, 25 Jun 2022 11:14:26 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33374) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1o57UJ-0002sF-Bf; Sat, 25 Jun 2022 11:14:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=JhF3r64XGq5Ql5XAwtQuP62Bwi4ZYmDbhY2Xnn5kmfE=; b=qUqSleXog4nhNdHy+0i8 mqqaVTTQBcIkBWIYq52Dpx8Ca3I7qUUSKsf3psUaA0KNd/0EbZBx0/Gci9JwoomtmKuju8yIL8P4D ZHiaj2fgBQmn/LQAjEPRSEV0NtQ9vnDyEFgIJiK/JJAv0tLTMFi7NyTtlzILOdMKpFb0SjgVTQFUj x1BfHoPGoJo7nfkIHMbw8fXyLhoz9K01AX7BNZ+risROffdn1crMiRUD7zMMqeIZY1Nju4OYcoO4v ZcjYlHjgcmNhsgaUfxsFRNo/jenl87SOzjOa8+6+0Qv13Ddkxh/u2qSKA/pyQA+HDuHRAOkoLmTdC QKIcq5nlEtiR6g==; Received: from [87.69.77.57] (port=3415 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1o57UI-0002nV-9q; Sat, 25 Jun 2022 11:14:19 -0400 Date: Sat, 25 Jun 2022 18:14:15 +0300 Message-Id: <83v8soai7s.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Visuwesh <visuweshm@HIDDEN> In-Reply-To: <87fsjs3j2y.fsf@HIDDEN> (message from Visuwesh on Sat, 25 Jun 2022 20:07:25 +0530) Subject: Re: bug#28407: 26.0.50; xref should use imenu References: <87h8wa8quw.fsf@bapiya> <3238a206-240a-aa76-87c0-bcb3bdfa00dc@HIDDEN> <87y1z35630.fsf@HIDDEN> <87zgjic68h.fsf@HIDDEN> <2a6aec56-4f72-5064-c001-e7aa46144f9d@HIDDEN> <87mtez1wn9.fsf@HIDDEN> <9c56d537-fe2c-a9ea-686a-aa9ff110f1ab@HIDDEN> <87o7yg3klb.fsf@HIDDEN> <83wnd4akqa.fsf@HIDDEN> <87fsjs3j2y.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 28407 Cc: tom@HIDDEN, 28407 <at> debbugs.gnu.org, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Visuwesh <visuweshm@HIDDEN> > Cc: tom@HIDDEN, 28407 <at> debbugs.gnu.org, dgutov@HIDDEN > Date: Sat, 25 Jun 2022 20:07:25 +0530 > > [சனி ஜூன் 25, 2022] Eli Zaretskii wrote: > > > In general, when you visit a new TAGS file, etags asks you whether to > > replace the previous one or to keep them both. Maybe the way you > > "switch to another project" somehow hides that prompt/decision? > > It does ask me to replace the previous one but I expected Emacs to > restrict the TAGS file to the buffer I selected it from That'd be against the purpose of TAGS tables: their explicit purpose is to allow you to find definitions in _other_ files. And Emacs cannot know whether the fact that you loaded another TAGS table means that you want to "forget" about the previous one, as long as you keep it loaded.
bug-gnu-emacs@HIDDEN:bug#28407; Package emacs.
Full text available.Received: (at 28407) by debbugs.gnu.org; 25 Jun 2022 14:37:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 25 10:37:42 2022 Received: from localhost ([127.0.0.1]:45994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1o56ur-0004Uf-OG for submit <at> debbugs.gnu.org; Sat, 25 Jun 2022 10:37:41 -0400 Received: from mail-pl1-f195.google.com ([209.85.214.195]:33334) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <visuweshm@HIDDEN>) id 1o56um-0004UN-Nx for 28407 <at> debbugs.gnu.org; Sat, 25 Jun 2022 10:37:39 -0400 Received: by mail-pl1-f195.google.com with SMTP id n10so4560829plp.0 for <28407 <at> debbugs.gnu.org>; Sat, 25 Jun 2022 07:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=IksTOXwFG4ImIOqov9gBm3yxMMB5Ul+d/+lWJpfdiB0=; b=HearfT4ytlTdtlV5/IoiYQCG1xjgv+gn/9NZt82K0TYOdCEYOR+La3JQ7BtbOQmA9A L84C6YUWXBUj/6nTZ617DPeD6JesvJtG9ZSBy2ycueuS21zymyLEY74oMp6tospofxLd 7ROTT1MilDb3xui/EEV60ixileZX/ktVahTk4c13Pbl7c9QeTE6vTwjocEcjZ0Byr4u3 LQvyAnDWA3GEgnsO8OayIXyxDVLlmhX2Be0/PUOevwdPs4zifGsKTCd60yvUFDjN2HEX mWyGMvvUe2hiQ+rDWEss/NiW/l5wy2V25M5wuDcFtrzjk8Dv1R+axaA4hYdPQc6480Ag qv0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=IksTOXwFG4ImIOqov9gBm3yxMMB5Ul+d/+lWJpfdiB0=; b=s8PMHFfS4l9Sog5EbULPuOHOUTvoNovFtUPxOkXKsQtarpzQ9530FrSs2pvKIBIro+ OGFimBDy4AQ18bLUToRbdqwNijZicXm7A7Fv2OaUC3GQ31lRswqaLCRvEMSWQCZ0BqYU 0+XnQw3Kxy3m+XHviY+yTBcnG8ux9ylhmZchAuzN9QOG0m3K539wtTUcw3pQ8EoK6o+6 emaHAWDul2bU+AFe6UwtBlEe9BsbgOMs8sA91kFs/zjbUrgzgV8tgxwNu/AxnodCTwlW 8EJW6zOMafvcEjnIxmeHEStsfHF8xVL0LxZaoy67IN/41nZH/wuDFWHEEkC2KMB03T24 utxw== X-Gm-Message-State: AJIora9kOjSc/fr6zFaTa9I6s79FTw99Ubi/j+7RKLvo6SqOEe7ff6YO tlwkb7TrUZwsOkTCnTKMMf8= X-Google-Smtp-Source: AGRyM1sRVU4yntS36z8F+zYGHQG4J4W2zje4+IjwodjJr2xkbb6jyweyK1YtiMwXqV+v20saV5x8ug== X-Received: by 2002:a17:902:bb8d:b0:168:e48d:86bc with SMTP id m13-20020a170902bb8d00b00168e48d86bcmr4748039pls.93.1656167850871; Sat, 25 Jun 2022 07:37:30 -0700 (PDT) Received: from localhost ([49.204.119.36]) by smtp.gmail.com with ESMTPSA id l127-20020a632585000000b0040c4f60f649sm3514038pgl.13.2022.06.25.07.37.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 25 Jun 2022 07:37:30 -0700 (PDT) From: Visuwesh <visuweshm@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#28407: 26.0.50; xref should use imenu References: <87h8wa8quw.fsf@bapiya> <3238a206-240a-aa76-87c0-bcb3bdfa00dc@HIDDEN> <87y1z35630.fsf@HIDDEN> <87zgjic68h.fsf@HIDDEN> <2a6aec56-4f72-5064-c001-e7aa46144f9d@HIDDEN> <87mtez1wn9.fsf@HIDDEN> <9c56d537-fe2c-a9ea-686a-aa9ff110f1ab@HIDDEN> <87o7yg3klb.fsf@HIDDEN> <83wnd4akqa.fsf@HIDDEN> Date: Sat, 25 Jun 2022 20:07:25 +0530 In-Reply-To: <83wnd4akqa.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 25 Jun 2022 17:19:57 +0300") Message-ID: <87fsjs3j2y.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 28407 Cc: tom@HIDDEN, 28407 <at> debbugs.gnu.org, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) [=E0=AE=9A=E0=AE=A9=E0=AE=BF =E0=AE=9C=E0=AF=82=E0=AE=A9=E0=AF=8D 25, 2022]= Eli Zaretskii wrote: >> Cc: Tom Tromey <tom@HIDDEN>, 28407 <at> debbugs.gnu.org >> From: Visuwesh <visuweshm@HIDDEN> >> Date: Sat, 25 Jun 2022 19:34:48 +0530 >>=20 >> [ To elaborate, say that I visited the TAGS residing in Emacs' src/ >> directory then switched to another project. Now, if I do C-u >> M-. Fplist_get RET, then it will take me to the Emacs project!! This >> seems to be a general problem with the etags backend tho. ] > > In general, when you visit a new TAGS file, etags asks you whether to > replace the previous one or to keep them both. Maybe the way you > "switch to another project" somehow hides that prompt/decision? It does ask me to replace the previous one but I expected Emacs to restrict the TAGS file to the buffer I selected it from, mostly because I was mislead to believe the check (or tags-table-files tags-file-name) would work that way. [ The check is from a previous revision of my patch. ]
bug-gnu-emacs@HIDDEN:bug#28407; Package emacs.
Full text available.Received: (at 28407) by debbugs.gnu.org; 25 Jun 2022 14:20:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 25 10:20:23 2022 Received: from localhost ([127.0.0.1]:45971 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1o56e7-00042r-97 for submit <at> debbugs.gnu.org; Sat, 25 Jun 2022 10:20:23 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60518) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1o56dq-00041t-2M for 28407 <at> debbugs.gnu.org; Sat, 25 Jun 2022 10:20:21 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:32906) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1o56dk-000899-Ml; Sat, 25 Jun 2022 10:20:00 -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=c6cs+YNiAJKrY+7544FlOx6sB0Qhe/DMAdfQCwmGDsw=; b=ebZNmQNIg3K+ kIEIHct1aX26BZMo+BwJ4emPBXJ59byGhQMRfkaidnd2c6wC3Y/OItFoMwvxhV+YDQsfgm/vKtHGt i+2xdeIojAYU0aaZtKDGzY8fKkVNdvpYhD39ZW06Yo1KHdx1dk/TdHcKVYnbROX9yLD0HNPHk8bcL J+8oKrZm/nYifnmg1Yc2PsBSPX01qwSbrsKtvqaFFUuTbVhNg8VCfhT1/IaSnHc0m9QuCGVX91PYs O4xOd5raAoBQvmMEoqyVsxHmVYMDH1W/EyFBshwEyK9KgebJgw6f277fvlY7wEpDQ9s4qnMW1op79 NFn+1zDRuhi4vUGnKLgCkA==; Received: from [87.69.77.57] (port=4073 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1o56dk-0001H1-41; Sat, 25 Jun 2022 10:20:00 -0400 Date: Sat, 25 Jun 2022 17:19:57 +0300 Message-Id: <83wnd4akqa.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Visuwesh <visuweshm@HIDDEN> In-Reply-To: <87o7yg3klb.fsf@HIDDEN> (message from Visuwesh on Sat, 25 Jun 2022 19:34:48 +0530) Subject: Re: bug#28407: 26.0.50; xref should use imenu References: <87h8wa8quw.fsf@bapiya> <3238a206-240a-aa76-87c0-bcb3bdfa00dc@HIDDEN> <87y1z35630.fsf@HIDDEN> <87zgjic68h.fsf@HIDDEN> <2a6aec56-4f72-5064-c001-e7aa46144f9d@HIDDEN> <87mtez1wn9.fsf@HIDDEN> <9c56d537-fe2c-a9ea-686a-aa9ff110f1ab@HIDDEN> <87o7yg3klb.fsf@HIDDEN> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 28407 Cc: tom@HIDDEN, 28407 <at> debbugs.gnu.org, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: Tom Tromey <tom@HIDDEN>, 28407 <at> debbugs.gnu.org > From: Visuwesh <visuweshm@HIDDEN> > Date: Sat, 25 Jun 2022 19:34:48 +0530 > > [ To elaborate, say that I visited the TAGS residing in Emacs' src/ > directory then switched to another project. Now, if I do C-u > M-. Fplist_get RET, then it will take me to the Emacs project!! This > seems to be a general problem with the etags backend tho. ] In general, when you visit a new TAGS file, etags asks you whether to replace the previous one or to keep them both. Maybe the way you "switch to another project" somehow hides that prompt/decision?
bug-gnu-emacs@HIDDEN:bug#28407; Package emacs.
Full text available.
Received: (at 28407) by debbugs.gnu.org; 25 Jun 2022 14:05:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 25 10:05:10 2022
Received: from localhost ([127.0.0.1]:45943 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1o56PN-0003g5-7I
for submit <at> debbugs.gnu.org; Sat, 25 Jun 2022 10:05:10 -0400
Received: from mail-pj1-f65.google.com ([209.85.216.65]:39463)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <visuweshm@HIDDEN>) id 1o56PI-0003fU-Qa
for 28407 <at> debbugs.gnu.org; Sat, 25 Jun 2022 10:05:07 -0400
Received: by mail-pj1-f65.google.com with SMTP id
b12-20020a17090a6acc00b001ec2b181c98so8225747pjm.4
for <28407 <at> debbugs.gnu.org>; Sat, 25 Jun 2022 07:05:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=from:to:cc:subject:references:date:in-reply-to:message-id
:user-agent:mime-version;
bh=zr1x1QgMXd3KTVqULKsQ464fyMkqX+i2J3kltA9AYY4=;
b=Ay1tut3B6YNyjoR7sgZPgPZYQ+T6dB1+RJIWdjLmxVFkT3aWRrPlP1BJ3ce3JS4ncK
aZctdw7FHZ23D5FdyK9fLbetYqICKtvguxliTsquSwvNbv9SYqFX8brtxoXbg+01GQZe
jblYkU4SubLFawNe1a2uWo5IAulUa1GjrCioz79nrawrEGCyuXp0UCD1hBM4P5aMFT9b
lS7fq+mr2m0xFE8+l9vB9EOePefg/f+OfzrtmnmcPGwhZChOHeIxT7rs/kob39g1SMBQ
sfr74KxE3N9SHJKZ5KkrBra964jC8OxgiPaps4LadZ3rTXp3g+r7KyGVDaMopeOfIb7e
Q5Zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
:message-id:user-agent:mime-version;
bh=zr1x1QgMXd3KTVqULKsQ464fyMkqX+i2J3kltA9AYY4=;
b=rnR4egVtkAmtftstSxiNz1FVsUIl45E34Y1xVHdkBYGjZwiqXpHLgOgdNK104j+tY6
wV7QjvNnDrskWYBQRzyUUaKhAxqa1JiOB51TD0MpRwvHGwUzlNqfYg/AV4vsN8BI8Rfp
ZyRblhg9hygHAlwgAXnAx/SL7wbgFjfJfdPFtzXiYOxPNxwGgc+8rSUZuCwoxLrc+k+e
2/wRrRYfYTJcTbhI6m1zT+k7hfGCN8jsc/h0UXhpiSKrOTjtCBL1peLVVnuFkZvS0VGU
mTKxTWqoLE1dPIzIRMScAOpQSUQ66Sw/8cFsjxKWQtip/Uw3C2BFiynbmfED5En6HSYQ
RItA==
X-Gm-Message-State: AJIora+N4OUvVCmndeeJ5VbMJiCquwxK/RPul0bHoRVlfvYzwCFGzTSA
i22TaaTIVuFuAQCUqUQx/dk=
X-Google-Smtp-Source: AGRyM1v/7F485G+MCazYWDI8zGAZCTPlIFpy6+AkoT5AeumkhMG5VvKGXfVCsos6GCtqjEo7RZZDkA==
X-Received: by 2002:a17:902:ea02:b0:16a:57bb:d344 with SMTP id
s2-20020a170902ea0200b0016a57bbd344mr4494455plg.150.1656165898928;
Sat, 25 Jun 2022 07:04:58 -0700 (PDT)
Received: from localhost ([49.204.119.36]) by smtp.gmail.com with ESMTPSA id
t19-20020a63dd13000000b00401a9bc0f33sm3508532pgg.85.2022.06.25.07.04.56
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 25 Jun 2022 07:04:57 -0700 (PDT)
From: Visuwesh <visuweshm@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#28407: 26.0.50; xref should use imenu
References: <87h8wa8quw.fsf@bapiya>
<3238a206-240a-aa76-87c0-bcb3bdfa00dc@HIDDEN>
<87y1z35630.fsf@HIDDEN> <87zgjic68h.fsf@HIDDEN>
<2a6aec56-4f72-5064-c001-e7aa46144f9d@HIDDEN>
<87mtez1wn9.fsf@HIDDEN>
<9c56d537-fe2c-a9ea-686a-aa9ff110f1ab@HIDDEN>
Date: Sat, 25 Jun 2022 19:34:48 +0530
In-Reply-To: <9c56d537-fe2c-a9ea-686a-aa9ff110f1ab@HIDDEN> (Dmitry Gutov's
message of "Sat, 4 Jun 2022 03:56:51 +0300")
Message-ID: <87o7yg3klb.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 28407
Cc: Tom Tromey <tom@HIDDEN>, 28407 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
[=E0=AE=9A=E0=AE=A9=E0=AE=BF =E0=AE=9C=E0=AF=82=E0=AE=A9=E0=AF=8D 04, 2022]=
Dmitry Gutov wrote:
Hello Dmitry,
It took me too long to reply since I did not have the immediate need of
this backend and so wasn't too interested in writing it. Sorry about
that.
>> Do we really need something like this? Can we not let the user
>> handle
>> it themselves by adding/removing the imenu backend in .dir-locals.el?
>
> IDK, .dir-locals.el is per-directory. To have per-file effect one
> would need to use the file-locals section inside the file, which some
> might find undesirable.
>
> Anyway, the kind of defcustoms I was talking about are something to be
> considered for a later addition.
>
OK, I will leave it for the future.
>> Also what's the right way to check if a TAGS table is defined for the
>> current buffer? I currently have,
>> (or tags-table-files tags-file-name)
>
> Seems okay.
>
>>> As long as it comes before etags in xref-backend-functions, it should
>>> have all the power. Another possible direction for its development
>>> would be to always try to combine the locations coming from both etags
>>> and imenu (in the current file).
>> Yes, this sounds attractive but then we would be limiting ourselves
>> to
>> etags. IMO, xref trying another backend when one fails to produce a
>> match would be a better solution in the long term.
>> [ I, for one, would like to have imenu and elisp backends working at the
>> same time. ]
>
> As an alternative, the IMenu backend could look inside the list of
> backends that follow it and try to combine itself with the next one
> manually.
>
I tried this and the results really depend on the imenu indices. As for
example, python-mode really loves to add junk to the index name so this
combine-all thingy does not place too nicely but, it is still usable.
> A feature like "always use the next one" has been requested before,
> but so far no implementation that everybody would like has been
> proposed.
>
My combination thingy works along these lines. Currently, if the
identifier is not found in imenu indices, then I check the backends
following the imenu one. It works satisfactorily. Although, there
might be a problem with deleting duplicates: a simple `delete-dups' does
not work. I'm not sure how to compare two xref items independently of
their type (type as in buffer location, etc.).
One problem right now though is the TAGS table used by the etags backend
and the one actually corresponding to the focused file might be
different. Maybe I should specially handle the etags backend? WDYT?
[ To elaborate, say that I visited the TAGS residing in Emacs' src/
directory then switched to another project. Now, if I do C-u
M-. Fplist_get RET, then it will take me to the Emacs project!! This
seems to be a general problem with the etags backend tho. ]
> Also note that such approach is difficult to make behave
> consistently. E.g. we have identifier completion -- and it would
> (probably) only work for the first backend, but then navigation,
> somehow, would still be able to jump to the symbols indexed by the
> following backends. No matter which one comes first (etags or imenu),
> that doesn't sound ideal.
>
Looks like my logic can handle this case just fine. In xdisp.c, I tried
C-u M-. Fplist_get RET and the imenu backend used the etags backend to
jump to the definition.=20=20
>
> I think converting it to a simpler structure would indeed be a better
> choice. I am concerned about this code being to stay
> language-agnostic, though.
>
> If you have entries like "checkforlink (def)", how do you reliably
> extract the actual method name from it? Or if you don't it wouldn't
> match what xref-backend-identifier-at-point returns.
>
I don't think you have to worry about the backend staying language
agnostic. In the case of python, I have a few imenu customisations:
(defun vz/python-imenu-hook ()
(setq imenu-name-lookup-function (lambda (symbol item) (string-prefix=
-p symbol item))
python-imenu-format-parent-item-jump-label-function (lambda (_ =
name) name)
imenu-create-index-function
(lambda () (vz/imenu-create-index-function #'python-imenu-creat=
e-index))))
The `string-prefix-p' ensures that the imenu xref backend does not choke
on the " (def)" part.
>> But perhaps handling this "path-tree" in xref-backend-definitions would
>> not hurt after all. I can spin this up if you think this is better
>> moving forward.
>
> Thanks.
>
Now done.
>> Some other questions follow:
>> 1. I was thinking about adding a buffer-local function for the
>> identifier-at-point instead of hard-coding (thing-at-point 'symb=
ol)
>> to let major-modes like org-mode and auctex-mode behave more
>> smartly. WDYT?
>
> See what etags does in find-tag--default. Maybe you could just
> delegate to it, just like etags's xref-backend-identifier-at-point
> override does.
>
I added a variable `imenu-xref-identifier-function'. If this is not
what you had in mind, do tell.
>> 2. When implementing the apropos method for the backend, should we
>> let pattern match against the whole "path-tree" or just the last
>> part of it?
>
> Can't say for sure. Depends on how hard that would be to implement, I gue=
ss.
I'm leaving the apropos bit to the future=E2=84=A2 as well.
On the performance part, it does not seem to be too bad but the only
large file I tested it on was xdisp.c: the imenu backend performed
really well once the initial hiccup of generating the imenu index alist
was done.
Hopefully, I covered everything that needed to be addressed.
Attaching updated patch.
--=-=-=
Content-Type: text/x-diff
Content-Disposition: attachment; filename=0001-Add-imenu-xref-backend.patch
From 43779948d064453942dc97cacd3e8a4be8048f19 Mon Sep 17 00:00:00 2001
From: Visuwesh <visuweshm@HIDDEN>
Date: Sat, 25 Jun 2022 19:32:49 +0530
Subject: [PATCH] Add imenu xref backend
* imenu.el (imenu--in-alist): Add new optional argument.
(imenu-xref-backend): New xref backend.
(imenu-xref-identifier-function, imenu-xref--following-backends): Add.
(imenu-xref--make-summary, imenu-xref--make-location)
(imenu-xref--flatten): Add helper functions.
(xref-backend-identifier-at-point, xref-backend-definitions)
(xref-backend-identifier-completion-ignore-case)
(xref-backend-identifier-completion-table): Add 'imenu' method.
(bug#28407)
---
lisp/imenu.el | 101 +++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 96 insertions(+), 5 deletions(-)
diff --git a/lisp/imenu.el b/lisp/imenu.el
index 4393c6ed6c..9820de54e3 100644
--- a/lisp/imenu.el
+++ b/lisp/imenu.el
@@ -52,6 +52,7 @@
;;; Code:
(require 'cl-lib)
+(require 'xref)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;
@@ -473,8 +474,10 @@ imenu--create-keymap
(if cmd (funcall cmd item) item))))))
alist)))
-(defun imenu--in-alist (str alist)
- "Check whether the string STR is contained in multi-level ALIST."
+(defun imenu--in-alist (str alist &optional all)
+ "Check whether the string STR is contained in multi-level ALIST.
+If the optional argument ALL is non-nil, then return all matches
+of STR in ALIST."
(let (elt head tail res)
(setq res nil)
(while alist
@@ -491,12 +494,18 @@ imenu--in-alist
;; We are only interested in the bottom-level elements, so we need to
;; recurse if TAIL is a nested ALIST.
(cond ((imenu--subalist-p elt)
- (if (setq res (imenu--in-alist str tail))
- (setq alist nil)))
+ (let ((r (imenu--in-alist str tail all)))
+ (if all
+ (setq res (append res (if (listp (cdr r)) r (list r))))
+ (setq res r)
+ (when r
+ (setq alist nil)))))
((if imenu-name-lookup-function
(funcall imenu-name-lookup-function str head)
(string= str head))
- (setq alist nil res elt))))
+ (if all
+ (push elt res)
+ (setq alist nil res elt)))))
res))
;;;###autoload
@@ -550,6 +559,88 @@ imenu-default-create-index-function
(t
(imenu-unavailable-error "This buffer cannot use `imenu-default-create-index-function'"))))
+;;;
+;;; Xref backend
+;;;
+
+(defvar-local imenu-xref-identifier-function nil
+ "Function to fetch the identifier for xref.")
+
+;;;###autoload
+(defun imenu-xref-backend ()
+ (unless imenu--index-alist
+ (imenu--make-index-alist))
+ (and imenu--index-alist 'imenu))
+
+(defun imenu-xref--following-backends ()
+ "Return the xref backends following the imenu one."
+ (let (backends)
+ (dolist (b (cdr (memq 'imenu-xref-backend xref-backend-functions)))
+ (when-let ((backend (and (functionp b) (funcall b))))
+ (push backend backends)))
+ (setq backends (nreverse backends))
+ backends))
+
+(cl-defmethod xref-backend-identifier-at-point ((_backend (eql 'imenu)))
+ (or (and imenu-xref-identifier-function
+ (funcall imenu-xref-identifier-function))
+ (thing-at-point 'symbol)))
+
+(defun imenu-xref--make-summary (marker)
+ (with-current-buffer (marker-buffer marker)
+ (save-excursion
+ (goto-char marker)
+ (back-to-indentation)
+ (buffer-substring (point) (point-at-eol)))))
+
+(defun imenu-xref--make-location (item)
+ (xref-make (imenu-xref--make-summary (cdr item))
+ (xref-make-buffer-location (marker-buffer (cdr item))
+ (marker-position (cdr item)))))
+
+(cl-defmethod xref-backend-definitions ((_backend (eql 'imenu)) identifier)
+ (if-let ((pos (string-search imenu-level-separator identifier)))
+ ;; We only care about the exact match here so ALL is nil.
+ (let ((alist (imenu--in-alist (substring identifier 0 pos) imenu--index-alist)))
+ (while (and (listp alist) (listp (cdr alist)))
+ (setq identifier (substring identifier (1+ pos))
+ pos (string-search imenu-level-separator identifier)
+ alist (imenu--in-alist (substring identifier 0 pos) imenu--index-alist)))
+ (list (imenu-xref--make-location alist)))
+ (let ((res (imenu--in-alist identifier imenu--index-alist t))
+ defs)
+ (dolist (item res)
+ (push (imenu-xref--make-location item) defs))
+ (unless defs
+ (dolist (b (imenu-xref--following-backends))
+ (ignore-errors
+ ;; FIXME: This does not catch duplicates!
+ (setq defs (append defs (xref-backend-definitions b identifier))))))
+ defs)))
+
+(cl-defmethod xref-backend-identifier-completion-ignore-case ((_backend (eql 'imenu)))
+ imenu-case-fold-search)
+
+(defun imenu-xref--flatten (alist &optional prefix)
+ (let (res)
+ (dolist (item alist)
+ (if (imenu--subalist-p item)
+ (setq res (append res (imenu-xref--flatten
+ (cdr item)
+ (concat prefix (when prefix imenu-level-separator) (car item)))))
+ (push (cons (concat prefix (when prefix imenu-level-separator) (car item))
+ (cdr item))
+ res)))
+ res))
+
+(cl-defmethod xref-backend-identifier-completion-table ((_backend (eql 'imenu)))
+ (let ((collection (imenu-xref--flatten imenu--index-alist)))
+ (apply #'completion-table-merge
+ (append (list (lambda (string pred action)
+ (complete-with-action action collection string pred)))
+ (mapcar #'xref-backend-identifier-completion-table
+ (imenu-xref--following-backends))))))
+
;;;
;;; Generic index gathering function.
;;;
--
2.35.1
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#28407; Package emacs.
Full text available.
Received: (at 28407) by debbugs.gnu.org; 4 Jun 2022 00:57:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 03 20:57:01 2022
Received: from localhost ([127.0.0.1]:57257 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1nxI68-0003dx-W3
for submit <at> debbugs.gnu.org; Fri, 03 Jun 2022 20:57:01 -0400
Received: from mail-wr1-f53.google.com ([209.85.221.53]:35466)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <raaahh@HIDDEN>) id 1nxI67-0003dk-An
for 28407 <at> debbugs.gnu.org; Fri, 03 Jun 2022 20:57:00 -0400
Received: by mail-wr1-f53.google.com with SMTP id a15so3785756wrh.2
for <28407 <at> debbugs.gnu.org>; Fri, 03 Jun 2022 17:56:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=sender:message-id:date:mime-version:user-agent:subject
:content-language:to:cc:references:from:in-reply-to
:content-transfer-encoding;
bh=1dVtKTSYd0Odb6qj83iHXW4Fwq0JmDePI5mO9M0rsIE=;
b=jFtSzzuJu3lC8V5tIqUJNbqISbAtG1tFjDNHiwNtUr+j554hhjCHY4Wl89H8qixKFs
YLXKqvhQ8ppsHsPEJh13jcERYx1VVsJiftoWCrKm2A6ja0tNVUFpirKtUcQPp7xIwrr9
LgkBSZ3OmlR65jQ/WhXEd7ipONfhTybasabUUKkhZQJEVr+HaE/pI20wAdQ7Pd8IBSs8
5eHHRezMkP2em6v7dXUUg+53wMvnpNbisuFKL/Z8INEdUF/nEHTjjX0k292+TexnwKmP
A2pQqleEhYZW+KgrBRVLcnDRQIOWizFb7yZgJepCAznjxhahEfr5R8ijw3GV+CC/nUL6
iksQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:sender:message-id:date:mime-version:user-agent
:subject:content-language:to:cc:references:from:in-reply-to
:content-transfer-encoding;
bh=1dVtKTSYd0Odb6qj83iHXW4Fwq0JmDePI5mO9M0rsIE=;
b=4hZx/QcnvYxRqkpZBNpdRt6joGkO8U78mw7VFGlcUvidkEpB4ZlFYjFjaX9UBVwIIQ
ntpCvAcfJ+BxWhucn9A6Fz3TgpKRnldKY6UjsWimWM7wAf8GAjHRCw4iaMHM8aTFj2Do
jDqIFm75GieZPPk3G3JIoGVikvz2HWo2G7S63vVzzjH0i2RLBoGACO1vnmXGH3qOqNXz
wYA5I1H9Rjn0k168QvKDDgJVIV85G1W/zIG5GkGE340Cy4u0EGfFksgCW+0LK5q6qly0
1EcWBcpjwM7mF+Xp80cgMad4J3+7uWGDvKxn6lGK1ECB378YuuYNowt6XzTTPkQ5VR3p
fXPg==
X-Gm-Message-State: AOAM533W9/1iEmPcqf7i7WiyVJHey14VQ7P4b24MAzOVaCTTOdaU6cHA
pO8I2EOcJhrnM8XlFfjrWM8=
X-Google-Smtp-Source: ABdhPJzIfreFhu/qvGJGPuwFYYCc/aXB0yPEKbWsw1GSVEUmsZbjupcmgBkDE5QIUvTNGSvCk2ZEdw==
X-Received: by 2002:a5d:4601:0:b0:20d:53a:2f39 with SMTP id
t1-20020a5d4601000000b0020d053a2f39mr10147097wrq.347.1654304213236;
Fri, 03 Jun 2022 17:56:53 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
by smtp.googlemail.com with ESMTPSA id
h4-20020adffd44000000b002102d4ed579sm8566608wrs.39.2022.06.03.17.56.52
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Fri, 03 Jun 2022 17:56:52 -0700 (PDT)
Message-ID: <9c56d537-fe2c-a9ea-686a-aa9ff110f1ab@HIDDEN>
Date: Sat, 4 Jun 2022 03:56:51 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
Subject: Re: bug#28407: 26.0.50; xref should use imenu
Content-Language: en-US
To: Visuwesh <visuweshm@HIDDEN>
References: <87h8wa8quw.fsf@bapiya>
<3238a206-240a-aa76-87c0-bcb3bdfa00dc@HIDDEN> <87y1z35630.fsf@HIDDEN>
<87zgjic68h.fsf@HIDDEN> <2a6aec56-4f72-5064-c001-e7aa46144f9d@HIDDEN>
<87mtez1wn9.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <87mtez1wn9.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 28407
Cc: Tom Tromey <tom@HIDDEN>, 28407 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)
On 30.05.2022 07:18, Visuwesh wrote:
> [திங்கள் மே 30, 2022] Dmitry Gutov wrote:
>
>> Hi Visuwesh,
>>
>
> Hi Dmitry!
>
>> On 16.05.2022 09:59, Visuwesh wrote:
>>> [ஞாயிறு மே 15, 2022] Visuwesh wrote:
>>>
>>>> [திங்கள் செப்டம்பர் 11, 2017] Dmitry Gutov wrote:
>>>>
>>>>> On 9/10/17 7:23 PM, Tom Tromey wrote:
>>>>>> It would be nice if imenu were a back end for xref.
>>>>>> Then M-. could also use symbols found by imenu.
>>>>>> A further wrinkle on this would be if xref, project, and imenu
>>>>>> worked
>>>>>> together, so that M-. would automatically know to look at imenu results
>>>>>> for other buffers in the same project.
>>>>>
>>>>> Agreed. It could be a nice default for when no tags table is currently
>>>>> visited.
>>>>
>>>> I tried to write a general imenu backend in attached file (extracted
>>>> from my init.el) but I hit quite a few roadblocks,
>>>>
>>>> 1. I activate the imenu backend iff there are no tags table defined
>>>> for the buffer but this means that one cannot use the imenu
>>>> backend to jump to definitions for symbols that TAGS do not know
>>>> of currently. I can think of two ways to solve this problem,
>>>>
>>>> (a) Check if the symbol is in TAGS table.
>>>> (b) Modify the etags backend so that the user can say "I have no
>>>> TAGS table for this file/project/whatever."
>>>>
>>>> (a) is definitely not clean, and (b) sounds feasible but similar
>>>> situation can also exist with other backends (like elisp).
>>>>
>>>> I'm lost on how to solve this problem.
>>>>
>>>> 2. I have not defined all the methods and the completion-table does
>>>> not handle the nested case of the index alist. AFAIU from `(elisp)
>>>> Programmed Completion', completion "ends" when `try-completion'
>>>> returns t but I seem to be mistaken. I have to rewrite
>>>> completion-table to be like `imenu--completion-buffer' but I don't
>>>> know how to pull that off.
>>>>
>>>> 3. `imenu-xref--in-alist' is mostly a 1-1 copy of `imenu--in-alist'
>>>> with the only difference being my function returns all matches of
>>>> the symbol instead of just the first one. This should be easy
>>>> enough to fix by adding an optional argument INCLUDE-ALL to
>>>> `imenu--in-alist'.
>>>>
>>>> I'm testing in python-mode with the following settings,
>>>>
>>>> (setq imenu-name-lookup-function (lambda (symbol item) (string-prefix-p symbol item))
>>>> python-imenu-format-parent-item-jump-label-function (lambda (_ name) name))
>>> I solved (2) by using an affixation function. I did (3) as well,
>>> and
>>> I'm attaching my work as a patch against imenu.el.
>>
>> (1) sounds reasonable because the reference might easily be in another
>> file. If you wanted to add extra customizations (for the user to be
>> able to indicated things like "use imenu for xref in these files"),
>> maybe add it to this backend's options.
>
> Do we really need something like this? Can we not let the user handle
> it themselves by adding/removing the imenu backend in .dir-locals.el?
IDK, .dir-locals.el is per-directory. To have per-file effect one would
need to use the file-locals section inside the file, which some might
find undesirable.
Anyway, the kind of defcustoms I was talking about are something to be
considered for a later addition.
> Also what's the right way to check if a TAGS table is defined for the
> current buffer? I currently have,
>
> (or tags-table-files tags-file-name)
Seems okay.
>> As long as it comes before etags in xref-backend-functions, it should
>> have all the power. Another possible direction for its development
>> would be to always try to combine the locations coming from both etags
>> and imenu (in the current file).
>
> Yes, this sounds attractive but then we would be limiting ourselves to
> etags. IMO, xref trying another backend when one fails to produce a
> match would be a better solution in the long term.
> [ I, for one, would like to have imenu and elisp backends working at the
> same time. ]
As an alternative, the IMenu backend could look inside the list of
backends that follow it and try to combine itself with the next one
manually.
A feature like "always use the next one" has been requested before, but
so far no implementation that everybody would like has been proposed.
Also note that such approach is difficult to make behave consistently.
E.g. we have identifier completion -- and it would (probably) only work
for the first backend, but then navigation, somehow, would still be able
to jump to the symbols indexed by the following backends. No matter
which one comes first (etags or imenu), that doesn't sound ideal.
Yes another approach, would be to program a "backend combinator"
function. Then people would be able to slap together a bunch of
backends, but all of them would be queried together eagerly, so it's not
a failover-like solution.
>> I would leave that to a later revision, though. Some testing for
>> performance regressions in large projects would be nice too.
>
> Indeed. Unfortunately, I don't have any large projects on hand. All
> the testing I did was in a small python script of mine.
>
>> (2) Could you try to explain the problem that you were solving here?
>> affixation-function is normally about how the completions look (I
>> think). Would 'completion-table-with-predicate' help? Or maybe you
>> just need to pre-process the nested structure into a "flat" completion
>> table first.
>
> I did the pre-processing but I hit a block wrt how the
> xref-backend-definitions method worked. To illustrate, in the test file
> that I had I have a function that goes like
>
> def do1():
> ...
>
> def checkforlink1():
> ...
>
> def checkforlink2():
> ...
>
> def sortlinks():
> ...
> def weight():
> ...
>
> def checkforlink():
> ...
>
> and the imenu--index-alist for this part looks like
>
> ("do1 (def)"
> ("do1" . #<marker at 2413 in rdscrape.py>)
> ("checkforlink1 (def)" . #<marker at 2850 in rdscrape.py>)
> ("checkforlink2 (def)" . #<marker at 3363 in rdscrape.py>)
> ("sortlinks (def)"
> ("sortlinks" . #<marker at 3721 in rdscrape.py>)
> ("weight (def)" . #<marker at 3747 in rdscrape.py>))
> ("checkforlink (def)" . #<marker at 4121 in rdscrape.py>))
>
> I wrote the flatten function so that it would produce completion
> candidates like
>
> "do1:do1" "do1:checkforlink1 (def)" "do1:checkforlink2 (def)" ... and so
> on.
>
> But the xref-backend-definitions method can only handle the last part of
> it (i.e., "do1" "checkforlink1 (def)"). Since I didn't feel like
> parsing this "path-tree" (for a lack of a better word) would be
> appropriate for xref-backend-definitions, I slapped this "path-tree" as
> cosmetics in the affixation-function instead. Hopefully, this makes
> sense.
I think converting it to a simpler structure would indeed be a better
choice. I am concerned about this code being to stay language-agnostic,
though.
If you have entries like "checkforlink (def)", how do you reliably
extract the actual method name from it? Or if you don't it wouldn't
match what xref-backend-identifier-at-point returns.
> But perhaps handling this "path-tree" in xref-backend-definitions would
> not hurt after all. I can spin this up if you think this is better
> moving forward.
Thanks.
> Some other questions follow:
>
> 1. I was thinking about adding a buffer-local function for the
> identifier-at-point instead of hard-coding (thing-at-point 'symbol)
> to let major-modes like org-mode and auctex-mode behave more
> smartly. WDYT?
See what etags does in find-tag--default. Maybe you could just delegate
to it, just like etags's xref-backend-identifier-at-point override does.
> 2. When implementing the apropos method for the backend, should we
> let pattern match against the whole "path-tree" or just the last
> part of it?
Can't say for sure. Depends on how hard that would be to implement, I guess.
bug-gnu-emacs@HIDDEN:bug#28407; Package emacs.
Full text available.
Received: (at 28407) by debbugs.gnu.org; 30 May 2022 04:18:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 30 00:18:14 2022
Received: from localhost ([127.0.0.1]:42377 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1nvWr7-0002Od-Gd
for submit <at> debbugs.gnu.org; Mon, 30 May 2022 00:18:13 -0400
Received: from mail-pj1-f67.google.com ([209.85.216.67]:44563)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <visuweshm@HIDDEN>) id 1nvWr6-0002OQ-BJ
for 28407 <at> debbugs.gnu.org; Mon, 30 May 2022 00:18:12 -0400
Received: by mail-pj1-f67.google.com with SMTP id
pq9-20020a17090b3d8900b001df622bf81dso9561646pjb.3
for <28407 <at> debbugs.gnu.org>; Sun, 29 May 2022 21:18:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=from:to:cc:subject:references:date:in-reply-to:message-id
:user-agent:mime-version:content-transfer-encoding;
bh=5Vm87OpA49B5ljJCjvcN/R8RrXpGt1gfFKW5ah/9kqs=;
b=ACPZRGIS1ykJPHR0PHylmghqBSFvKX2xCzvdJOTsjvQsU8t0GhyAqWKdIabTf1MQoj
MGn9En1RqWfjPe3EfjGjhRqks5zyUq84MThkgxCnJJuD4VuT7vll5w9AP935JfsbvI8O
CaKkp02wM62NZ8WkpLPlKKXqFcl5+qyZlh1ItBnVRfFBqqCNpu+wr2iaXmhgqv8duwFr
WDwFCmWwoawlh28DCMD5WfbMRNIrpzQCsf8nkJ7XNH5GEzklxuSEordjDYNxbYfG4EuQ
U//OcJ7+vtS+Enu8/5gnoH4XNSG/bj6vw0Vyd0+l6RoWGdvS1XdCcyj1zX3R2oLb/RfG
lphA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
:message-id:user-agent:mime-version:content-transfer-encoding;
bh=5Vm87OpA49B5ljJCjvcN/R8RrXpGt1gfFKW5ah/9kqs=;
b=nZuCuib0QZE2oTTsl9nXukUfImCo3T5kPMJmC8i7M3Vr6uJ9nfoFE3z9WXt+6guAGp
NcNso5EGIMXVsHw5cGPyo7jZHHh82OJfVS/XhSuHjUBiKboavJwF2iQw87qcxpAk9dEe
t5BIKh/R/4NwXHbqyYhpVVukXjNdWM44UE4VQfMtuMLpI1o7V+8H9Xd2I7N3p14NWFfb
RX7tYUeqpyZy6p41JOR7mmlGyy5wuaW8xCAnC9/paRI7WNYNi9F337AGFm+dh6NqcPg+
oObKa+kSe8pJd2bH2VncO36WVPdn01bxR1PV52GrZ412yEeL4ZyKy7JuupQooj01CNV9
1roQ==
X-Gm-Message-State: AOAM532PCFzcVOA+4iwydSfSPWtVihjP/7QDPL3LSvH5qCl171dYDHkg
KRIRx/6wXMk4f18QiY3LjDk=
X-Google-Smtp-Source: ABdhPJz2D9oPnP47ciXB9d90Aoppuj56foASKLA/hSelLb6sdOzo+sWO2FHpVMb1VVALfiMkIoO9ug==
X-Received: by 2002:a17:90b:3ecc:b0:1e0:5eba:e79a with SMTP id
rm12-20020a17090b3ecc00b001e05ebae79amr20723041pjb.57.1653884286416;
Sun, 29 May 2022 21:18:06 -0700 (PDT)
Received: from localhost ([49.204.142.91]) by smtp.gmail.com with ESMTPSA id
b2-20020aa78ec2000000b0051868418b06sm7565017pfr.35.2022.05.29.21.18.04
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sun, 29 May 2022 21:18:05 -0700 (PDT)
From: Visuwesh <visuweshm@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#28407: 26.0.50; xref should use imenu
References: <87h8wa8quw.fsf@bapiya>
<3238a206-240a-aa76-87c0-bcb3bdfa00dc@HIDDEN>
<87y1z35630.fsf@HIDDEN> <87zgjic68h.fsf@HIDDEN>
<2a6aec56-4f72-5064-c001-e7aa46144f9d@HIDDEN>
Date: Mon, 30 May 2022 09:48:02 +0530
In-Reply-To: <2a6aec56-4f72-5064-c001-e7aa46144f9d@HIDDEN> (Dmitry Gutov's
message of "Mon, 30 May 2022 01:13:18 +0300")
Message-ID: <87mtez1wn9.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 28407
Cc: Tom Tromey <tom@HIDDEN>, 28407 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
[=E0=AE=A4=E0=AE=BF=E0=AE=99=E0=AF=8D=E0=AE=95=E0=AE=B3=E0=AF=8D =E0=AE=AE=
=E0=AF=87 30, 2022] Dmitry Gutov wrote:
> Hi Visuwesh,
>
Hi Dmitry!
> On 16.05.2022 09:59, Visuwesh wrote:
>> [=E0=AE=9E=E0=AE=BE=E0=AE=AF=E0=AE=BF=E0=AE=B1=E0=AF=81 =E0=AE=AE=E0=AF=
=87 15, 2022] Visuwesh wrote:
>>=20
>>> [=E0=AE=A4=E0=AE=BF=E0=AE=99=E0=AF=8D=E0=AE=95=E0=AE=B3=E0=AF=8D =E0=AE=
=9A=E0=AF=86=E0=AE=AA=E0=AF=8D=E0=AE=9F=E0=AE=AE=E0=AF=8D=E0=AE=AA=E0=AE=B0=
=E0=AF=8D 11, 2017] Dmitry Gutov wrote:
>>>
>>>> On 9/10/17 7:23 PM, Tom Tromey wrote:
>>>>> It would be nice if imenu were a back end for xref.
>>>>> Then M-. could also use symbols found by imenu.
>>>>> A further wrinkle on this would be if xref, project, and imenu
>>>>> worked
>>>>> together, so that M-. would automatically know to look at imenu resul=
ts
>>>>> for other buffers in the same project.
>>>>
>>>> Agreed. It could be a nice default for when no tags table is currently
>>>> visited.
>>>
>>> I tried to write a general imenu backend in attached file (extracted
>>> from my init.el) but I hit quite a few roadblocks,
>>>
>>> 1. I activate the imenu backend iff there are no tags table defined
>>> for the buffer but this means that one cannot use the imenu
>>> backend to jump to definitions for symbols that TAGS do not know
>>> of currently. I can think of two ways to solve this problem,
>>>
>>> (a) Check if the symbol is in TAGS table.
>>> (b) Modify the etags backend so that the user can say "I have no
>>> TAGS table for this file/project/whatever."
>>>
>>> (a) is definitely not clean, and (b) sounds feasible but similar
>>> situation can also exist with other backends (like elisp).
>>>
>>> I'm lost on how to solve this problem.
>>>
>>> 2. I have not defined all the methods and the completion-table does
>>> not handle the nested case of the index alist. AFAIU from `(elis=
p)
>>> Programmed Completion', completion "ends" when `try-completion'
>>> returns t but I seem to be mistaken. I have to rewrite
>>> completion-table to be like `imenu--completion-buffer' but I don't
>>> know how to pull that off.
>>>
>>> 3. `imenu-xref--in-alist' is mostly a 1-1 copy of `imenu--in-alist'
>>> with the only difference being my function returns all matches of
>>> the symbol instead of just the first one. This should be easy
>>> enough to fix by adding an optional argument INCLUDE-ALL to
>>> `imenu--in-alist'.
>>>
>>> I'm testing in python-mode with the following settings,
>>>
>>> (setq imenu-name-lookup-function (lambda (symbol item) (string-pre=
fix-p symbol item))
>>> python-imenu-format-parent-item-jump-label-function (lambda =
(_ name) name))
>> I solved (2) by using an affixation function. I did (3) as well,
>> and
>> I'm attaching my work as a patch against imenu.el.
>
> (1) sounds reasonable because the reference might easily be in another
> file. If you wanted to add extra customizations (for the user to be
> able to indicated things like "use imenu for xref in these files"),
> maybe add it to this backend's options.=20
Do we really need something like this? Can we not let the user handle
it themselves by adding/removing the imenu backend in .dir-locals.el?
Also what's the right way to check if a TAGS table is defined for the
current buffer? I currently have,
(or tags-table-files tags-file-name)
> As long as it comes before etags in xref-backend-functions, it should
> have all the power. Another possible direction for its development
> would be to always try to combine the locations coming from both etags
> and imenu (in the current file).
Yes, this sounds attractive but then we would be limiting ourselves to
etags. IMO, xref trying another backend when one fails to produce a
match would be a better solution in the long term.
[ I, for one, would like to have imenu and elisp backends working at the
same time. ]
> I would leave that to a later revision, though. Some testing for
> performance regressions in large projects would be nice too.
Indeed. Unfortunately, I don't have any large projects on hand. All
the testing I did was in a small python script of mine.
> (2) Could you try to explain the problem that you were solving here?
> affixation-function is normally about how the completions look (I
> think). Would 'completion-table-with-predicate' help? Or maybe you
> just need to pre-process the nested structure into a "flat" completion
> table first.
I did the pre-processing but I hit a block wrt how the
xref-backend-definitions method worked. To illustrate, in the test file
that I had I have a function that goes like
def do1():
...
=20=20=20=20=20=20=20=20
def checkforlink1():
...
def checkforlink2():
...
def sortlinks():
...
def weight():
...
def checkforlink():
...
and the imenu--index-alist for this part looks like
("do1 (def)"
("do1" . #<marker at 2413 in rdscrape.py>)
("checkforlink1 (def)" . #<marker at 2850 in rdscrape.py>)
("checkforlink2 (def)" . #<marker at 3363 in rdscrape.py>)
("sortlinks (def)"
("sortlinks" . #<marker at 3721 in rdscrape.py>)
("weight (def)" . #<marker at 3747 in rdscrape.py>))
("checkforlink (def)" . #<marker at 4121 in rdscrape.py>))
I wrote the flatten function so that it would produce completion
candidates like
"do1:do1" "do1:checkforlink1 (def)" "do1:checkforlink2 (def)" ... and so
on.
But the xref-backend-definitions method can only handle the last part of
it (i.e., "do1" "checkforlink1 (def)"). Since I didn't feel like
parsing this "path-tree" (for a lack of a better word) would be
appropriate for xref-backend-definitions, I slapped this "path-tree" as
cosmetics in the affixation-function instead. Hopefully, this makes
sense.
But perhaps handling this "path-tree" in xref-backend-definitions would
not hurt after all. I can spin this up if you think this is better
moving forward.
Some other questions follow:
1. I was thinking about adding a buffer-local function for the
identifier-at-point instead of hard-coding (thing-at-point 'symbol)
to let major-modes like org-mode and auctex-mode behave more=20
smartly. WDYT?
2. When implementing the apropos method for the backend, should we
let pattern match against the whole "path-tree" or just the last
part of it?
bug-gnu-emacs@HIDDEN:bug#28407; Package emacs.
Full text available.Received: (at 28407) by debbugs.gnu.org; 29 May 2022 22:13:27 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 29 18:13:27 2022 Received: from localhost ([127.0.0.1]:42137 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nvRA7-0001ou-FX for submit <at> debbugs.gnu.org; Sun, 29 May 2022 18:13:27 -0400 Received: from mail-wr1-f48.google.com ([209.85.221.48]:45806) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1nvRA6-0001oi-FT for 28407 <at> debbugs.gnu.org; Sun, 29 May 2022 18:13:26 -0400 Received: by mail-wr1-f48.google.com with SMTP id p10so12347343wrg.12 for <28407 <at> debbugs.gnu.org>; Sun, 29 May 2022 15:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=8f+zGc9Q9Ix8XvDz2VXdVC8c6aw6/2eC1CsqBpjWBfA=; b=P9UorENZDrLTneB8PIBVF242FmsE4IIw2lBIHJmey4S6aLhPniUsqlKSE4qF0qmrxC PZVHI3gcQBY4MSFfUUyhse5XruGRTgzPE/fvlDrhHIdwSvMrg+GqiynlUoJ3/cS+4iQp /xlk9xmgFDHVkLbDNHSEr9lRhvMU70xTySw9CeHPGeZih3Mi99IfZ3yuUbZuktbEU400 MBxTBb5t+WBLlWFngQ21fFc6xQObdBB5yL4fhGLkbEASlLA7r3ZFS9mT/4s3R1L9CWgj 37ZcBUUkqbGH9EAxdH2rf2hsBsuRMTpw0j+e0cMU9636YsHZ1v5JJLFEA+6u93OvJTWn EKUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=8f+zGc9Q9Ix8XvDz2VXdVC8c6aw6/2eC1CsqBpjWBfA=; b=qLFfkRrPi12ZgoAeRG5X0SqD6xXBZzlvGPphZRNZKPN+BUCBM4sKDtHYHc/r2aWXVM 489JK4rtkxUggroYPGhX57Iz4zg4SOza7N3YhszOu8+bTbQry0iAq8qJ2arufAhuS4b5 +NMkgHqF3x7FV6l4gjLEGYVHam0vivEFXdPtyD7lyz/xuefKQ8wXBWeJgJch8KjMnQup ftWNKlwQCGbj0ejCgmZhr0yfD2pTSuoG5LCwF9uoSikEz0OUeCxsD1PhcO9nLKGwqh66 D/L7/CGDPB9JoiuiUE+d57fmkogwxlc9ch6G+HuwS8HSJ/6B3FGFWPq7Z7zSQeS8N9Cq 1ZEw== X-Gm-Message-State: AOAM531YUwtwFXoHutr3tPHCTzl8LsMEx6fe8jUGYij0suhvs6vemH5q 0xNI4Ws7Axu/PYP1ipO6lN8= X-Google-Smtp-Source: ABdhPJxPASV8MStyyN6L+dgzb4/AqtuMY1s2kzUhz5GTgcelJETvq6S1DZMltPRIhud3QQ5V4jnUgw== X-Received: by 2002:a05:6000:1ac8:b0:20f:d4e7:b814 with SMTP id i8-20020a0560001ac800b0020fd4e7b814mr30711845wry.678.1653862400521; Sun, 29 May 2022 15:13:20 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id f7-20020a1c3807000000b003942a244f53sm8335814wma.44.2022.05.29.15.13.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 29 May 2022 15:13:20 -0700 (PDT) Message-ID: <2a6aec56-4f72-5064-c001-e7aa46144f9d@HIDDEN> Date: Mon, 30 May 2022 01:13:18 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: bug#28407: 26.0.50; xref should use imenu Content-Language: en-US To: Visuwesh <visuweshm@HIDDEN> References: <87h8wa8quw.fsf@bapiya> <3238a206-240a-aa76-87c0-bcb3bdfa00dc@HIDDEN> <87y1z35630.fsf@HIDDEN> <87zgjic68h.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <87zgjic68h.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 28407 Cc: Tom Tromey <tom@HIDDEN>, 28407 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.5 (/) Hi Visuwesh, On 16.05.2022 09:59, Visuwesh wrote: > [ஞாயிறு மே 15, 2022] Visuwesh wrote: > >> [திங்கள் செப்டம்பர் 11, 2017] Dmitry Gutov wrote: >> >>> On 9/10/17 7:23 PM, Tom Tromey wrote: >>>> It would be nice if imenu were a back end for xref. >>>> Then M-. could also use symbols found by imenu. >>>> A further wrinkle on this would be if xref, project, and imenu >>>> worked >>>> together, so that M-. would automatically know to look at imenu results >>>> for other buffers in the same project. >>> >>> Agreed. It could be a nice default for when no tags table is currently >>> visited. >> >> I tried to write a general imenu backend in attached file (extracted >> from my init.el) but I hit quite a few roadblocks, >> >> 1. I activate the imenu backend iff there are no tags table defined >> for the buffer but this means that one cannot use the imenu >> backend to jump to definitions for symbols that TAGS do not know >> of currently. I can think of two ways to solve this problem, >> >> (a) Check if the symbol is in TAGS table. >> (b) Modify the etags backend so that the user can say "I have no >> TAGS table for this file/project/whatever." >> >> (a) is definitely not clean, and (b) sounds feasible but similar >> situation can also exist with other backends (like elisp). >> >> I'm lost on how to solve this problem. >> >> 2. I have not defined all the methods and the completion-table does >> not handle the nested case of the index alist. AFAIU from `(elisp) >> Programmed Completion', completion "ends" when `try-completion' >> returns t but I seem to be mistaken. I have to rewrite >> completion-table to be like `imenu--completion-buffer' but I don't >> know how to pull that off. >> >> 3. `imenu-xref--in-alist' is mostly a 1-1 copy of `imenu--in-alist' >> with the only difference being my function returns all matches of >> the symbol instead of just the first one. This should be easy >> enough to fix by adding an optional argument INCLUDE-ALL to >> `imenu--in-alist'. >> >> I'm testing in python-mode with the following settings, >> >> (setq imenu-name-lookup-function (lambda (symbol item) (string-prefix-p symbol item)) >> python-imenu-format-parent-item-jump-label-function (lambda (_ name) name)) > > I solved (2) by using an affixation function. I did (3) as well, and > I'm attaching my work as a patch against imenu.el. (1) sounds reasonable because the reference might easily be in another file. If you wanted to add extra customizations (for the user to be able to indicated things like "use imenu for xref in these files"), maybe add it to this backend's options. As long as it comes before etags in xref-backend-functions, it should have all the power. Another possible direction for its development would be to always try to combine the locations coming from both etags and imenu (in the current file). I would leave that to a later revision, though. Some testing for performance regressions in large projects would be nice too. (2) Could you try to explain the problem that you were solving here? affixation-function is normally about how the completions look (I think). Would 'completion-table-with-predicate' help? Or maybe you just need to pre-process the nested structure into a "flat" completion table first.
bug-gnu-emacs@HIDDEN:bug#28407; Package emacs.
Full text available.
Received: (at 28407) by debbugs.gnu.org; 16 May 2022 07:00:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 16 03:00:37 2022
Received: from localhost ([127.0.0.1]:51521 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1nqUia-0007A5-IE
for submit <at> debbugs.gnu.org; Mon, 16 May 2022 03:00:36 -0400
Received: from mail-pj1-f68.google.com ([209.85.216.68]:38428)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <visuweshm@HIDDEN>) id 1nqUiY-00079m-9V
for 28407 <at> debbugs.gnu.org; Mon, 16 May 2022 03:00:34 -0400
Received: by mail-pj1-f68.google.com with SMTP id
o13-20020a17090a9f8d00b001df3fc52ea7so2589584pjp.3
for <28407 <at> debbugs.gnu.org>; Mon, 16 May 2022 00:00:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=from:to:cc:subject:references:date:in-reply-to:message-id
:user-agent:mime-version;
bh=PA8gUUXaHjJ9Hw3bhPOtVi3/LL3wEkIjYiz1x+TYNyc=;
b=CjZIEAxu+3wskmq+XkNJ/MwEm8qN6l3BusYu255XsHtFCzrzLOcxArgeZEWdJZOL7i
1+G6SvzxfZ2DUycDe3uD+2ZdRaFCb2BvaUic28GZLmzMzxw/VR3P7As4CSzG0qK9aa75
uFGwj9TMLAuvxzKHOmKeYbRuiBxGWMh/2anjBS1SNidfW+Yq4icZOovjasoqD5grINva
kPaTo60MUmbJwllmYusZPejsTnNZkKSGTHasvCgflCPgbWJxumTPwBMvDJJUCzkgIKPe
+kMaDNwOVUS0u22xhhy4MS6BRMfn19KbtMN9bD+oovvqluoCouP549AOlnQIlCt2Ajwq
p+SQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
:message-id:user-agent:mime-version;
bh=PA8gUUXaHjJ9Hw3bhPOtVi3/LL3wEkIjYiz1x+TYNyc=;
b=N5q6UCTZl0m6URY3YjK0mvSYWd2oc5pWEksxFsVv8s0WR5/f78OAARIZUv/ViIyfk+
Ts+JDfiXVQYWq+tSq90QOgPib3xzx21vJvmZpefnA5AHQl4/b2uszhbQP0chgh0eS77G
7LCEoKlCtU0ZhXoNq17KE0FJCxjybT+5T7vuDy02Qq65pUIHKS67bcUNzmgo49c0KaRK
t039P0u7Yh2CP+XaI+FvESsf0FB0F/Yg9j7fU3Z3ZD1dmgjEdZrWdpyeqkzYHLbUegZT
fN2YHbjzbfwS8FRVeh2WpycSEbMbKMqDvQ/HzLzE2uagVfHO9zEMtR0lBtdgFMUQLeWF
NbCg==
X-Gm-Message-State: AOAM530YmETZqogtPfsJMfeLIeiBlYufkRSmsZ13/SAWVshplgXrkrGq
TGCZ6EzjzxXYJkyhKXX2Sjs=
X-Google-Smtp-Source: ABdhPJyS3+bJXlDaTuAvWLBsBdSrBQDctPJV0vwVarfK81Cg5yXFdlXyB/lv9ReCwP7/ror1Q8cOxQ==
X-Received: by 2002:a17:903:124a:b0:154:c7a4:9374 with SMTP id
u10-20020a170903124a00b00154c7a49374mr16178227plh.68.1652684428154;
Mon, 16 May 2022 00:00:28 -0700 (PDT)
Received: from localhost ([49.205.85.27]) by smtp.gmail.com with ESMTPSA id
cs14-20020a17090af50e00b001d75aabe050sm5735441pjb.34.2022.05.16.00.00.26
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 16 May 2022 00:00:27 -0700 (PDT)
From: Visuwesh <visuweshm@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#28407: 26.0.50; xref should use imenu
References: <87h8wa8quw.fsf@bapiya>
<3238a206-240a-aa76-87c0-bcb3bdfa00dc@HIDDEN>
<87y1z35630.fsf@HIDDEN>
Date: Mon, 16 May 2022 12:29:58 +0530
In-Reply-To: <87y1z35630.fsf@HIDDEN> (Visuwesh's message of "Sun, 15 May
2022 18:02:14 +0530")
Message-ID: <87zgjic68h.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 28407
Cc: Tom Tromey <tom@HIDDEN>, 28407 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
[=E0=AE=9E=E0=AE=BE=E0=AE=AF=E0=AE=BF=E0=AE=B1=E0=AF=81 =E0=AE=AE=E0=AF=87 =
15, 2022] Visuwesh wrote:
> [=E0=AE=A4=E0=AE=BF=E0=AE=99=E0=AF=8D=E0=AE=95=E0=AE=B3=E0=AF=8D =E0=AE=
=9A=E0=AF=86=E0=AE=AA=E0=AF=8D=E0=AE=9F=E0=AE=AE=E0=AF=8D=E0=AE=AA=E0=AE=B0=
=E0=AF=8D 11, 2017] Dmitry Gutov wrote:
>
>> On 9/10/17 7:23 PM, Tom Tromey wrote:
>>> It would be nice if imenu were a back end for xref.
>>> Then M-. could also use symbols found by imenu.
>>> A further wrinkle on this would be if xref, project, and imenu
>>> worked
>>> together, so that M-. would automatically know to look at imenu results
>>> for other buffers in the same project.
>>
>> Agreed. It could be a nice default for when no tags table is currently
>> visited.
>
> I tried to write a general imenu backend in attached file (extracted
> from my init.el) but I hit quite a few roadblocks,
>
> 1. I activate the imenu backend iff there are no tags table defined
> for the buffer but this means that one cannot use the imenu
> backend to jump to definitions for symbols that TAGS do not know
> of currently. I can think of two ways to solve this problem,
>
> (a) Check if the symbol is in TAGS table.
> (b) Modify the etags backend so that the user can say "I have no
> TAGS table for this file/project/whatever."
>
> (a) is definitely not clean, and (b) sounds feasible but similar
> situation can also exist with other backends (like elisp).
>
> I'm lost on how to solve this problem.
>
> 2. I have not defined all the methods and the completion-table does
> not handle the nested case of the index alist. AFAIU from `(elisp)
> Programmed Completion', completion "ends" when `try-completion'
> returns t but I seem to be mistaken. I have to rewrite
> completion-table to be like `imenu--completion-buffer' but I don't
> know how to pull that off.
>
> 3. `imenu-xref--in-alist' is mostly a 1-1 copy of `imenu--in-alist'
> with the only difference being my function returns all matches of
> the symbol instead of just the first one. This should be easy
> enough to fix by adding an optional argument INCLUDE-ALL to
> `imenu--in-alist'.
>
> I'm testing in python-mode with the following settings,
>
> (setq imenu-name-lookup-function (lambda (symbol item) (string-prefix=
-p symbol item))
> python-imenu-format-parent-item-jump-label-function (lambda (_ =
name) name))
I solved (2) by using an affixation function. I did (3) as well, and
I'm attaching my work as a patch against imenu.el.
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment; filename=imenu-xref.patch
diff --git a/lisp/imenu.el b/lisp/imenu.el
index 2636e77d08..69338d216a 100644
--- a/lisp/imenu.el
+++ b/lisp/imenu.el
@@ -52,6 +52,7 @@
;;; Code:
(require 'cl-lib)
+(require 'xref)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;
@@ -473,8 +474,10 @@ imenu--create-keymap
(if cmd (funcall cmd item) item))))))
alist)))
-(defun imenu--in-alist (str alist)
- "Check whether the string STR is contained in multi-level ALIST."
+(defun imenu--in-alist (str alist &optional all)
+ "Check whether the string STR is contained in multi-level ALIST.
+If the optional argument ALL is non-nil, then return all matches
+of STR in ALIST."
(let (elt head tail res)
(setq res nil)
(while alist
@@ -491,12 +494,18 @@ imenu--in-alist
;; We are only interested in the bottom-level elements, so we need to
;; recurse if TAIL is a nested ALIST.
(cond ((imenu--subalist-p elt)
- (if (setq res (imenu--in-alist str tail))
- (setq alist nil)))
+ (let ((r (imenu--in-alist str tail all)))
+ (if all
+ (setq res (append res (if (listp (cdr r)) r (list r))))
+ (setq res r)
+ (when r
+ (setq alist nil)))))
((if imenu-name-lookup-function
(funcall imenu-name-lookup-function str head)
(string= str head))
- (setq alist nil res elt))))
+ (if all
+ (push elt res)
+ (setq alist nil res elt)))))
res))
;;;###autoload
@@ -550,6 +559,61 @@ imenu-default-create-index-function
(t
(imenu-unavailable-error "This buffer cannot use `imenu-default-create-index-function'"))))
+;;;
+;;; Xref backend
+;;;
+
+;;;###autoload
+(defun imenu-xref-backend ()
+ (unless imenu--index-alist
+ (imenu--make-index-alist))
+ (when (and imenu--index-alist
+ (not (progn (require 'etags) tags-table-files)))
+ 'imenu))
+
+(cl-defmethod xref-backend-identifier-at-point ((_backend (eql 'imenu)))
+ (thing-at-point 'symbol))
+
+(defun imenu-xref--make-summary (marker)
+ (with-current-buffer (marker-buffer marker)
+ (save-excursion
+ (goto-char marker)
+ (back-to-indentation)
+ (buffer-substring (point) (point-at-eol)))))
+
+(cl-defmethod xref-backend-definitions ((_backend (eql 'imenu)) symbol)
+ (let ((res (imenu--in-alist symbol imenu--index-alist t))
+ defs)
+ (dolist (item res)
+ (push (xref-make (imenu-xref--make-summary (cdr item))
+ (xref-make-buffer-location (marker-buffer (cdr item))
+ (marker-position (cdr item))))
+ defs))
+ defs))
+
+(cl-defmethod xref-backend-identifier-completion-ignore-case ((_backend (eql 'imenu)))
+ imenu-case-fold-search)
+
+(defun imenu-xref--make-affixations (alist &optional prefix)
+ (let (res)
+ (dolist (item alist)
+ (if (imenu--subalist-p item)
+ (setq res (append res (imenu-xref--make-affixations
+ (cdr item)
+ (concat prefix (when prefix imenu-level-separator) (car item)))))
+ (push (list (car item) (concat prefix (when prefix imenu-level-separator)) "") res)))
+ res))
+
+(cl-defmethod xref-backend-identifier-completion-table ((_backend (eql 'imenu)))
+ (let ((affixations (imenu-xref--make-affixations imenu--index-alist)))
+ (lambda (string pred action)
+ (if (eq action 'metadata)
+ `(metadata (affixation-function
+ . ,(lambda (cmp) (mapcar (lambda (c) (assoc c affixations #'equal)) cmp))))
+ ;; This works since (car AFFIXATIONS) is the completion
+ ;; candidate.
+ (complete-with-action action affixations string pred)))))
+
;;;
;;; Generic index gathering function.
;;;
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#28407; Package emacs.
Full text available.
Received: (at 28407) by debbugs.gnu.org; 15 May 2022 12:33:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 15 08:33:15 2022
Received: from localhost ([127.0.0.1]:48741 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1nqDQx-0000zO-DD
for submit <at> debbugs.gnu.org; Sun, 15 May 2022 08:33:15 -0400
Received: from mail-pl1-f193.google.com ([209.85.214.193]:44955)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <visuweshm@HIDDEN>) id 1nqDQv-0000z9-QO
for 28407 <at> debbugs.gnu.org; Sun, 15 May 2022 08:33:14 -0400
Received: by mail-pl1-f193.google.com with SMTP id q4so11989570plr.11
for <28407 <at> debbugs.gnu.org>; Sun, 15 May 2022 05:33:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=from:to:cc:subject:in-reply-to:date:lines:references:user-agent
:message-id:mime-version;
bh=o4GMPC0dWDpVKCE2Ociv5/k7qrTiknbafxgnkzx4fws=;
b=KFP6oweDM3MZra6RX2vktLX7dicJ/pp5p1DiUhK7sKteQEa57yHTjvFl8VL0EBwICW
Ouha4wEiO4pBr27rrbaU5Nhc2XwC4BgD5rDPneAowAikrUMZNMN+J8VtSyFsP/eqpnyW
wnQU6OPJb6d0CRPwyAE/wKdMo5rJkyZEaiOYoo+QBYjsR3HLjCSV1T/rel0GR4hr2tTX
zXp4B/mkzpspETKxaoUBB+Yf4PjEaQdPd6rtmZmB3vXUrCGgWR56iUKLjnm5rpDHHUVl
M7DQa3JyRhHjyz/XBFGglTKK324eZPJJ6Eih870d6iBkcDaQ/mLmCdc7RjVowhYiCtfp
kQTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:from:to:cc:subject:in-reply-to:date:lines
:references:user-agent:message-id:mime-version;
bh=o4GMPC0dWDpVKCE2Ociv5/k7qrTiknbafxgnkzx4fws=;
b=0yQw4uft7fG5GDZ8GVeUBtFKWMBpa3UDlOQCns0NU2EaNFI4ZSLSfb6zMhJ3mOYBdj
eC8an4docfl5epyFpV/ZZRCpm489uUHKT9K7y4yOA3f1nB2O4ghWzDo99aw9MLSDVapw
cfhympIR4OfkNLPEmjYHzou0CXs0Lp5BF4ZNOGD/j+mGtxx1yWKZVw+lgoHSS3igSp3o
R3kVk9o//N6PDZKL9ZXvoiIs1nsj7cwk9QlV2km6O4MKGujIxbbxqX98Jsaf3bfdfJzV
PjrFq0Y2ZvpLIZ2yDPU7fr6xln5LAXvPPOLJsB+B9OiWJrKcgDaC8GArH/Sb9oajgDVw
DLOg==
X-Gm-Message-State: AOAM532u5ftO0ZwbabkhHpw42YPt84n6x7fXugC8ezCpxigA8lmIMcRD
gZRK21a6URqUar4nKO5P5R4=
X-Google-Smtp-Source: ABdhPJwp6X3Yd8F3ghmq1duSji5/PKZ5SnH/MK241kJSXytvh3p0vLThqW22BcNzHxKn1UGnSU9+Aw==
X-Received: by 2002:a17:90a:2809:b0:1df:35ca:2e6a with SMTP id
e9-20020a17090a280900b001df35ca2e6amr3624933pjd.8.1652617987725;
Sun, 15 May 2022 05:33:07 -0700 (PDT)
Received: from localhost ([49.204.115.240]) by smtp.gmail.com with ESMTPSA id
d17-20020aa78691000000b0050dc76281c6sm5040310pfo.160.2022.05.15.05.33.06
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sun, 15 May 2022 05:33:07 -0700 (PDT)
From: Visuwesh <visuweshm@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#28407: 26.0.50; xref should use imenu
In-Reply-To: <3238a206-240a-aa76-87c0-bcb3bdfa00dc@HIDDEN> (Dmitry Gutov's
message of "Mon, 11 Sep 2017 00:35:56 +0300")
Date: Sun, 15 May 2022 18:02:14 +0530
Lines: 151
References: <87h8wa8quw.fsf@bapiya>
<3238a206-240a-aa76-87c0-bcb3bdfa00dc@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
Message-ID: <87y1z35630.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 28407
Cc: Tom Tromey <tom@HIDDEN>, 28407 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
[=E0=AE=A4=E0=AE=BF=E0=AE=99=E0=AF=8D=E0=AE=95=E0=AE=B3=E0=AF=8D =E0=AE=9A=
=E0=AF=86=E0=AE=AA=E0=AF=8D=E0=AE=9F=E0=AE=AE=E0=AF=8D=E0=AE=AA=E0=AE=B0=E0=
=AF=8D 11, 2017] Dmitry Gutov wrote:
> On 9/10/17 7:23 PM, Tom Tromey wrote:
>> It would be nice if imenu were a back end for xref.
>> Then M-. could also use symbols found by imenu.
>> A further wrinkle on this would be if xref, project, and imenu
>> worked
>> together, so that M-. would automatically know to look at imenu results
>> for other buffers in the same project.
>
> Agreed. It could be a nice default for when no tags table is currently
> visited.
I tried to write a general imenu backend in attached file (extracted
from my init.el) but I hit quite a few roadblocks,
1. I activate the imenu backend iff there are no tags table defined
for the buffer but this means that one cannot use the imenu
backend to jump to definitions for symbols that TAGS do not know
of currently. I can think of two ways to solve this problem,
(a) Check if the symbol is in TAGS table.
(b) Modify the etags backend so that the user can say "I have no
TAGS table for this file/project/whatever."
(a) is definitely not clean, and (b) sounds feasible but similar
situation can also exist with other backends (like elisp).
I'm lost on how to solve this problem.
2. I have not defined all the methods and the completion-table does
not handle the nested case of the index alist. AFAIU from `(elisp)
Programmed Completion', completion "ends" when `try-completion'
returns t but I seem to be mistaken. I have to rewrite
completion-table to be like `imenu--completion-buffer' but I don't
know how to pull that off.
3. `imenu-xref--in-alist' is mostly a 1-1 copy of `imenu--in-alist'
with the only difference being my function returns all matches of
the symbol instead of just the first one. This should be easy
enough to fix by adding an optional argument INCLUDE-ALL to
`imenu--in-alist'.
I'm testing in python-mode with the following settings,
(setq imenu-name-lookup-function (lambda (symbol item) (string-prefix-p=
symbol item))
python-imenu-format-parent-item-jump-label-function (lambda (_ na=
me) name))
--=-=-=
Content-Type: application/emacs-lisp
Content-Disposition: attachment; filename=imenu-xref.el
Content-Transfer-Encoding: quoted-printable
(defun imenu-xref-backend ()
(when (not tags-table-files)
'imenu))
(cl-defmethod xref-backend-identifier-at-point ((_backend (eql 'imenu)))
(or (thing-at-point 'symbol)
(find-tag--default)))
(defun imenu-xref--in-alist (symbol alist)
"Find all positions that match SYMBOL in the imenu index ALIST."
(let (elt head tail res)
(while alist
(setq elt (car alist)
tail (cdr elt)
alist (cdr alist)
head (car elt))
;; A nested ALIST element looks like
;; (INDEX-NAME (INDEX-NAME . INDEX-POSITION) ...)
;; while a bottom-level element looks like
;; (INDEX-NAME . INDEX-POSITION)
;; or
;; (INDEX-NAME INDEX-POSITION FUNCTION ARGUMENTS...)
;; We are only interested in the bottom-level elements, so we need to
;; recurse if TAIL is a nested ALIST.
(cond ((imenu--subalist-p elt)
(when-let ((item (imenu-xref--in-alist symbol tail)))
(if (listp item)
(setq res (append res item))
(push item res))))
((if imenu-name-lookup-function
(funcall imenu-name-lookup-function symbol head)
(equal symbol head))
(push elt res))))
res))
(defun imenu-xref--make-summary (sym marker)
(with-current-buffer (marker-buffer marker)
(save-excursion
(goto-char marker)
(back-to-indentation)
(buffer-substring (point) (point-at-eol)))))
(cl-defmethod xref-backend-definitions ((_backend (eql 'imenu)) symbol)
(unless imenu--index-alist
(imenu--make-index-alist))
(let ((res (imenu-xref--in-alist symbol imenu--index-alist))
defs)
(pcase-dolist (`(,sym . ,m) res)
(push (xref-make (imenu-xref--make-summary sym m)
(xref-make-buffer-location (marker-buffer m) (marker=
-position m)))
defs))
defs))
(cl-defmethod xref-backend-identifier-completion-ignore-case ((_backend (eq=
l 'imenu)))
completion-ignore-case)
(defun imenu-xref--flatten (alist &optional prefix)
(let (res)
(dolist (item alist)
(if (imenu--subalist-p (cdr item))
(setq res (append res (imenu-xref--flatten
(cdr item)
(concat prefix (when prefix imenu-level-se=
parator) (car item)))))
(push (cons (concat prefix (when prefix imenu-level-separator) (car=
item))
(cdr item))
res)))
res))
(cl-defmethod xref-backend-identifier-completion-table ((_backend (eql 'ime=
nu)))
(unless imenu--index-alist
(imenu--make-index-alist))
(let ((collection (imenu-xref--flatten imenu--index-alist)))
(lambda (string pred action)
(cond
((null action)
(if-let* ((completion (try-completion string collection pred))
((eq t completion)))
(string-trim-left string ".+:")
completion))
(t (complete-with-action action collection string pred))))))
(add-hook 'xref-backend-functions #'imenu-xref-backend)
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#28407; Package emacs.
Full text available.
Received: (at 28407) by debbugs.gnu.org; 10 Sep 2017 21:36:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 10 17:36:05 2017
Received: from localhost ([127.0.0.1]:59844 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1dr9td-00027t-7j
for submit <at> debbugs.gnu.org; Sun, 10 Sep 2017 17:36:05 -0400
Received: from mail-lf0-f41.google.com ([209.85.215.41]:33099)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <raaahh@HIDDEN>) id 1dr9tb-00027K-Vo
for 28407 <at> debbugs.gnu.org; Sun, 10 Sep 2017 17:36:04 -0400
Received: by mail-lf0-f41.google.com with SMTP id c80so14430422lfh.0
for <28407 <at> debbugs.gnu.org>; Sun, 10 Sep 2017 14:36:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=sender:subject:to:references:from:message-id:date:user-agent
:mime-version:in-reply-to:content-language:content-transfer-encoding;
bh=m0CtbaMX8F3ETYBX9VyfKSE0d5Y4pDHtNZa2hesDRwc=;
b=HWvRBAkTmuXrr85JMZKcZy2tFAMPrRXszlaFQhFiG9gXQF2+EABq357rEdX5fMdcQZ
oiUyziUPcnsWXziPPGEEuMEvQHNVy/z8nLg80ZIMkvDqIbl9ZQWFG4oP0p2ybIEehVsJ
q51H8cS+s3CLfEIWKSREfUXhCV18FAKUdHI6bDnu4jmynm41DVWLn0c2EFW9RtglWgmg
LaNPHq8fMqFMwV3LpWOYt/T1VK2l1qVyCYSR/wzzW/mojHFqZ2MzZTRL3cRDPFS4MVNf
eidEN8W4mxbjNZmMYRIt6hexMCfJMjqC1xRMjvUiMuOAW2v9pB+LvKFQmQAT15htuR37
J+hA==
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:references:from:message-id
:date:user-agent:mime-version:in-reply-to:content-language
:content-transfer-encoding;
bh=m0CtbaMX8F3ETYBX9VyfKSE0d5Y4pDHtNZa2hesDRwc=;
b=d8DHAnK0/kE/6QAcia+5Vszr81GuvO2wv2hBUVJni04HCn4WSn8GHI3uPT+m5Aw9ta
v8j9yUFdpiU+2wTwZKcd37F+A+BrmRQ5ZvAkgqquG71W7vNd65OPL3UYFphlmy2+mhPV
cvqExG4OqB2Jd8nTmIHOq/fsxhJfwb9expk/DiYTDXKFJAD9FIJUr0zOOmbsNJRffZhI
MAuD4skobfmzjG21UOItVHA3opue5ub7COGl8bcKcXco8nSGnqJDdYc2ZrW9U+05ab54
5C1s5HhWxsIp3hkSwcXTnP8etsQa9sVpDNR30JqiXYU/jVCQis93n//Cd24HhHJZ1/Fp
9Dow==
X-Gm-Message-State: AHPjjUh/pNjszmTnjmXQSinbR1xm4dOm+qNw2wG29dKlh6rr5HNKLse7
PCLwJv6WpD5SEwdlS7E=
X-Google-Smtp-Source: ADKCNb7/HdmXB8mb5xtEKGR0Mxp9Sb/CLjn5UGW53ommMrwhjX5e1Ki2r+6cwSDn+7qLHBeaeaLlJg==
X-Received: by 10.46.2.14 with SMTP id 14mr3560394ljc.0.1505079358026;
Sun, 10 Sep 2017 14:35:58 -0700 (PDT)
Received: from [192.168.1.174] ([178.252.127.239])
by smtp.googlemail.com with ESMTPSA id c73sm1181854lfg.89.2017.09.10.14.35.57
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 10 Sep 2017 14:35:57 -0700 (PDT)
Subject: Re: bug#28407: 26.0.50; xref should use imenu
To: Tom Tromey <tom@HIDDEN>, 28407 <at> debbugs.gnu.org
References: <87h8wa8quw.fsf@bapiya>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <3238a206-240a-aa76-87c0-bcb3bdfa00dc@HIDDEN>
Date: Mon, 11 Sep 2017 00:35:56 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101
Thunderbird/56.0
MIME-Version: 1.0
In-Reply-To: <87h8wa8quw.fsf@bapiya>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.2 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: On 9/10/17 7:23 PM, Tom Tromey wrote: > > It would be nice
if imenu were a back end for xref. > Then M-. could also use symbols found
by imenu. > > A further wrinkle on this would be if xref, project, and imenu
worked > together, so that M-. would automatically know to look at imenu
results > for other buffers in the same project. [...]
Content analysis details: (2.2 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server
[178.252.127.239 listed in dnsbl.sorbs.net]
0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source
[209.85.215.41 listed in dnsbl.sorbs.net]
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no
trust [209.85.215.41 listed in list.dnswl.org]
0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail
domains are different
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(dgutov[at]yandex.ru)
-0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
[209.85.215.41 listed in wl.mailspike.net]
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom
freemail headers are different
-0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
X-Debbugs-Envelope-To: 28407
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.2 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: On 9/10/17 7:23 PM, Tom Tromey wrote: > > It would be nice
if imenu were a back end for xref. > Then M-. could also use symbols found
by imenu. > > A further wrinkle on this would be if xref, project, and imenu
worked > together, so that M-. would automatically know to look at imenu
results > for other buffers in the same project. [...]
Content analysis details: (2.2 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server
[178.252.127.239 listed in dnsbl.sorbs.net]
0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source
[209.85.215.41 listed in dnsbl.sorbs.net]
-0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
[209.85.215.41 listed in wl.mailspike.net]
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no
trust
[209.85.215.41 listed in list.dnswl.org]
0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail
domains are different
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(dgutov[at]yandex.ru)
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom
freemail headers are different
-0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
On 9/10/17 7:23 PM, Tom Tromey wrote:
>
> It would be nice if imenu were a back end for xref.
> Then M-. could also use symbols found by imenu.
>
> A further wrinkle on this would be if xref, project, and imenu worked
> together, so that M-. would automatically know to look at imenu results
> for other buffers in the same project.
Agreed. It could be a nice default for when no tags table is currently
visited.
bug-gnu-emacs@HIDDEN:bug#28407; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 10 Sep 2017 16:24:09 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 10 12:24:09 2017 Received: from localhost ([127.0.0.1]:59552 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1dr51l-0003HV-1z for submit <at> debbugs.gnu.org; Sun, 10 Sep 2017 12:24:09 -0400 Received: from eggs.gnu.org ([208.118.235.92]:50663) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <tom@HIDDEN>) id 1dr51j-0003Gz-9m for submit <at> debbugs.gnu.org; Sun, 10 Sep 2017 12:24:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <tom@HIDDEN>) id 1dr51a-0004Bp-8L for submit <at> debbugs.gnu.org; Sun, 10 Sep 2017 12:24:02 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:56163) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <tom@HIDDEN>) id 1dr51a-0004Bj-4z for submit <at> debbugs.gnu.org; Sun, 10 Sep 2017 12:23:58 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41565) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <tom@HIDDEN>) id 1dr51Y-0007KO-9N for bug-gnu-emacs@HIDDEN; Sun, 10 Sep 2017 12:23:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <tom@HIDDEN>) id 1dr51Q-00046K-NO for bug-gnu-emacs@HIDDEN; Sun, 10 Sep 2017 12:23:52 -0400 Received: from gproxy10-pub.mail.unifiedlayer.com ([69.89.20.226]:41935) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <tom@HIDDEN>) id 1dr51Q-00044N-7k for bug-gnu-emacs@HIDDEN; Sun, 10 Sep 2017 12:23:48 -0400 Received: from cmgw2 (unknown [10.0.90.83]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id 3DD2B141007 for <bug-gnu-emacs@HIDDEN>; Sun, 10 Sep 2017 10:23:45 -0600 (MDT) Received: from box522.bluehost.com ([74.220.219.122]) by cmgw2 with id 7sPe1w01i2f2jeq01sPh4f; Sun, 10 Sep 2017 10:23:45 -0600 X-Authority-Analysis: v=2.2 cv=dZfw5Tfe c=1 sm=1 tr=0 a=GsOEXm/OWkKvwdLVJsfwcA==:117 a=GsOEXm/OWkKvwdLVJsfwcA==:17 a=2JCJgTwv5E4A:10 a=cetfRAdre1X6KpoU0voA:9 a=OeaKoLnGlz1oxMzE:21 a=LvRqEr-l-nQWnhci:21 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From: Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=lzBSDn2KBluPNB5/aDR4G879lSkFcKAZ1jSmsiYNOUY=; b=PHzE2IC7wEffRZ+AcRC6Rcp24R 5gLFhbeCi5j71qHuXY4sHrwmyN0xKtRsGghWAMFQ8CahXwKpRJD8kKFqv1dR3ys2GfbP0uDuSm3W6 FylpHHjJv6PoCWypwJ3AfDuor; Received: from 75-166-76-94.hlrn.qwest.net ([75.166.76.94]:45660 helo=bapiya) by box522.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from <tom@HIDDEN>) id 1dr51G-003GEy-C5; Sun, 10 Sep 2017 10:23:38 -0600 From: Tom Tromey <tom@HIDDEN> To: bug-gnu-emacs@HIDDEN Subject: 26.0.50; xref should use imenu X-Attribution: Tom Date: Sun, 10 Sep 2017 10:23:35 -0600 Message-ID: <87h8wa8quw.fsf@bapiya> MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box522.bluehost.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 75.166.76.94 X-Exim-ID: 1dr51G-003GEy-C5 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 75-166-76-94.hlrn.qwest.net (bapiya) [75.166.76.94]:45660 X-Source-Auth: tom+tromey.com X-Email-Count: 1 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTIyLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.5 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -4.5 (----) It would be nice if imenu were a back end for xref. Then M-. could also use symbols found by imenu. A further wrinkle on this would be if xref, project, and imenu worked together, so that M-. would automatically know to look at imenu results for other buffers in the same project. Tom In GNU Emacs 26.0.50 (build 18, x86_64-pc-linux-gnu, GTK+ Version 3.22.17) of 2017-09-09 built on bapiya Repository revision: 4131f9785e30f2a31745125c714e922892113c62 Windowing system distributor 'Fedora Project', version 11.0.11903000 System Description: Fedora release 25 (Twenty Five) Recent messages: Hunk already applied [3 times] Mark saved where search started user-error: No definitions found for: funlike_invocation_p Quit M-. runs the command xref-find-definitions Type "q" in help window to restore its previous buffer. uncompressing xref.el.gz...done Mark saved where search started uncompressing imenu.el.gz...done Mark saved where search started [2 times] Configured using: 'configure --prefix=/home/tromey/Emacs/install' Configured features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 Important settings: value of $LANG: en_US.utf8 value of $XMODIFIERS: @im=ibus locale-coding-system: utf-8-unix Major mode: Emacs-Lisp Minor modes in effect: shell-dirtrack-mode: t diff-auto-refine-mode: t flyspell-mode: t which-function-mode: t erc-services-mode: t erc-list-mode: t erc-menu-mode: t erc-autojoin-mode: t erc-ring-mode: t erc-networks-mode: t erc-pcomplete-mode: t erc-track-mode: t erc-match-mode: t erc-netsplit-mode: t erc-hl-nicks-mode: t erc-button-mode: t erc-fill-mode: t erc-stamp-mode: t erc-irccontrols-mode: t erc-noncommands-mode: t erc-move-to-prompt-mode: t erc-readonly-mode: t savehist-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t auto-fill-function: do-auto-fill transient-mark-mode: t Load-path shadows: /home/tromey/.emacs.d/elpa/bubbles-0.5/bubbles hides /home/tromey/Emacs/install/share/emacs/26.0.50/lisp/play/bubbles Features: (shadow emacsbug make-mode cc-awk texinfo log-edit cl-print debug nndoc gnus-dup debbugs-gnu debbugs soap-client url-http url-auth url-gw rng-xsd rng-dt rng-util xsd-regexp smerge-mode whitespace gnus-html url-queue help-fns radix-tree url-cache mm-url url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf goto-addr log-view pcvs-util term/xterm xterm shell find-file copyright pulse etags xref project vc-mtn vc-hg vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs jka-compr shr-color url-util shr svg xml dom browse-url find-dired add-log misearch multi-isearch bug-reference vc-git diff-mode map cc-mode cc-fonts cc-guess cc-menus cc-cmds dabbrev supercite easy-mmode regi mail-hist nnir flow-fill mm-archive mailalias sort smiley gnus-cite gnus-async gnus-bcklg mail-extr gnus-ml disp-table gnus-topic nndraft nnmh nnfolder utf-7 network-stream nsm starttls gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg nntp gnus-cache gnus-registry registry ebdb-gnus gnus-art mm-uu mml2015 mm-view mml-smime smime dig mailcap gnus-sum gnus-group gnus-undo smtpmail gnus-start gnus-cloud nnimap nnmail mail-source tls gnutls utf7 netrc nnoo parse-time gnus-spec gnus-int gnus-range gnus-win gnus nnheader elec-pair flyspell ispell diminish edmacro kmacro projectile grep compile ibuf-ext ibuffer ibuffer-loaddefs dash appt diary-lib diary-loaddefs which-func imenu minimap autorevert filenotify cus-start cus-load status erc-services erc-list erc-menu erc-join erc-ring erc-networks erc-pcomplete pcomplete erc-track erc-match erc-netsplit erc-hl-nicks color erc-button erc-fill erc-stamp wid-edit erc-goodies erc erc-backend erc-compat thingatpt pp warnings advice vc-dir ewoc vc vc-dispatcher cc-styles cc-align cc-engine cc-vars cc-defs ebdb-complete ebdb-message sendmail message puny dired dired-loaddefs format-spec rfc822 mml mml-sec epa derived epg gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mail-utils gmm-utils mailheader ebdb-mua ebdb-com crm mailabbrev ebdb-format qp ebdb cl-extra help-mode eieio-opt speedbar sb-image ezimage dframe find-func eieio-base pcase subr-x cal-menu calendar cal-loaddefs timezone ange-ftp comint ansi-color ring server savehist finder-inf dwarf-mode-autoloads gdb-shell-autoloads lisppaste-autoloads pydoc-info-autoloads info-look cl weblogger-autoloads info package easymenu epg-config url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote dbusbind inotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 2205844 699201) (symbols 48 58822 76) (miscs 40 16108 11738) (strings 32 597642 63371) (string-bytes 1 15642233) (vectors 16 252143) (vector-slots 8 3921716 191337) (floats 8 4806 1815) (intervals 56 142400 1766) (buffers 992 191))
Tom Tromey <tom@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#28407; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.