From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 29 Dec 2014 20:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 19468@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Reply-To: Eli Zaretskii Received: via spool by submit@debbugs.gnu.org id=B.14198848096819 (code B ref -1); Mon, 29 Dec 2014 20:27:02 +0000 Received: (at submit) by debbugs.gnu.org; 29 Dec 2014 20:26:49 +0000 Received: from localhost ([127.0.0.1]:60564 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5gts-0001lv-DV for submit@debbugs.gnu.org; Mon, 29 Dec 2014 15:26:48 -0500 Received: from eggs.gnu.org ([208.118.235.92]:39842) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5gtq-0001ln-B4 for submit@debbugs.gnu.org; Mon, 29 Dec 2014 15:26:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y5gto-00015M-R6 for submit@debbugs.gnu.org; Mon, 29 Dec 2014 15:26:46 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:50057) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5gto-00015I-Oj for submit@debbugs.gnu.org; Mon, 29 Dec 2014 15:26:44 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41554) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5gtn-0002sp-6x for bug-gnu-emacs@gnu.org; Mon, 29 Dec 2014 15:26:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y5gti-00014b-60 for bug-gnu-emacs@gnu.org; Mon, 29 Dec 2014 15:26:43 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:51604) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5gth-00014R-Q9 for bug-gnu-emacs@gnu.org; Mon, 29 Dec 2014 15:26:38 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NHD00D002326Q00@a-mtaout20.012.net.il> for bug-gnu-emacs@gnu.org; Mon, 29 Dec 2014 22:26:36 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHD00DJR24B6C00@a-mtaout20.012.net.il> for bug-gnu-emacs@gnu.org; Mon, 29 Dec 2014 22:26:36 +0200 (IST) Date: Mon, 29 Dec 2014 22:26:23 +0200 From: Eli Zaretskii X-012-Sender: halo1@inter.net.il Message-id: <83zja6b3tc.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Make sure you generated src/TAGS, and then: emacs -Q C-x C-f src/buffer.c RET M-x visit-tags-table RET RET M-. display_line RET This pops up a *xref* buffer which looks like this: d:/gnu/git/emacs/trunk/src/xdisp.c display_line move_it_in_display_line_to move_it_in_display_line with point at the beginning of the first line. Why doesn't it put me on "display_line"s line, and display its definition at the same time? This is a regression from the old tags feature, where just "M-. RET" will already show the first matching definition. Further, this buffer's name, *xref*, has no mnemonic significance, and there are no clues as to what it wants to tell me or what is expected of me. The candidates are not mouse-sensitive, either, which is un-Emacsy. It functions like *Completions*, but it ain't one. By trial and error I found out that I'm expected to move to the candidate I want with cursor movement keys, and press RET to exit the buffer. Moving up an down is slow, probably because it visits files without waiting for RET or some other gesture to select a candidate (why was that design decision made?). Hitting RET on the first line, the one that shows the file name, results in "No reference at point", which is not really useful. Another peculiarity is that once I press arrow once, I can no longer get back to the first line, the one that shows the source file: pressing on the 2nd line doesn't move point, but it does return the original buffer to the window above *xref*. Weird. Finally, invoking the same command from the menu bar ought to present a dialog box with the candidates, according to the general rule: if a command was invoked by a mouse gesture, selection of candidates is via a GUI dialog, not a special-purpose buffer. But that doesn't happen. In sum: please make the new feature at least as good as the old one it replaces. And when introducing new exhibits, like the *xref* window, please make them self-explanatory and convenient/natural to use for newbies and veterans alike. TIA In GNU Emacs 25.0.50.110 (i686-pc-mingw32) of 2014-12-29 on HOME-C4E4A596F7 Repository revision: ce1ebdf1ba8acc75e8f959f414652cdc87e76401 Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --prefix=/d/usr --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'' Configured features: XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB Important settings: value of $LANG: ENU locale-coding-system: cp1255 Major mode: XREF Minor modes in effect: diff-auto-refine-mode: t tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: t line-number-mode: t Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Starting a new list of tags tables M-. runs the command xref-find-definitions M-, runs the command xref-pop-marker-stack Making tags completion table for d:/gnu/git/emacs/trunk/src/TAGS...80% Making tags completion table for d:/gnu/git/emacs/trunk/lisp/TAGS...94% Making tags completion table for d:/gnu/git/emacs/trunk/lwlib/TAGS... Making tags completion table for d:/gnu/git/emacs/trunk/src/TAGS...done Making completion list... xref--location-at-point: No reference at point Load-path shadows: None found. Features: (shadow sort gnus-util mail-extr emacsbug message dired format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils cl-macs gv thingatpt etags xref eieio byte-opt bytecomp byte-compile cl-extra cconv eieio-core cl-loaddefs cl-lib ring vc-git diff-mode easy-mmode cc-mode cc-fonts easymenu cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs time-date tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table w32-win w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer 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 make-network-process w32notify w32 multi-tty emacs) Memory information: ((conses 8 123285 11708) (symbols 32 104663 1) (miscs 32 77 302) (strings 16 108087 9345) (string-bytes 1 2510300) (vectors 8 15137) (vector-slots 4 446128 6934) (floats 8 75 209) (intervals 28 2628 236) (buffers 516 18)) From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 06:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , 19468@debbugs.gnu.org Cc: Helmut Eller Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141991948832162 (code B ref 19468); Tue, 30 Dec 2014 06:05:01 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 06:04:48 +0000 Received: from localhost ([127.0.0.1]:60647 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5pvD-0008Mg-L1 for submit@debbugs.gnu.org; Tue, 30 Dec 2014 01:04:48 -0500 Received: from mail-wi0-f170.google.com ([209.85.212.170]:36125) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5pvA-0008MX-Lr for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 01:04:45 -0500 Received: by mail-wi0-f170.google.com with SMTP id bs8so25002437wib.1 for <19468@debbugs.gnu.org>; Mon, 29 Dec 2014 22:04:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1amNtXd3vETVdnE+8AGT7T4byax4Q7QnH9oZeCtqSYA=; b=bZnMQYDE3TGqF3aRJT1LczdvALpx2ArtwEdZBghllvAVW8k0MaJK4h0ayksgbMrSak 14qlFcY+tmlkbL42oe19GJofi66SwyyntEdCZspBNwWmya02CWZeO+MPSa+7+6HFJ0/G ADcaRMJrnegnBvrYanuvHdJSFKuQeoPB67DDIMg/qoPALwAuZ/EhcPbH5Wk5S5jHA6xx Jm0SNuVhjKn6Nme1z0O8pCPF1uCeqb7U+/yWXebKH+m7UURe2bbwQXiDjgYyaUXzgTGg xu594KNn0rZfGK/E3iqgLmZJ70Mbed21wNY8lnxLOYjQNW4tTJko2zasNdJPwQug5hC6 E4OA== X-Received: by 10.180.76.132 with SMTP id k4mr103752463wiw.41.1419919483736; Mon, 29 Dec 2014 22:04:43 -0800 (PST) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id i3sm41381460wie.23.2014.12.29.22.04.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Dec 2014 22:04:43 -0800 (PST) Message-ID: <54A24079.4020902@yandex.ru> Date: Tue, 30 Dec 2014 08:04:41 +0200 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> In-Reply-To: <83zja6b3tc.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 12/29/2014 10:26 PM, Eli Zaretskii wrote: > Why doesn't it put me on "display_line"s line, and display its > definition at the same time? This is a regression from the old tags > feature, where just "M-. RET" will already show the first matching > definition. It's a tradeoff. Otherwise, you'd see two new buffers at once, possibly covering both windows (if you have two). And it seems inconsistent with your further complaint that movement visits files automatically (if it shouldn't, it shouldn't start with displaying the buffer at point either). Compared to `find-tag', you see the list of all possible definitions (and only if there are several). What are the odds that the first location is the right one anyway? > Further, this buffer's name, *xref*, has no mnemonic significance, and > there are no clues as to what it wants to tell me or what is expected > of me. Would you like it to be called the same as the current command? *xref-find-definitions-other-window*, *xref-find-apropos*, etc? > The candidates are not mouse-sensitive, either, which is > un-Emacsy. It functions like *Completions*, but it ain't one. One might argue that using the mouse is also un-Emacsy. But sure, that shouldn't be hard to add (and would increase discoverability). > By trial and error I found out that I'm expected to move to the > candidate I want with cursor movement keys, Or with `.' and `,', which are a bit easier to press right after `M-.'. > Moving up an down is slow, probably because it visits files > without waiting for RET or some other gesture to select a candidate > (why was that design decision made?). If you look at the related thread in emacs-devel, you'll see that it hasn't been discussed at all. Helmut implemented it this way, and apparently everyone that looked at it (the few people that did), liked it. I expect it will have its admirers, since helm-swoop, a package with the same visual effect, is pretty popular. This can be made configurable, though. For instance, `C-o' could be that "other gesture". Would you prefer the window configuration restored before point moves to a different line, or should the new buffer keep being displayed? The latter presents a challenge if we want `q' in the xref buffer to restore the original window configuration before xref-find-definitions was invoked, as long as the user hadn't made any manual changes thereafter. > Hitting RET on the first line, > the one that shows the file name, results in "No reference at point", > which is not really useful. Would you prefer to navigate to the first line of that file? That seems unlikely. > Another peculiarity is that once I press arrow once, I can no > longer get back to the first line, the one that shows the source file: > pressing on the 2nd line doesn't move point, but it does return > the original buffer to the window above *xref*. Weird. A bit weird, yes. Would you prefer not to "return the original buffer"? > Finally, invoking the same command from the menu bar ought to present > a dialog box with the candidates, according to the general rule: if a > command was invoked by a mouse gesture, selection of candidates is via > a GUI dialog, not a special-purpose buffer. But that doesn't happen. Example? Since when do we have a working completion interface that uses a GUI dialog ("open file" doesn't count)? If it's as fully functional, then sure, we should use that. As a counterpoint, Buffers->Select Named Buffer... uses the minibuffer. > In sum: please make the new feature at least as good as the old one it > replaces. I'd say it's already much better, but maybe not in all respects. And the latter would be a tough goal. > And when introducing new exhibits, like the *xref* window, > please make them self-explanatory and convenient/natural to use for > newbies and veterans alike. That's a great ideal to strive for, but a poor criterion for acceptance (convenient and natural are subjective notions). When the veterans don't participate in the discussion about a new feature, I suspect having follow-up discussions in bug reports would often be inevitable. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Helmut Eller Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 08:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org, Dmitry Gutov Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141992756513299 (code B ref 19468); Tue, 30 Dec 2014 08:20:02 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 08:19:25 +0000 Received: from localhost ([127.0.0.1]:60687 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5s1U-0003SR-FC for submit@debbugs.gnu.org; Tue, 30 Dec 2014 03:19:24 -0500 Received: from mail-wi0-f175.google.com ([209.85.212.175]:38658) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5s1S-0003SI-Ax for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 03:19:22 -0500 Received: by mail-wi0-f175.google.com with SMTP id l15so23605444wiw.8 for <19468@debbugs.gnu.org>; Tue, 30 Dec 2014 00:19:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=iANXuGI/OTlgxi/Gbc+wG2fIzBkaY135j+FFjlyhNnY=; b=vniKgh2rK35EqDNn7/Dweho/uvQQjE+jRtyixmTwQY7fAZUXCOX91x4ijwP7NdMHhC Ep1Zm5blCrATzx5g6vqe+mgkAJp7GjyXkPT1g6XJTrc7hoeCNMEHIDA34TCTMr/C5H0h uNmqxlye8oWBp5N1ehlEsFRpQs19YKuDhRks+i3wQZ85iIYBeU4P+GB2FGZKsZr27qa1 QJEKEjHH8GHek63onLOqKZi7AqppEmD+B3nnWYjX4KOURt/qKgNMWPxTHB+0bk6dOTLh 1dwTLlnnaq0W74F60si13tIZuHGBFgJHd0K5vFpa6oKuoHB1mHcuL8s0Ih5XcTvkM7Gz LUyg== X-Received: by 10.180.207.211 with SMTP id ly19mr104682652wic.73.1419927561834; Tue, 30 Dec 2014 00:19:21 -0800 (PST) Received: from ix ([212.46.172.21]) by mx.google.com with ESMTPSA id h8sm42450363wiy.17.2014.12.30.00.19.20 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 30 Dec 2014 00:19:21 -0800 (PST) Received: from helmut by ix with local (Exim 4.80) (envelope-from ) id 1Y5s1O-00010K-TP; Tue, 30 Dec 2014 09:19:19 +0100 From: Helmut Eller References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> Date: Tue, 30 Dec 2014 09:19:18 +0100 In-Reply-To: <54A24079.4020902@yandex.ru> (Dmitry Gutov's message of "Tue, 30 Dec 2014 08:04:41 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Tue, Dec 30 2014, Dmitry Gutov wrote: > On 12/29/2014 10:26 PM, Eli Zaretskii wrote: > >> Why doesn't it put me on "display_line"s line, and display its >> definition at the same time? As Dmitry says: that would replace the current buffer and at the same time create and switch to the *xref* buffer. I had tried that and it didn't like it. >> This is a regression from the old tags >> feature, where just "M-. RET" will already show the first matching >> definition. It's not a regression as M-. is now a different command with a different UI. My goal was never to be 100% backward compatible with find-tag but to make something better. You lost your key binding for find-tag. Sorry about that, but there are only so many good keys. Of course, you know how to get the old key binding back. > It's a tradeoff. Otherwise, you'd see two new buffers at once, > possibly covering both windows (if you have two). And it seems > inconsistent with your further complaint that movement visits files > automatically (if it shouldn't, it shouldn't start with displaying the > buffer at point either). > > Compared to `find-tag', you see the list of all possible definitions > (and only if there are several). What are the odds that the first > location is the right one anyway? > >> Further, this buffer's name, *xref*, has no mnemonic significance, and >> there are no clues as to what it wants to tell me or what is expected >> of me. > > Would you like it to be called the same as the current command? > *xref-find-definitions-other-window*, *xref-find-apropos*, etc? I bet that after 15 minutes of using it, nobody will care what the name of the *xref* buffer is. So we can just as well use something short. [...] >> By trial and error I found out that I'm expected to move to the >> candidate I want with cursor movement keys, Trial and error isn't the worst way to learn things; at least if it doesn't take too long. Apparently you didn't even need to read any documentation, which would indicate that the UI is not so unintuitive after all. [...] >> Moving up an down is slow, probably because it visits files >> without waiting for RET or some other gesture to select a candidate For me, opening the file the first time is a bit slow, but after that moving up and down is instantaneous. [...] >> Another peculiarity is that once I press arrow once, I can no >> longer get back to the first line, the one that shows the source >> file: That's as expected. There is nothing to select on the first line. >> pressing on the 2nd line doesn't move point, but it does return >> the original buffer to the window above *xref*. Weird. > > A bit weird, yes. Would you prefer not to "return the original buffer"? I didn't implement that. It's because of the save-window-excursion in xref--next-line that Dmitry added. In my proposal the other window didn't change when the cursor didn't move. >> In sum: please make the new feature at least as good as the old one it >> replaces. You can't make progress by keeping everything the same. Helmut From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 15:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: eller.helmut@gmail.com, 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14199540871858 (code B ref 19468); Tue, 30 Dec 2014 15:42:02 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 15:41:27 +0000 Received: from localhost ([127.0.0.1]:32945 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5yvG-0000Tt-6K for submit@debbugs.gnu.org; Tue, 30 Dec 2014 10:41:26 -0500 Received: from mtaout28.012.net.il ([80.179.55.184]:39048) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5yvC-0000Tf-DB for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 10:41:23 -0500 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NHE00K00JCDP800@mtaout28.012.net.il> for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 17:39:12 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHE00JCBJHCVU10@mtaout28.012.net.il>; Tue, 30 Dec 2014 17:39:12 +0200 (IST) Date: Tue, 30 Dec 2014 17:41:10 +0200 From: Eli Zaretskii In-reply-to: <54A24079.4020902@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83tx0db0x5.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 30 Dec 2014 08:04:41 +0200 > From: Dmitry Gutov > CC: Helmut Eller > > On 12/29/2014 10:26 PM, Eli Zaretskii wrote: > > Why doesn't it put me on "display_line"s line, and display its > definition at the same time? This is a regression from the old tags > feature, where just "M-. RET" will already show the first matching > definition. > > > It's a tradeoff. Otherwise, you'd see two new buffers at once, possibly covering both windows (if you have two). Sorry, I don't follow. I started that from a single window, and M-. already did split it into 2, and displayed the candidates in the lower one. So I already see 2 buffers, and showing the first candidate in the upper window doesn't do anything I won't expect -- after all, I did ask to see something different from what I was already seeing. > And it seems inconsistent with your further complaint that movement visits files automatically (if it shouldn't, it shouldn't start with displaying the buffer at point either). I see no inconsistency: we could display the first candidate automatically, but not switch to others without the user's say-so. Imagine a situation where the list of possible candidates is very long, longer than what the window shows. Then the user might wish to scroll the list of candidates before she makes up her mind about the one she wants to see. But moving point visits the candidates, which is not what the user asked for in this use case. Moreover, I see that scrolling the window by C-v/PageDn does _not_ visit the tags at point, while scrolling by up- and down- arrow key does. Looks like another confusing inconsistency. So I suggest that the automatic visiting will be at least customizable, if not switched off by default. > Compared to `find-tag', you see the list of all possible definitions (and only if there are several). What are the odds that the first location is the right one anyway? With completion? excellent. Moreover, the old find-tags employed some logic in its completion, so that matches that are more likely appear first. I generally found the results very good, certainly in languages which require symbols to have unique names on the source level. > Further, this buffer's name, *xref*, has no mnemonic significance, and > there are no clues as to what it wants to tell me or what is expected > of me. > > > Would you like it to be called the same as the current command? *xref-find-definitions-other-window*, *xref-find-apropos*, etc? How about "*find-function-candidates*" or even "*Completions*"? > The candidates are not mouse-sensitive, either, which is > un-Emacsy. It functions like *Completions*, but it ain't one. > > > One might argue that using the mouse is also un-Emacsy. That ship sailed a long time ago. > But sure, that shouldn't be hard to add (and would increase discoverability). More importantly, it will tell the user what she needs to do, even if she doesn't use the mouse, because mouse-sensitive portions of Emacs display generally behave very similarly. > By trial and error I found out that I'm expected to move to the > candidate I want with cursor movement keys, > > > Or with `.' and `,', which are a bit easier to press right after `M-.'. It would be nice to have some instructions to this effect. Once again, this is not a UI that is used in other places in Emacs, it is very different. So you shouldn't assume that its keybindings are known by users, especially keybindings such as '.' and ',' that are not widely used in other programs, and therefore must be learned anew. > > Moving up an down is slow, probably because it visits files > > without waiting for RET or some other gesture to select a candidate > (why was that design decision made?). > > If you look at the related thread in emacs-devel, you'll see that it hasn't been discussed at all. Helmut implemented it this way, and apparently everyone that looked at it (the few people that did), liked it. I expect it will have its admirers, since helm-swoop, a package with the same visual effect, is pretty popular. I described above one use case where I think this reaction to moving point will not be appreciated by users, since Emacs moves point as result of scrolling. > This can be made configurable, though. For instance, `C-o' could be that "other gesture". Would you prefer the window configuration restored before point moves to a different line, or should the new buffer keep being displayed? The latter presents a challenge if we want `q' in the xref buffer to restore the original window configuration before xref-find-definitions was invoked, as long as the user hadn't made any manual changes thereafter. Why is it a challenge? Typing 'q' and 'C-o' can invoke different functions, can't it? I'm probably missing something. > > Hitting RET on the first line, > > the one that shows the file name, results in "No reference at point", > which is not really useful. > > > Would you prefer to navigate to the first line of that file? That seems unlikely. My point is that putting me on that line when the buffer pops up makes little sense, because that line is just a heading. > Another peculiarity is that once I press arrow once, I can no > longer get back to the first line, the one that shows the source file: > pressing on the 2nd line doesn't move point, but it does return > the original buffer to the window above *xref*. Weird. > > A bit weird, yes. Would you prefer not to "return the original buffer"? No, I prefer that the lines that show file names be not reachable at all. They are just clutter, as far as moving point is concerned. Let point jump over them. > Finally, invoking the same command from the menu bar ought to present > a dialog box with the candidates, according to the general rule: if a > command was invoked by a mouse gesture, selection of candidates is via > a GUI dialog, not a special-purpose buffer. But that doesn't happen. > > Example? Click File->Quit when you have unsaved edits. > Since when do we have a working completion interface that uses a GUI dialog ("open file" doesn't count)? If it's as fully functional, then sure, we should use that. But this is not completion, this is a list of completion results. Completion happens _before_ the *xref* buffer is popped up. Or am I missing something? > As a counterpoint, Buffers->Select Named Buffer... uses the minibuffer. That _is_ completion. I'm not talking about prompting the user for a symbol, I'm talking about _displaying_ the matching symbols once the user has typed her input. > In sum: please make the new feature at least as good as the old one it > replaces. > > I'd say it's already much better, but maybe not in all respects. And the latter would be a tough goal. I don't think we can deprecate/obsolete find-tag unless xref is at least as good. And I don't see any reasons why it couldn't become as good or better, the issues I mentioned seem to be minor and easy to fix. > And when introducing new exhibits, like the *xref* window, > please make them self-explanatory and convenient/natural to use for > newbies and veterans alike. > > That's a great ideal to strive for, but a poor criterion for acceptance (convenient and natural are subjective notions). I agree it's subjective, but I think I provided explanations for my views. > When the veterans don't participate in the discussion about a new feature, I suspect having follow-up discussions in bug reports would often be inevitable. I'm sorry I didn't participate. The reason is that I never understood this is meant as a replacement for find-tag etc., until you asked whether to remove them from the menu bar. The discussion was long enough and focused on technicalities enough to turn me off. Perhaps a prominent announcement of the intent to replace Tags, with explicit reference to that word in the Subject, would have done a better job of attracting people who might have had something to say about this. Thanks. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 16:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Helmut Eller Cc: 19468@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14199552424442 (code B ref 19468); Tue, 30 Dec 2014 16:01:02 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 16:00:42 +0000 Received: from localhost ([127.0.0.1]:32950 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5zDt-00019Y-Gg for submit@debbugs.gnu.org; Tue, 30 Dec 2014 11:00:42 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:60821) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5zDp-00019E-Ou for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 11:00:39 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NHE00L00K84BS00@a-mtaout20.012.net.il> for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 18:00:35 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHE00KJJKGYYWB0@a-mtaout20.012.net.il>; Tue, 30 Dec 2014 18:00:35 +0200 (IST) Date: Tue, 30 Dec 2014 18:00:24 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83oaqlb013.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Helmut Eller > Cc: Dmitry Gutov , 19468@debbugs.gnu.org > Date: Tue, 30 Dec 2014 09:19:18 +0100 > > >> Why doesn't it put me on "display_line"s line, and display its > >> definition at the same time? > > As Dmitry says: that would replace the current buffer and at the same > time create and switch to the *xref* buffer. I had tried that and it > didn't like it. But that's what the old M-. did, so it should be at least an option, IMO. > >> This is a regression from the old tags > >> feature, where just "M-. RET" will already show the first matching > >> definition. > > It's not a regression as M-. is now a different command with a different > UI. My goal was never to be 100% backward compatible with find-tag but > to make something better. You lost your key binding for find-tag. Sorry > about that, but there are only so many good keys. Of course, you know > how to get the old key binding back. But etc/NEWS says that find-tag is now obsolete. So I think the replacement should be at least as good, in terms of usability and speed. I didn't ask for 100% backward compatibility, I'm asking for convenience and speed. I don't think they are unreasonable requests. > >> Further, this buffer's name, *xref*, has no mnemonic significance, and > >> there are no clues as to what it wants to tell me or what is expected > >> of me. > > > > Would you like it to be called the same as the current command? > > *xref-find-definitions-other-window*, *xref-find-apropos*, etc? > I bet that after 15 minutes of using it, nobody will care what the name > of the *xref* buffer is. So we can just as well use something short. I don't see how the length of the buffer's name is important here. Short names are okay if they explain themselves; this one doesn't. We periodically have discussions full of flames about discoverability in Emacs and its steep learning curve. It is my impression as a user that the name of this buffer, its specialized keybindings, and lack of instructions, don't make the curve less steep, to say the least. I hope we can do better, as the problems don't seem to be grave or hard to fix. > >> By trial and error I found out that I'm expected to move to the > >> candidate I want with cursor movement keys, > > Trial and error isn't the worst way to learn things; at least if it > doesn't take too long. Turns out I missed '.' and ',', though. So trial and error are evidently less efficient than we would want. > Apparently you didn't even need to read any documentation What documentation? These commands are not yet in the manual. Or maybe you meant this: M-. runs the command xref-find-definitions (found in global-map), which is an interactive autoloaded Lisp function in `xref.el'. It is bound to M-., . (xref-find-definitions IDENTIFIER) Find the definition of the identifier at point. With prefix argument, prompt for the identifier. That's the entire doc string of the command, all of it. (Btw, it doesn't even say that if no identifier is found at point, it will prompt even without an argument.) I hope now you understand why I needed to "try and err". > >> Another peculiarity is that once I press arrow once, I can no > >> longer get back to the first line, the one that shows the source > >> file: > > That's as expected. There is nothing to select on the first line. Then why let me position point there? > >> In sum: please make the new feature at least as good as the old one it > >> replaces. > > You can't make progress by keeping everything the same. Once again, no one asked for "the same". I'm asking for the new feature to be at least as convenient and fast as the one it replaces. The two issues that I find annoying about this are: the first candidate is not displayed until I press a key, and I'm unable to find functions that the current major mode doesn't know about. I hope these can be fixed, they don't seem major to me. Thanks. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Helmut Eller Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 17:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141995899211714 (code B ref 19468); Tue, 30 Dec 2014 17:04:02 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 17:03:12 +0000 Received: from localhost ([127.0.0.1]:33001 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y60CN-00032r-Vo for submit@debbugs.gnu.org; Tue, 30 Dec 2014 12:03:12 -0500 Received: from mail-wg0-f42.google.com ([74.125.82.42]:59624) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y60CD-00032I-O0 for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 12:03:10 -0500 Received: by mail-wg0-f42.google.com with SMTP id k14so21122444wgh.29 for <19468@debbugs.gnu.org>; Tue, 30 Dec 2014 09:03:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=wd9RzVyP3FaECn9WWzfVsy/8wCR/X9HPnalsQF9tia4=; b=tzqVZvk+GXWi6YCGGcQmdTiCx/f/4xWHVa9Tkwnef/S1yiAMPpqZlhuLhIR2MvxBqN SBq34K08jV5UKnKX0KR+Df/+HNoL4t+NypScmQzGPUckj2SMrx6YKFJd+Dd7pDcXo4jL 7KdroG7EulpVF1cLDZiao/LVxkEpkKDlE3p7OIDBihxO53a4NBq1c82yv1WGmHsxm6QS WdJvEe3CbueNsmPf4XQYtZ6mzDuz/zvkNa67J54jOTFcehUFBsAmufKVQPsuQss9Ud3C 4+8DNDvcCZOq6rt2v72vq0jPNFLDS8K9vLurPolZRAMTMSS9vT990JqbxokBzqEYTF0P EYDw== X-Received: by 10.194.92.37 with SMTP id cj5mr123533200wjb.81.1419958981095; Tue, 30 Dec 2014 09:03:01 -0800 (PST) Received: from ix ([212.46.172.21]) by mx.google.com with ESMTPSA id p14sm44081193wie.1.2014.12.30.09.02.59 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 30 Dec 2014 09:03:00 -0800 (PST) Received: from helmut by ix with local (Exim 4.80) (envelope-from ) id 1Y60CB-0001NY-4U; Tue, 30 Dec 2014 18:02:59 +0100 From: Helmut Eller References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <83oaqlb013.fsf@gnu.org> Date: Tue, 30 Dec 2014 18:02:59 +0100 In-Reply-To: <83oaqlb013.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 30 Dec 2014 18:00:24 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Tue, Dec 30 2014, Eli Zaretskii wrote: >> From: Helmut Eller >> Cc: Dmitry Gutov , 19468@debbugs.gnu.org >> Date: Tue, 30 Dec 2014 09:19:18 +0100 >> >> >> Why doesn't it put me on "display_line"s line, and display its >> >> definition at the same time? >> >> As Dmitry says: that would replace the current buffer and at the same >> time create and switch to the *xref* buffer. I had tried that and it >> didn't like it. > > But that's what the old M-. did, No, find-tag didn't display a list of candidates. > so it should be at least an option, > IMO. As I said: been there, done that, didn't like it. Helmut From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 17:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Eli Zaretskii , Helmut Eller , 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141995901411752 (code B ref 19468); Tue, 30 Dec 2014 17:04:02 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 17:03:34 +0000 Received: from localhost ([127.0.0.1]:33004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y60Cj-00033U-J9 for submit@debbugs.gnu.org; Tue, 30 Dec 2014 12:03:33 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:51607) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y60Ci-00033M-3n for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 12:03:32 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8PAOwQflRFpY0B/2dsb2JhbABbgweDYIVawjuCYgQCAoEkFwEBAQEBAXyEAwEBAwFWIwULCw4mEhQYDSSISgnWWQEBAQEBBQEBAQEekG8HhEgFiwGSMY9zggqBeIQZIYJ3AQEB X-IPAS-Result: Aj8PAOwQflRFpY0B/2dsb2JhbABbgweDYIVawjuCYgQCAoEkFwEBAQEBAXyEAwEBAwFWIwULCw4mEhQYDSSISgnWWQEBAQEBBQEBAQEekG8HhEgFiwGSMY9zggqBeIQZIYJ3AQEB X-IronPort-AV: E=Sophos;i="5.07,502,1413259200"; d="scan'208";a="104173217" Received: from 69-165-141-1.dsl.teksavvy.com (HELO ceviche.home) ([69.165.141.1]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Dec 2014 12:03:31 -0500 Received: by ceviche.home (Postfix, from userid 20848) id 732D8660FB; Tue, 30 Dec 2014 12:03:30 -0500 (EST) From: Stefan Monnier Message-ID: References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> Date: Tue, 30 Dec 2014 12:03:30 -0500 In-Reply-To: <54A24079.4020902@yandex.ru> (Dmitry Gutov's message of "Tue, 30 Dec 2014 08:04:41 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > It's a tradeoff. Otherwise, you'd see two new buffers at once, possibly > covering both windows (if you have two). And it seems inconsistent with your > further complaint that movement visits files automatically (if it shouldn't, > it shouldn't start with displaying the buffer at point either). I thought the problem that Eli was pointing out is that he requested "display_line" and there is only one "display_line", so instead of showing 3 entries (each one including "display_line" as a substring) we should directly jump to the perfect match. Stefan From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 17:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , Helmut Eller , 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141995949312513 (code B ref 19468); Tue, 30 Dec 2014 17:12:02 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 17:11:33 +0000 Received: from localhost ([127.0.0.1]:33010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y60KS-0003Fh-HJ for submit@debbugs.gnu.org; Tue, 30 Dec 2014 12:11:32 -0500 Received: from mail-wg0-f47.google.com ([74.125.82.47]:43398) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y60KQ-0003FX-48 for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 12:11:30 -0500 Received: by mail-wg0-f47.google.com with SMTP id n12so20751022wgh.6 for <19468@debbugs.gnu.org>; Tue, 30 Dec 2014 09:11:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8D/gEnFikoQXR9PAf8e0JbQR8ohIGLmsAfRicAfqAMI=; b=Wi+1q+vAOLcuy8L6VOEp0hQXRBj3eXAOC0P1THbYXAyWphF+7ExGZNK3PPFTidpi6q 0g1OrGgfqbglTOXWQMNcw+kUXAgSA96wyZM6xnXx4fqs3vwGbzSY+/1ATP81a5TR1ddp eUr3S7/pesSzTtx1refBfGvxusQyydnzZ8hNbWp81fLKz2T5rINHp0GpY7fb/zSZu2LB vQQOtc/KKg2avogAE7TXQF+Byikl7QKKzns8lBlLy2svkNAMiVSOHaDK/IKfiVrJSB6a qnkZiG8KnDFjqquTTeJb9t0EzNfo+WSDtaLDCU910LJE+OTC1Wr3JtzOOCZ9+YUKTjgI ILwg== X-Received: by 10.180.75.199 with SMTP id e7mr109208774wiw.21.1419959489636; Tue, 30 Dec 2014 09:11:29 -0800 (PST) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id fo12sm44067310wic.19.2014.12.30.09.11.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Dec 2014 09:11:29 -0800 (PST) Message-ID: <54A2DCBC.6010406@yandex.ru> Date: Tue, 30 Dec 2014 19:11:24 +0200 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 12/30/2014 07:03 PM, Stefan Monnier wrote: > I thought the problem that Eli was pointing out is that he requested > "display_line" and there is only one "display_line", so instead of > showing 3 entries (each one including "display_line" as a substring) we > should directly jump to the perfect match. Not really (see his response), but indeed, filtering out imperfect matches retrieved from tags file would be an improvement. Suppose there are several "perfect" matches. Should the imperfect matches be included in the list too, then? From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Helmut Eller Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 17:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , 19468@debbugs.gnu.org, Dmitry Gutov Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141996030914122 (code B ref 19468); Tue, 30 Dec 2014 17:26:01 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 17:25:09 +0000 Received: from localhost ([127.0.0.1]:33021 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y60Xc-0003fi-Ls for submit@debbugs.gnu.org; Tue, 30 Dec 2014 12:25:08 -0500 Received: from mail-wg0-f49.google.com ([74.125.82.49]:57075) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y60XZ-0003fX-Or for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 12:25:06 -0500 Received: by mail-wg0-f49.google.com with SMTP id n12so20819358wgh.8 for <19468@debbugs.gnu.org>; Tue, 30 Dec 2014 09:25:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=JwDiR0SfqVGNGAk4Dh1B1yo9p54xof8QdO77d8Au1+w=; b=Og48fP+ngOImhoHT0DGI4B43TDOIcHyVa5aVgMkECK35Tcv7MZvTH1ctAVE9HvJCqv 2MCBIAQVOx/d7Vpuevi14scqjZiSEpPR0QxmWWd8PX2cHDFs1FkzBsUXsM5bPGPNH1WO Hly4Mew7aD1mxMJYLVeiOKH3hKb5tMsMWEfiOfT/XclMM9q/YOChJF+k/Fdl0JTecJbY +OaLfC2olMO/7nRSpcbdo/Ovc6wWiGpB8nPgw/npynev9frjmPSyNTncF7U+4YtHsSXa sL5lhJouS+sMpHu+N/EMvus6ZkhXoqcSFfIwcfXtF+oFIWFw6BUnqNQAiHFU85Ef/Zv+ GLKQ== X-Received: by 10.194.174.72 with SMTP id bq8mr119058839wjc.120.1419960305285; Tue, 30 Dec 2014 09:25:05 -0800 (PST) Received: from ix ([212.46.172.21]) by mx.google.com with ESMTPSA id x2sm54603564wjx.9.2014.12.30.09.25.04 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 30 Dec 2014 09:25:04 -0800 (PST) Received: from helmut by ix with local (Exim 4.80) (envelope-from ) id 1Y60XX-0001O2-Mu; Tue, 30 Dec 2014 18:25:03 +0100 From: Helmut Eller References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> Date: Tue, 30 Dec 2014 18:25:03 +0100 In-Reply-To: (Stefan Monnier's message of "Tue, 30 Dec 2014 12:03:30 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Tue, Dec 30 2014, Stefan Monnier wrote: >> It's a tradeoff. Otherwise, you'd see two new buffers at once, possibly >> covering both windows (if you have two). And it seems inconsistent with your >> further complaint that movement visits files automatically (if it shouldn't, >> it shouldn't start with displaying the buffer at point either). > > I thought the problem that Eli was pointing out is that he requested > "display_line" and there is only one "display_line", so instead of > showing 3 entries (each one including "display_line" as a substring) we > should directly jump to the perfect match. That's not an UI issue, that is a backend issue. The etags backend produces a high number of false positives. That's not new and as in the past it can be fixed with a more strict find-tag-tag-order. Helmut From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 17:40:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Helmut Eller Cc: 19468@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141996120215671 (code B ref 19468); Tue, 30 Dec 2014 17:40:04 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 17:40:02 +0000 Received: from localhost ([127.0.0.1]:33034 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y60m1-00044V-A8 for submit@debbugs.gnu.org; Tue, 30 Dec 2014 12:40:02 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:44688) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y60ly-00044M-VO for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 12:39:59 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NHE00L00OG7V700@a-mtaout20.012.net.il> for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 19:39:57 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHE00LQ5P2LVJ10@a-mtaout20.012.net.il>; Tue, 30 Dec 2014 19:39:57 +0200 (IST) Date: Tue, 30 Dec 2014 19:39:47 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83d271avfg.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <83oaqlb013.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Helmut Eller > Cc: dgutov@yandex.ru, 19468@debbugs.gnu.org > Date: Tue, 30 Dec 2014 18:02:59 +0100 > > On Tue, Dec 30 2014, Eli Zaretskii wrote: > > >> From: Helmut Eller > >> Cc: Dmitry Gutov , 19468@debbugs.gnu.org > >> Date: Tue, 30 Dec 2014 09:19:18 +0100 > >> > >> >> Why doesn't it put me on "display_line"s line, and display its > >> >> definition at the same time? > >> > >> As Dmitry says: that would replace the current buffer and at the same > >> time create and switch to the *xref* buffer. I had tried that and it > >> didn't like it. > > > > But that's what the old M-. did, > > No, find-tag didn't display a list of candidates. I meant the "display the first candidate" part. > > so it should be at least an option, > > IMO. > > As I said: been there, done that, didn't like it. But that's what options are for: to allow different people customize Emacs to their taste. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 17:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 19468@debbugs.gnu.org, eller.helmut@gmail.com, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141996128715833 (code B ref 19468); Tue, 30 Dec 2014 17:42:02 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 17:41:27 +0000 Received: from localhost ([127.0.0.1]:33039 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y60nO-00047J-KI for submit@debbugs.gnu.org; Tue, 30 Dec 2014 12:41:26 -0500 Received: from mtaout28.012.net.il ([80.179.55.184]:58709) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y60nM-00047A-Nh for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 12:41:25 -0500 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NHE00L00OL95A00@mtaout28.012.net.il> for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 19:39:14 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHE00IZHP1EBQ30@mtaout28.012.net.il>; Tue, 30 Dec 2014 19:39:14 +0200 (IST) Date: Tue, 30 Dec 2014 19:41:13 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83bnmlavd2.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: Eli Zaretskii , 19468@debbugs.gnu.org, Helmut Eller > Date: Tue, 30 Dec 2014 12:03:30 -0500 > > > It's a tradeoff. Otherwise, you'd see two new buffers at once, possibly > > covering both windows (if you have two). And it seems inconsistent with your > > further complaint that movement visits files automatically (if it shouldn't, > > it shouldn't start with displaying the buffer at point either). > > I thought the problem that Eli was pointing out is that he requested > "display_line" and there is only one "display_line", so instead of > showing 3 entries (each one including "display_line" as a substring) we > should directly jump to the perfect match. Indeed, that's what I meant. It is okay to display other, less perfect, matches as well, but the exact match should be displayed without asking me to type anything else. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 17:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: eller.helmut@gmail.com, monnier@iro.umontreal.ca, 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141996139716025 (code B ref 19468); Tue, 30 Dec 2014 17:44:02 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 17:43:17 +0000 Received: from localhost ([127.0.0.1]:33043 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y60pB-0004AP-2x for submit@debbugs.gnu.org; Tue, 30 Dec 2014 12:43:17 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:34328) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y60p8-0004AF-Sh for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 12:43:15 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NHE00900P1CKB00@a-mtaout22.012.net.il> for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 19:43:13 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHE00991P81GE20@a-mtaout22.012.net.il>; Tue, 30 Dec 2014 19:43:13 +0200 (IST) Date: Tue, 30 Dec 2014 19:43:03 +0200 From: Eli Zaretskii In-reply-to: <54A2DCBC.6010406@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83a925ava0.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2DCBC.6010406@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 30 Dec 2014 19:11:24 +0200 > From: Dmitry Gutov > CC: Eli Zaretskii , 19468@debbugs.gnu.org, > Helmut Eller > > Suppose there are several "perfect" matches. Should the imperfect > matches be included in the list too, then? Find-tag, when called with an argument, would go through all the possible matches one by one, starting from the "perfect" one. So yes, I think it is good to present the list of all the candidates, it will be functionally equivalent to what find-tag did. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 17:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Helmut Eller , 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141996176216617 (code B ref 19468); Tue, 30 Dec 2014 17:50:01 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 17:49:22 +0000 Received: from localhost ([127.0.0.1]:33047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y60v3-0004Jx-TE for submit@debbugs.gnu.org; Tue, 30 Dec 2014 12:49:22 -0500 Received: from mail-wg0-f52.google.com ([74.125.82.52]:38028) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y60v1-0004Jo-DV for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 12:49:20 -0500 Received: by mail-wg0-f52.google.com with SMTP id x12so20889838wgg.25 for <19468@debbugs.gnu.org>; Tue, 30 Dec 2014 09:49:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=zSHHe6lw6ny3PeB/1m1MMCTDawQloOCOn5puVeNW6lM=; b=jUTePVdsXKQ1cn5xlsfJ8MEKUwYVtBEDUTrpGrLpmAMSe9nWDnYHcMkjbwBfMGDwhX 0hENQR5Mkix2nZC6+VWne01BUTmkzx4T7kAUQ4710rT4P8UdpPC6wMCPs6TCKWkBA5Xn aPL3u/g0M2tM19XjL9l6hTj8ypuYKpERi/5RWHVBBj/m9oXsrFP2/I2cncunAROG7bJ4 SvSVo5jlA2odIi7ovZ7jEOFj0guUEaAXZ27SF6s7kGDue4lCkdKDUPvicZt/5yuUlQ+z 42PYvyyp/cz3oI+49xY2NTfW4nZbyxY/EbY1Aq+YpEpSr6DCpv3rvZ/SWlxntVwMwXWI NWJw== X-Received: by 10.180.72.33 with SMTP id a1mr106629497wiv.18.1419961758840; Tue, 30 Dec 2014 09:49:18 -0800 (PST) Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id la10sm24833116wjc.36.2014.12.30.09.49.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Dec 2014 09:49:18 -0800 (PST) Message-ID: <54A2E59C.4000501@yandex.ru> Date: Tue, 30 Dec 2014 19:49:16 +0200 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2DCBC.6010406@yandex.ru> In-Reply-To: <54A2DCBC.6010406@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 12/30/2014 07:11 PM, Dmitry Gutov wrote: > Should the imperfect matches be included in the list too, then? Actually, should the imperfect matches be included in the "find definitions" list at all, even if there are no perfect ones? I'd say no, even though `find-tag' does that, and its users might expect it. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Helmut Eller Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 17:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org, Stefan Monnier , dgutov@yandex.ru Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141996184516752 (code B ref 19468); Tue, 30 Dec 2014 17:51:02 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 17:50:45 +0000 Received: from localhost ([127.0.0.1]:33051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y60wP-0004M8-Bw for submit@debbugs.gnu.org; Tue, 30 Dec 2014 12:50:45 -0500 Received: from mail-wi0-f179.google.com ([209.85.212.179]:60861) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y60wN-0004Lz-W1 for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 12:50:44 -0500 Received: by mail-wi0-f179.google.com with SMTP id ex7so24443666wid.12 for <19468@debbugs.gnu.org>; Tue, 30 Dec 2014 09:50:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=d6aQxgfOBTxZmdtb+qV7GM0CTMcU2h6WYLWeiRteW9k=; b=P85wtFLpv9LdN8T5x4boDaPK3DRa96O1hQOcmG+CVKCrq+oSjYkwonjvVXc+cPN8zt C5TBO14iI6cL2YkVWxb7ndsuM/ri/bStoFZwl4pfjWyrlGVxNUsRYsfqNKZwTZH4BJvd N9bzxCLBvSDOQHd/Gdljd0oujUfxGujMw3E8i0/1qSCpXwOHUBnSytD0wLrZtAHFTAfv 9gR1458+9QOuTxCUtWblJUgyrOEt+BrkV20AvTpN9GFH2zycjqJJxfNXWV70P2FylcZN IBb1h34sv6C19trqZxm0NGu3sV4f2Poko+cSW095LwhvQQEs7rzr0mqPf8vkefr6oTSJ E23g== X-Received: by 10.180.85.34 with SMTP id e2mr109470851wiz.0.1419961843231; Tue, 30 Dec 2014 09:50:43 -0800 (PST) Received: from ix ([212.46.172.21]) by mx.google.com with ESMTPSA id s9sm44200884wiz.12.2014.12.30.09.50.42 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 30 Dec 2014 09:50:42 -0800 (PST) Received: from helmut by ix with local (Exim 4.80) (envelope-from ) id 1Y60wL-0001Oi-2U; Tue, 30 Dec 2014 18:50:41 +0100 From: Helmut Eller References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <83bnmlavd2.fsf@gnu.org> Date: Tue, 30 Dec 2014 18:50:41 +0100 In-Reply-To: <83bnmlavd2.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 30 Dec 2014 19:41:13 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Tue, Dec 30 2014, Eli Zaretskii wrote: >> I thought the problem that Eli was pointing out is that he requested >> "display_line" and there is only one "display_line", so instead of >> showing 3 entries (each one including "display_line" as a substring) we >> should directly jump to the perfect match. > > Indeed, that's what I meant. > > It is okay to display other, less perfect, matches as well, but the > exact match should be displayed without asking me to type anything > else. In other words: you want the old UI back. Helmut From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 17:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Stefan Monnier Cc: eller.helmut@gmail.com, 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141996204417080 (code B ref 19468); Tue, 30 Dec 2014 17:55:01 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 17:54:04 +0000 Received: from localhost ([127.0.0.1]:33055 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y60zc-0004RQ-3X for submit@debbugs.gnu.org; Tue, 30 Dec 2014 12:54:04 -0500 Received: from mail-wi0-f176.google.com ([209.85.212.176]:43433) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y60zZ-0004Qy-E7 for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 12:54:02 -0500 Received: by mail-wi0-f176.google.com with SMTP id ex7so24392545wid.15 for <19468@debbugs.gnu.org>; Tue, 30 Dec 2014 09:54:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=MhWpzpw7MJuzvwhoymazaji675MPGhTpb/yhTJE+f/8=; b=B+wDtFXLVljxdowRMc1OuJW8QW8EKYitt1oOnuL11DTVgWP5O1joDuFfCxEO3o/PMf 4IyeAzJuVOUdx27FltMKHh1bFPYUfFn4VnVkhDiJvqyMENxIpNaGWhNKZJpn2BtoaUua i9bFfowlex1qWvWtCdfujSc9dFhWrKOgAcyg+uQAGYDX16VkIbISJWt8FJlMRNFRlvkc FLOjuxOy9I4PmG5Ugzxp2r4ZsWRIy1PDm1LgKlm+5i9zehZuoqZ1bRZjg+Fl11F1I5Jo OLRFosePUFE9ZUDlCLfV+9rQLCxRF+Owax2rTtxNXPcA40S1AOysDmay4lYJ9UiQiR8B jolw== X-Received: by 10.180.100.98 with SMTP id ex2mr108719786wib.58.1419962040831; Tue, 30 Dec 2014 09:54:00 -0800 (PST) Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id lg7sm44233863wic.0.2014.12.30.09.53.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Dec 2014 09:54:00 -0800 (PST) Message-ID: <54A2E6B6.5020903@yandex.ru> Date: Tue, 30 Dec 2014 19:53:58 +0200 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <83bnmlavd2.fsf@gnu.org> In-Reply-To: <83bnmlavd2.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 12/30/2014 07:41 PM, Eli Zaretskii wrote: > It is okay to display other, less perfect, matches as well, Being magnanimous here doesn't help. It's the xref API: if the backend returns one result, we jump to it. Otherwise, show a list. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 18:00:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Helmut Eller Cc: 19468@debbugs.gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141996234717550 (code B ref 19468); Tue, 30 Dec 2014 18:00:04 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 17:59:07 +0000 Received: from localhost ([127.0.0.1]:33059 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y614U-0004Z0-N1 for submit@debbugs.gnu.org; Tue, 30 Dec 2014 12:59:07 -0500 Received: from mtaout24.012.net.il ([80.179.55.180]:50131) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y614O-0004YX-R6 for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 12:59:04 -0500 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NHE00100P1GOS00@mtaout24.012.net.il> for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 19:51:03 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHE00INBPL3FJ90@mtaout24.012.net.il>; Tue, 30 Dec 2014 19:51:03 +0200 (IST) Date: Tue, 30 Dec 2014 19:58:49 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <838uhpaujq.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <83bnmlavd2.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Helmut Eller > Cc: Stefan Monnier , dgutov@yandex.ru, 19468@debbugs.gnu.org > Date: Tue, 30 Dec 2014 18:50:41 +0100 > > On Tue, Dec 30 2014, Eli Zaretskii wrote: > > >> I thought the problem that Eli was pointing out is that he requested > >> "display_line" and there is only one "display_line", so instead of > >> showing 3 entries (each one including "display_line" as a substring) we > >> should directly jump to the perfect match. > > > > Indeed, that's what I meant. > > > > It is okay to display other, less perfect, matches as well, but the > > exact match should be displayed without asking me to type anything > > else. > > In other words: you want the old UI back. Not the old UI, the old functionality, at least the part that displayed the first match immediately. I don't mind the list of the candidates and the new method of switching to the other candidates, which are new with this UI. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 18:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: eller.helmut@gmail.com, monnier@iro.umontreal.ca, 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141996245217794 (code B ref 19468); Tue, 30 Dec 2014 18:01:01 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 18:00:52 +0000 Received: from localhost ([127.0.0.1]:33063 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y616C-0004cw-EF for submit@debbugs.gnu.org; Tue, 30 Dec 2014 13:00:52 -0500 Received: from mtaout26.012.net.il ([80.179.55.182]:37425) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y6169-0004cm-AZ for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 13:00:50 -0500 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NHE00M00PWOU800@mtaout26.012.net.il> for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 20:00:13 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHE00MXFQ0DES00@mtaout26.012.net.il>; Tue, 30 Dec 2014 20:00:13 +0200 (IST) Date: Tue, 30 Dec 2014 20:00:38 +0200 From: Eli Zaretskii In-reply-to: <54A2E6B6.5020903@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <837fx9augp.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <83bnmlavd2.fsf@gnu.org> <54A2E6B6.5020903@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 30 Dec 2014 19:53:58 +0200 > From: Dmitry Gutov > CC: eller.helmut@gmail.com, 19468@debbugs.gnu.org > > On 12/30/2014 07:41 PM, Eli Zaretskii wrote: > > It is okay to display other, less perfect, matches as well, > > Being magnanimous here doesn't help. It's the xref API: if the backend > returns one result, we jump to it. Otherwise, show a list. Why cannot the command jump to the first result, after it shows the list? From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 18:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: eller.helmut@gmail.com, monnier@iro.umontreal.ca, 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141996251817915 (code B ref 19468); Tue, 30 Dec 2014 18:02:02 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 18:01:58 +0000 Received: from localhost ([127.0.0.1]:33067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y617F-0004es-QW for submit@debbugs.gnu.org; Tue, 30 Dec 2014 13:01:58 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:48326) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y617C-0004ei-Nw for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 13:01:55 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NHE00M00PTK7D00@a-mtaout20.012.net.il> for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 20:01:53 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHE00L4VQ34SJ90@a-mtaout20.012.net.il>; Tue, 30 Dec 2014 20:01:52 +0200 (IST) Date: Tue, 30 Dec 2014 20:01:42 +0200 From: Eli Zaretskii In-reply-to: <54A2E59C.4000501@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <8361ctauex.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2DCBC.6010406@yandex.ru> <54A2E59C.4000501@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 30 Dec 2014 19:49:16 +0200 > From: Dmitry Gutov > Cc: Helmut Eller , 19468@debbugs.gnu.org > > On 12/30/2014 07:11 PM, Dmitry Gutov wrote: > > Should the imperfect matches be included in the list too, then? > > Actually, should the imperfect matches be included in the "find > definitions" list at all, even if there are no perfect ones? > > I'd say no Why not? From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Helmut Eller Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 18:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org, monnier@iro.umontreal.ca, Dmitry Gutov Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141996252017929 (code B ref 19468); Tue, 30 Dec 2014 18:02:02 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 18:02:00 +0000 Received: from localhost ([127.0.0.1]:33070 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y617I-0004f7-95 for submit@debbugs.gnu.org; Tue, 30 Dec 2014 13:02:00 -0500 Received: from mail-wi0-f178.google.com ([209.85.212.178]:36258) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y617G-0004er-0U for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 13:01:58 -0500 Received: by mail-wi0-f178.google.com with SMTP id em10so24347775wid.11 for <19468@debbugs.gnu.org>; Tue, 30 Dec 2014 10:01:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=86E0HQ0/UyhV+6reH0u74lIzdvEUeACGdWtodPqdoTs=; b=xcev2eGCp/0w5OlqKI/SANjCP/IQZJ5ZRT3R4x2DU1ndV65JvyMffRD0JbzBvK59A/ 7jMHecOtVXP7kzWJZpfBX8jd5uoMAseuubuEbPM2AFO7YAnO//C8aHzp1lkB6gO3pF3/ 4u69DEkqQmidY9fphj3GHDdii8n7q5pf7PttQL+CBxrfNvtJj/hCM97urmTTaLbECOKM fx/exN2nbNvsTlSSAZEP8CYVlD3zruF9vLwKx8EBlsLKew0uGdV/vq6K8L+B6P+vQ01P m7wq7u2tNyMooErG24EW7KRMBPmo2MAzDFrI5ZpDlTai265NlMnbFMMrpy7f4leUaxXK YswA== X-Received: by 10.194.177.225 with SMTP id ct1mr119418298wjc.75.1419962517433; Tue, 30 Dec 2014 10:01:57 -0800 (PST) Received: from ix ([212.46.172.21]) by mx.google.com with ESMTPSA id i3sm43515917wie.23.2014.12.30.10.01.56 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 30 Dec 2014 10:01:56 -0800 (PST) Received: from helmut by ix with local (Exim 4.80) (envelope-from ) id 1Y617D-0001Os-V8; Tue, 30 Dec 2014 19:01:56 +0100 From: Helmut Eller References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <83bnmlavd2.fsf@gnu.org> <54A2E6B6.5020903@yandex.ru> <837fx9augp.fsf@gnu.org> Date: Tue, 30 Dec 2014 19:01:55 +0100 In-Reply-To: <837fx9augp.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 30 Dec 2014 20:00:38 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Tue, Dec 30 2014, Eli Zaretskii wrote: > Why cannot the command jump to the first result, after it shows the > list? Because then you have a window that needs to be closed. Helmut From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 18:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Helmut Eller Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141996291118590 (code B ref 19468); Tue, 30 Dec 2014 18:09:01 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 18:08:31 +0000 Received: from localhost ([127.0.0.1]:33079 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61Db-0004pm-I2 for submit@debbugs.gnu.org; Tue, 30 Dec 2014 13:08:31 -0500 Received: from mail-wi0-f171.google.com ([209.85.212.171]:52112) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61DY-0004pd-T2 for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 13:08:29 -0500 Received: by mail-wi0-f171.google.com with SMTP id bs8so24434685wib.10 for <19468@debbugs.gnu.org>; Tue, 30 Dec 2014 10:08:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=9wyJ21F6iMsUatQlqXshHxqv9V7FG69Z7f/CusqNBIA=; b=K30nNrQc3GxVB/haaZHFcFLd8fApugOtAIuJQ3D/a7OAfaOJNNyrS93+qOvvCIOiT5 U/MeIKeDeDFp9WzkM9tMlv5ABNSybCVKC9yXzuljuLpVBIS3k3yxZdInYLqFxN6vtmNh YW5nnYHrYuM8kCfKb47/9chR63HNpGnuERgpDqJPG+Qj2b7NbmIGPHUDe0LT/SHTryyr ZsH7iQozA9rsgQ1jNfzkm0pd4OttyFp3d12TnTsJ5u+epWL53Ix0wLz8KgMc+sgSuMHw fnxGybPuumLPs0vHsN2vdSK+rAqAAyMPMsLvb8YN8njWOmj6pPUhInZ8zQP1i8tU7wh/ j4IQ== X-Received: by 10.180.107.136 with SMTP id hc8mr109066467wib.32.1419962908452; Tue, 30 Dec 2014 10:08:28 -0800 (PST) Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id kn5sm54694181wjb.48.2014.12.30.10.08.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Dec 2014 10:08:28 -0800 (PST) Message-ID: <54A2EA1A.8010005@yandex.ru> Date: Tue, 30 Dec 2014 20:08:26 +0200 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <83bnmlavd2.fsf@gnu.org> <838uhpaujq.fsf@gnu.org> In-Reply-To: <838uhpaujq.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 12/30/2014 07:58 PM, Eli Zaretskii wrote: > Not the old UI, the old functionality, at least the part that > displayed the first match immediately. The first match is only one `.' keypress away. Surely that's not a major issue? From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 18:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Helmut Eller Cc: Eli Zaretskii , 19468@debbugs.gnu.org, Dmitry Gutov Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141996293718632 (code B ref 19468); Tue, 30 Dec 2014 18:09:02 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 18:08:57 +0000 Received: from localhost ([127.0.0.1]:33082 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61E0-0004qS-UW for submit@debbugs.gnu.org; Tue, 30 Dec 2014 13:08:57 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:38648) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61Dy-0004qI-Ka for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 13:08:54 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8PAOwQflRFpY0B/2dsb2JhbABbgweDYIVawjuCYgQCAoEkFwEBAQEBAXyEAwEBAwFWIwULCzQSFBgNJIhKCdZZAQEBAQEBBAEBAQEBHZBvB4RIBYsBpC6BeIQZIYJ3AQEB X-IPAS-Result: Aj8PAOwQflRFpY0B/2dsb2JhbABbgweDYIVawjuCYgQCAoEkFwEBAQEBAXyEAwEBAwFWIwULCzQSFBgNJIhKCdZZAQEBAQEBBAEBAQEBHZBvB4RIBYsBpC6BeIQZIYJ3AQEB X-IronPort-AV: E=Sophos;i="5.07,502,1413259200"; d="scan'208";a="104190856" Received: from 69-165-141-1.dsl.teksavvy.com (HELO pastel.home) ([69.165.141.1]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Dec 2014 13:08:54 -0500 Received: by pastel.home (Postfix, from userid 20848) id 04670DE3; Tue, 30 Dec 2014 13:08:53 -0500 (EST) From: Stefan Monnier Message-ID: References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> Date: Tue, 30 Dec 2014 13:08:53 -0500 In-Reply-To: (Helmut Eller's message of "Tue, 30 Dec 2014 18:25:03 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > That's not an UI issue, that is a backend issue. Good, Stefan From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 18:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Helmut Eller Cc: 19468@debbugs.gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141996324819145 (code B ref 19468); Tue, 30 Dec 2014 18:15:02 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 18:14:08 +0000 Received: from localhost ([127.0.0.1]:33087 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61J1-0004yj-Nu for submit@debbugs.gnu.org; Tue, 30 Dec 2014 13:14:08 -0500 Received: from mtaout26.012.net.il ([80.179.55.182]:39553) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61Iz-0004ya-JH for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 13:14:06 -0500 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NHE00O00QAFNW00@mtaout26.012.net.il> for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 20:13:30 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHE00MJNQMIES30@mtaout26.012.net.il>; Tue, 30 Dec 2014 20:13:30 +0200 (IST) Date: Tue, 30 Dec 2014 20:13:54 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <834msdatul.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <83bnmlavd2.fsf@gnu.org> <54A2E6B6.5020903@yandex.ru> <837fx9augp.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Helmut Eller > Cc: Dmitry Gutov , monnier@iro.umontreal.ca, 19468@debbugs.gnu.org > Date: Tue, 30 Dec 2014 19:01:55 +0100 > > On Tue, Dec 30 2014, Eli Zaretskii wrote: > > > Why cannot the command jump to the first result, after it shows the > > list? > > Because then you have a window that needs to be closed. Sorry, I don't understand: what window needs to be closed? What I meant is to do automatically what moving to the first candidate does. It doesn't close any windows, AFAICS, it just displays the definition in the upper window, leaving the list in the lower one. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Helmut Eller Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 18:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141996361419747 (code B ref 19468); Tue, 30 Dec 2014 18:21:01 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 18:20:14 +0000 Received: from localhost ([127.0.0.1]:33091 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61Ov-00058Q-Mv for submit@debbugs.gnu.org; Tue, 30 Dec 2014 13:20:13 -0500 Received: from mail-we0-f174.google.com ([74.125.82.174]:38387) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61Ot-00058I-Sc for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 13:20:12 -0500 Received: by mail-we0-f174.google.com with SMTP id k48so1389964wev.19 for <19468@debbugs.gnu.org>; Tue, 30 Dec 2014 10:20:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=zGg9OowRomvsxdTMJxo0h0nnkUTN4Q72WjdtO6o0D5Q=; b=Wdx8fi8neHKl56Zd2gmLS1E5bImAwkOzAqGBWxM50TbYRFAq6lyz+7or4d2c/B3s2l xu7gidKgiDl19TmBEd4SFqbxi+3NrYPaAJjNGIE03reXls8L1Qmj45ZCWtS0F0BouROz JWVrgI5iRGOc7oOWTxv7Ui8S1HWOg47RWqQDGSVt9uLCx7IcwaryByeydFD/qksNoFm8 srGOHrD3uPTVFiNdZYRraEEAVu8BFiKMSahvk8wVQMJg4gwVTb/aY3bceo5a/zH4gati BxANhJmucpZVF3pOpoCZktNyOyxVcQhSQKSGZOchbu4JfNRrND9sRZSm5reDoHxH9Qkq /qFA== X-Received: by 10.194.6.70 with SMTP id y6mr106330599wjy.97.1419963611399; Tue, 30 Dec 2014 10:20:11 -0800 (PST) Received: from ix ([212.46.172.21]) by mx.google.com with ESMTPSA id eu8sm44269591wib.21.2014.12.30.10.20.10 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 30 Dec 2014 10:20:10 -0800 (PST) Received: from helmut by ix with local (Exim 4.80) (envelope-from ) id 1Y61Or-0001P9-FC; Tue, 30 Dec 2014 19:20:10 +0100 From: Helmut Eller References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <83bnmlavd2.fsf@gnu.org> <54A2E6B6.5020903@yandex.ru> <837fx9augp.fsf@gnu.org> <834msdatul.fsf@gnu.org> Date: Tue, 30 Dec 2014 19:20:09 +0100 In-Reply-To: <834msdatul.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 30 Dec 2014 20:13:54 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Tue, Dec 30 2014, Eli Zaretskii wrote: >> On Tue, Dec 30 2014, Eli Zaretskii wrote: >> >> > Why cannot the command jump to the first result, after it shows the >> > list? >> >> Because then you have a window that needs to be closed. > > Sorry, I don't understand: what window needs to be closed? The window that displays the *xref* buffer. > What I meant is to do automatically what moving to the first candidate > does. It doesn't close any windows, AFAICS, it just displays the > definition in the upper window, leaving the list in the lower one. If you press RET in *xref* buffer it closes the *xref* window. Helmut From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 18:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Helmut Eller Cc: 19468@debbugs.gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141996407620531 (code B ref 19468); Tue, 30 Dec 2014 18:28:02 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 18:27:56 +0000 Received: from localhost ([127.0.0.1]:33099 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61WN-0005L4-QG for submit@debbugs.gnu.org; Tue, 30 Dec 2014 13:27:55 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:41269) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61WM-0005Kw-4I for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 13:27:55 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NHE00900QWHVU00@a-mtaout22.012.net.il> for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 20:27:52 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHE0095XRAGV720@a-mtaout22.012.net.il>; Tue, 30 Dec 2014 20:27:52 +0200 (IST) Date: Tue, 30 Dec 2014 20:27:42 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83387xat7l.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <83bnmlavd2.fsf@gnu.org> <54A2E6B6.5020903@yandex.ru> <837fx9augp.fsf@gnu.org> <834msdatul.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Helmut Eller > Cc: dgutov@yandex.ru, monnier@iro.umontreal.ca, 19468@debbugs.gnu.org > Date: Tue, 30 Dec 2014 19:20:09 +0100 > > > What I meant is to do automatically what moving to the first candidate > > does. It doesn't close any windows, AFAICS, it just displays the > > definition in the upper window, leaving the list in the lower one. > > If you press RET in *xref* buffer it closes the *xref* window. I meant to simulate the '.' key, not the RET key. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Helmut Eller Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 18:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141996439321110 (code B ref 19468); Tue, 30 Dec 2014 18:34:02 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 18:33:13 +0000 Received: from localhost ([127.0.0.1]:33103 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61bU-0005UQ-H4 for submit@debbugs.gnu.org; Tue, 30 Dec 2014 13:33:12 -0500 Received: from mail-wg0-f46.google.com ([74.125.82.46]:35386) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61bR-0005UG-Gu for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 13:33:09 -0500 Received: by mail-wg0-f46.google.com with SMTP id x13so21216221wgg.33 for <19468@debbugs.gnu.org>; Tue, 30 Dec 2014 10:33:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=suXH1CFX85Y/nF2gSltr/w66uy0upL3GDa1xVZfeIhU=; b=KCjrDrN/9mo2S3r2rRUbE3hd/fSNmq1J7fDIRWmavhQ2TTLhEdNA/s/59c6xQ6EvHg 60NQxmDs7ttiBqGvZxbyiwSwbEsWvZwmXrVM4RYuoje3GyNsHKq8/1nXoH/oomzunv17 3MTV2QLZ2N62RqPX5IVVfUHuCs5slarprpiRwqUC13n7YRJs2cj6X+7LL5k4k7H75EG/ 1SK6V+lZle7/xNc1QzW9CDMk7QnEA5aJeEFfVkdlEdW9gfL79EtACC8rTB+59jPYOiO/ N2FZoEpuhNNGyI9THs4sQ2yGEeiRqI0UIReJJyvQnwEI9Hei6GmMX/IfRUWwE2KEsasv PCpA== X-Received: by 10.194.92.116 with SMTP id cl20mr125984987wjb.71.1419964388978; Tue, 30 Dec 2014 10:33:08 -0800 (PST) Received: from ix ([212.46.172.21]) by mx.google.com with ESMTPSA id gb10sm29578892wjb.21.2014.12.30.10.33.07 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 30 Dec 2014 10:33:08 -0800 (PST) Received: from helmut by ix with local (Exim 4.80) (envelope-from ) id 1Y61bP-0001PN-9i; Tue, 30 Dec 2014 19:33:07 +0100 From: Helmut Eller References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <83bnmlavd2.fsf@gnu.org> <54A2E6B6.5020903@yandex.ru> <837fx9augp.fsf@gnu.org> <834msdatul.fsf@gnu.org> <83387xat7l.fsf@gnu.org> Date: Tue, 30 Dec 2014 19:33:07 +0100 In-Reply-To: <83387xat7l.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 30 Dec 2014 20:27:42 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Tue, Dec 30 2014, Eli Zaretskii wrote: >> > What I meant is to do automatically what moving to the first candidate >> > does. It doesn't close any windows, AFAICS, it just displays the >> > definition in the upper window, leaving the list in the lower one. >> >> If you press RET in *xref* buffer it closes the *xref* window. > > I meant to simulate the '.' key, not the RET key. Then this question was already answered 3 times and here's the fourth time: it would display two buffers at the same time which is confusing and I had implemented that already and I didn't like it. Helmut From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 18:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Helmut Eller Cc: monnier@iro.umontreal.ca, 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141996442121157 (code B ref 19468); Tue, 30 Dec 2014 18:34:02 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 18:33:41 +0000 Received: from localhost ([127.0.0.1]:33106 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61bx-0005V9-4C for submit@debbugs.gnu.org; Tue, 30 Dec 2014 13:33:41 -0500 Received: from mail-wi0-f181.google.com ([209.85.212.181]:39779) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61bv-0005V1-C0 for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 13:33:39 -0500 Received: by mail-wi0-f181.google.com with SMTP id r20so24502737wiv.14 for <19468@debbugs.gnu.org>; Tue, 30 Dec 2014 10:33:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WKdksxvHeRSveGk7i/K1MH1BcfXdPnWWXj5plNvs7Eo=; b=RCQH6jSvK1g6cHKKiymx7dxjpQg/+qKjZssSl1LlGSxwqZKwa6330UJQfVb471jq2N 4UY4MnjxBmr5/jN0d/z5xbR8X9Tzn93bzXtQSA1jFmjjdmx/lgdPHM8s+8za7oBY7X/B ZHTRD6QyJ65Rgvs6ldfCs42NtjHUuZ+wUuBPkMsE1zMJndcLa3/nVTNsYP4xq68yw7k8 OK2+C5c/t0GXhGC1p9rrdcbJVX8nspF0szTOfJQHhCT265veGBJijLEcs+A7V/a+0Cye i9iIQcEBoPh9BSOMXV9dIDoaHoF3uxRTVcb2cr2owotipGsnon3iFpsnWbRViLLmgWLN /FTA== X-Received: by 10.180.81.169 with SMTP id b9mr109378820wiy.41.1419964418858; Tue, 30 Dec 2014 10:33:38 -0800 (PST) Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id cs8sm44343572wib.1.2014.12.30.10.33.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Dec 2014 10:33:38 -0800 (PST) Message-ID: <54A2F000.3020508@yandex.ru> Date: Tue, 30 Dec 2014 20:33:36 +0200 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <83bnmlavd2.fsf@gnu.org> <54A2E6B6.5020903@yandex.ru> <837fx9augp.fsf@gnu.org> <834msdatul.fsf@gnu.org> <83387xat7l.fsf@gnu.org> In-Reply-To: <83387xat7l.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 12/30/2014 08:27 PM, Eli Zaretskii wrote: >> If you press RET in *xref* buffer it closes the *xref* window. > > I meant to simulate the '.' key, not the RET key. You should try this: (advice-add 'xref--show-xref-buffer :after (lambda (&rest r) (run-with-idle-timer 0 nil #'xref-next-line))) Before adding the user option, I'd like to see at least one other person say that they'll use it. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 18:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Helmut Eller Cc: 19468@debbugs.gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141996475221724 (code B ref 19468); Tue, 30 Dec 2014 18:40:02 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 18:39:12 +0000 Received: from localhost ([127.0.0.1]:33119 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61hH-0005eJ-RX for submit@debbugs.gnu.org; Tue, 30 Dec 2014 13:39:12 -0500 Received: from mtaout26.012.net.il ([80.179.55.182]:52664) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61hG-0005eA-23 for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 13:39:11 -0500 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NHE00700RO2BD00@mtaout26.012.net.il> for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 20:38:34 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHE00MYARSAES90@mtaout26.012.net.il>; Tue, 30 Dec 2014 20:38:34 +0200 (IST) Date: Tue, 30 Dec 2014 20:38:59 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83zja59e4c.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <83bnmlavd2.fsf@gnu.org> <54A2E6B6.5020903@yandex.ru> <837fx9augp.fsf@gnu.org> <834msdatul.fsf@gnu.org> <83387xat7l.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Helmut Eller > Cc: dgutov@yandex.ru, monnier@iro.umontreal.ca, 19468@debbugs.gnu.org > Date: Tue, 30 Dec 2014 19:33:07 +0100 > > On Tue, Dec 30 2014, Eli Zaretskii wrote: > > >> > What I meant is to do automatically what moving to the first candidate > >> > does. It doesn't close any windows, AFAICS, it just displays the > >> > definition in the upper window, leaving the list in the lower one. > >> > >> If you press RET in *xref* buffer it closes the *xref* window. > > > > I meant to simulate the '.' key, not the RET key. > > Then this question was already answered 3 times and here's the fourth > time: it would display two buffers at the same time which is confusing > and I had implemented that already and I didn't like it. I'm not asking you to like it. I'm asking to provide a user option to get this behavior, for those who might like it. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Helmut Eller Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 18:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141996563323179 (code B ref 19468); Tue, 30 Dec 2014 18:54:01 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 18:53:53 +0000 Received: from localhost ([127.0.0.1]:33123 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61vV-00061n-Fy for submit@debbugs.gnu.org; Tue, 30 Dec 2014 13:53:53 -0500 Received: from mail-wi0-f179.google.com ([209.85.212.179]:61859) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61vT-00061f-JY for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 13:53:52 -0500 Received: by mail-wi0-f179.google.com with SMTP id ex7so24526672wid.12 for <19468@debbugs.gnu.org>; Tue, 30 Dec 2014 10:53:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=Q+1sb7C0Niof/xsKOiqBOXlFPjnFkTj2GJUOj9u3d9I=; b=uHsRebiwhCFbW2OKygj4lfcnLelsJPNF83wpSZcbHDGn14ZKLDiyRxaV4X1gYy5UZQ BrgYoZTKdN9u5Ux+ZG9hltSPMAL9NDdQinfyvljBm8sKsFjG+Wc23ra51+JVu6EsMAss LPU4AaqGnJnnyrmWzsKFZLCE8/KNSIydITcGYock3KDsGJxC0x9XVJ9k2Jc9B8z/H9j/ 1rA31XyHXVQf+cqnDp4rWG2aTKzh+X9IO9SUaSXWgnTsqCYoICeP6xnSOjw1p9mvi4Hm 4bqzlB1ZuRtzxJ2Rz5Hp0tLHNO6pVolBYjWwOSCKM320siWl06YCCu+qt6QxdWiD1VLs jssA== X-Received: by 10.194.235.226 with SMTP id up2mr112448293wjc.9.1419965631044; Tue, 30 Dec 2014 10:53:51 -0800 (PST) Received: from ix ([212.46.172.21]) by mx.google.com with ESMTPSA id a14sm44359595wib.22.2014.12.30.10.53.49 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 30 Dec 2014 10:53:50 -0800 (PST) Received: from helmut by ix with local (Exim 4.80) (envelope-from ) id 1Y61vR-0001Pp-Cr; Tue, 30 Dec 2014 19:53:49 +0100 From: Helmut Eller References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <83bnmlavd2.fsf@gnu.org> <54A2E6B6.5020903@yandex.ru> <837fx9augp.fsf@gnu.org> <834msdatul.fsf@gnu.org> <83387xat7l.fsf@gnu.org> <83zja59e4c.fsf@gnu.org> Date: Tue, 30 Dec 2014 19:53:49 +0100 In-Reply-To: <83zja59e4c.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 30 Dec 2014 20:38:59 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Tue, Dec 30 2014, Eli Zaretskii wrote: > I'm not asking you to like it. I'm asking to provide a user option to > get this behavior, for those who might like it. Yay, more customization variables is what we need. Helmut From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 19:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Helmut Eller Cc: 19468@debbugs.gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141996800032207 (code B ref 19468); Tue, 30 Dec 2014 19:34:01 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 19:33:20 +0000 Received: from localhost ([127.0.0.1]:33144 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y62Xg-0008NP-Gu for submit@debbugs.gnu.org; Tue, 30 Dec 2014 14:33:20 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:49544) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y62Xc-0008NC-LQ for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 14:33:18 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NHE00300U612Y00@a-mtaout21.012.net.il> for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 21:33:14 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHE002THUBEV580@a-mtaout21.012.net.il>; Tue, 30 Dec 2014 21:33:14 +0200 (IST) Date: Tue, 30 Dec 2014 21:33:05 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83tx0d9bm6.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <83bnmlavd2.fsf@gnu.org> <54A2E6B6.5020903@yandex.ru> <837fx9augp.fsf@gnu.org> <834msdatul.fsf@gnu.org> <83387xat7l.fsf@gnu.org> <83zja59e4c.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Helmut Eller > Cc: dgutov@yandex.ru, monnier@iro.umontreal.ca, 19468@debbugs.gnu.org > Date: Tue, 30 Dec 2014 19:53:49 +0100 > > On Tue, Dec 30 2014, Eli Zaretskii wrote: > > > I'm not asking you to like it. I'm asking to provide a user option to > > get this behavior, for those who might like it. > > Yay, more customization variables is what we need. You can add the behavior I asked for unconditionally, without adding an option. I won't mind. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 19:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Helmut Eller , Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.1419968334395 (code B ref 19468); Tue, 30 Dec 2014 19:39:02 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 19:38:54 +0000 Received: from localhost ([127.0.0.1]:33148 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y62d4-00006H-73 for submit@debbugs.gnu.org; Tue, 30 Dec 2014 14:38:54 -0500 Received: from mail-wi0-f171.google.com ([209.85.212.171]:55962) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y62d0-000062-NT for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 14:38:51 -0500 Received: by mail-wi0-f171.google.com with SMTP id bs8so24512102wib.16 for <19468@debbugs.gnu.org>; Tue, 30 Dec 2014 11:38:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7V1XXM24QULXUNX56OedrneH0h4IAjoSBiQKXP2yhRg=; b=oFE0/Fbk9/yEYnQ3iAHtkNBhy6bpnXw3Na3dgH4RT86sKYwT85aHxlbyXcOSajzwyr KW2YP4ZB5iQnBIcraoB1SZyyT0ZfB8Zw2nZGbgUBUt5zZICanIRS7bVjL7HCLMzKnUPy 6vNqBmpwZT2pn1t33r8Vrkxdb3QXtvS+oLTFMwScH1pGfz69/zcG629x3CBWlUvcX/In nlLZRBPU0lQOZ9lFozkX0rjgEpQclGke3Hhqr38C+y42bQzmkrRxiH1li8YEEiob8gbu stWN92Y8CTVta3ShG91ePSRneKF96p6vUZyoefSj5lGvszzSTzr2F+gy5Qcf6uhOyYBQ Ygrw== X-Received: by 10.180.13.7 with SMTP id d7mr110757896wic.57.1419968329961; Tue, 30 Dec 2014 11:38:49 -0800 (PST) Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id gl5sm47630223wib.0.2014.12.30.11.38.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Dec 2014 11:38:49 -0800 (PST) Message-ID: <54A2FF47.6010207@yandex.ru> Date: Tue, 30 Dec 2014 21:38:47 +0200 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 12/30/2014 10:19 AM, Helmut Eller wrote: > For me, opening the file the first time is a bit slow, but after that > moving up and down is instantaneous. Same here. > I didn't implement that. It's because of the save-window-excursion in > xref--next-line that Dmitry added. In my proposal the other window > didn't change when the cursor didn't move. This is a possibly hacky execution of the following idea: I can move up and down the lines and see their buffers displayed, but if I haven't pressed RET, I should be able to press `q' and the window configuration should return to just the way it was before `xref-find-definitions' was called. But not if the user modifier the window configuration in other ways, while *xref* buffer was open, or if the user switches to an existing *xref* buffer again after burying it. Suggestions for a better implementation are welcome. Should we mess around with `window-configuration-change-hook'? From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 19:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Helmut Eller Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14199693872159 (code B ref 19468); Tue, 30 Dec 2014 19:57:02 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 19:56:27 +0000 Received: from localhost ([127.0.0.1]:33158 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y62u3-0000Yk-9c for submit@debbugs.gnu.org; Tue, 30 Dec 2014 14:56:27 -0500 Received: from mail-wg0-f49.google.com ([74.125.82.49]:65168) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y62u1-0000Ya-NI for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 14:56:26 -0500 Received: by mail-wg0-f49.google.com with SMTP id n12so20989165wgh.8 for <19468@debbugs.gnu.org>; Tue, 30 Dec 2014 11:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=W5Icm4jD0kntwYp0/yC4IBa8HpcUADaRpeSmP10a09Y=; b=vioMWYiowwXfmeL04HfwcZ3AoceduLzYm5A8GpcWBeXnqldM2LDLkqX/2gHLgOwkBb e0r4hxPJp3c7w+jcbG2x25J0OlmFMeUkx59sT5ZXhmIdAQnG+YptwNkWaliLVFi5UPSi 8yWNZT45mMdWMuVlPApIUb4FgyWR7qqrCmeHAbSTDu8rF3kFYMwaB3ORTI6Tb8Qgjh8J A3G6nK+mMpymWO6G6PkQsnrg5g++dCYrl4gRWp5X9cwD5dLVzd40FS5KNw1/uvjJVajV 3w+UrduEgSiThTKmk5gnudO2Ru/ARATPZKBiPFhLq3AnGIl1EcwXQRwI66Qh4vBECHP4 sG8w== X-Received: by 10.180.107.70 with SMTP id ha6mr9310032wib.71.1419969384905; Tue, 30 Dec 2014 11:56:24 -0800 (PST) Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id l6sm14853703wjx.33.2014.12.30.11.56.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Dec 2014 11:56:24 -0800 (PST) Message-ID: <54A30366.2010508@yandex.ru> Date: Tue, 30 Dec 2014 21:56:22 +0200 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <83oaqlb013.fsf@gnu.org> In-Reply-To: <83oaqlb013.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 12/30/2014 06:00 PM, Eli Zaretskii wrote: >> Trial and error isn't the worst way to learn things; at least if it >> doesn't take too long. > > Turns out I missed '.' and ',', though. So trial and error are > evidently less efficient than we would want. I guess this will be in the manual, which I'd be happy not to have to write at all, and probably won't write until the 25 feature freeze. There's probably nothing to discuss about this further. >> Apparently you didn't even need to read any documentation > > What documentation? Any documentation. :) > (Btw, it > doesn't even say that if no identifier is found at point, it will > prompt even without an argument.) It does now, thanks. >> That's as expected. There is nothing to select on the first line. > > Then why let me position point there? Because then you're ideally positioned to press `.' and see the buffer of the first match displayed. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 20:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: eller.helmut@gmail.com, 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14199711965501 (code B ref 19468); Tue, 30 Dec 2014 20:27:02 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 20:26:36 +0000 Received: from localhost ([127.0.0.1]:33172 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y63NC-0001Qe-Ti for submit@debbugs.gnu.org; Tue, 30 Dec 2014 15:26:35 -0500 Received: from mail-we0-f173.google.com ([74.125.82.173]:55395) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y63NA-0001QU-JW for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 15:26:33 -0500 Received: by mail-we0-f173.google.com with SMTP id q58so1536637wes.32 for <19468@debbugs.gnu.org>; Tue, 30 Dec 2014 12:26:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2Q0jyc49WxMGUsmzWglltEBXm1u0Kt23No0rCV6nNeA=; b=MHuhPEwHfwHy+3Uo/eRYM5i/WVVc/fKnTN0op9w4Roufq4K5/gSUXpbF7g6aGzT/mz OjaQO0UIPeP/0ceQQnYAxJVwEWbgRwsSwI9t7bqQ4P4ESJIOTNi0WKAtZC2NAtMujjDv VbUKi/rfXu18W4EwlywFaiinOLSwehSMF4aAqCh8n6cAKkRnGomBfIYeuWlUEGB4fGug mxZ874j86aqNJQArZns+t+7o1j89LtUrraKXre9u6TAoKJLz+JhW/9seJxdx10IFhLER 8C12WMM7R2t43kmVuhC7djL3/pwk6NGPu/XeseOYI32HizwQm2FSsfY8HO+ZjzRs7Hq2 9tSw== X-Received: by 10.181.29.170 with SMTP id jx10mr95638337wid.50.1419971192071; Tue, 30 Dec 2014 12:26:32 -0800 (PST) Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id dp8sm44614127wib.20.2014.12.30.12.26.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Dec 2014 12:26:31 -0800 (PST) Message-ID: <54A30A75.3090909@yandex.ru> Date: Tue, 30 Dec 2014 22:26:29 +0200 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <83tx0db0x5.fsf@gnu.org> In-Reply-To: <83tx0db0x5.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 12/30/2014 05:41 PM, Eli Zaretskii wrote: > Sorry, I don't follow. I started that from a single window, and > M-. already did split it into 2, and displayed the candidates in the > lower one. So I already see 2 buffers, and showing the first > candidate in the upper window doesn't do anything I won't expect -- > after all, I did ask to see something different from what I was > already seeing. Changing buffer in two windows at once, like Helmut said, is a more radical change, more likely to confuse the user. And you lose more context. In the example of ELisp, you could instead glance at the original buffer, see that you've jumped from a function call (so you need a function), and then simply choose the `defun' among the options, without even looking at its buffer. >> And it seems inconsistent with your further complaint that movement visits files automatically (if it shouldn't, it shouldn't start with displaying the buffer at point either). > > I see no inconsistency: we could display the first candidate > automatically, but not switch to others without the user's say-so. Inconsistency would be this: you either automatically display the buffer of the candidate at point or not. You're asking to do it differently in quite similar contexts. > Imagine a situation where the list of possible candidates is very > long, longer than what the window shows. Then the user might wish to > scroll the list of candidates before she makes up her mind about the > one she wants to see. But moving point visits the candidates, which > is not what the user asked for in this use case. I would use C-s for that, or indeed C-v/M-v. > Moreover, I see that scrolling the window by C-v/PageDn does _not_ > visit the tags at point, while scrolling by up- and down- arrow key > does. Looks like another confusing inconsistency. This would be quite easy to solve, if displaying the tag at point after any movement command is indeed what we want to do. > So I suggest that the automatic visiting will be at least > customizable, if not switched off by default. Here's a possible compromise: only do that automatically for `.' and `,', as well as provide a manual command (say, bound to C-o). Speaking of the latter, do you see the value in undoing the window configuration change before the next command? We could expand this behavior to other `-display-' commands with the same binding. >> Would you like it to be called the same as the current command? *xref-find-definitions-other-window*, *xref-find-apropos*, etc? > > How about "*find-function-candidates*" or even "*Completions*"? `find-function-candidates' doesn't match the command name, nor would it be the same for different commands in the xref package. Inconvenient, from the implementation's standpoint. *Completions* is bad, because we're not completing text input. >> One might argue that using the mouse is also un-Emacsy. > > That ship sailed a long time ago. Guess so. >> But sure, that shouldn't be hard to add (and would increase discoverability). > > More importantly, it will tell the user what she needs to do, even if > she doesn't use the mouse, because mouse-sensitive portions of Emacs > display generally behave very similarly. If she doesn't use the mouse, how will she know the mouse-sensitive portions? >> Or with `.' and `,', which are a bit easier to press right after `M-.'. > > It would be nice to have some instructions to this effect. I don't think having the instructions inside the buffer would be good. Unlike `report-emacs-bug', it can be used very frequently, and seeing the same simple instructions you already know is annoying. > Once again, this is not a UI that is used in other places in Emacs, it > is very different. So you shouldn't assume that its keybindings are > known by users, especially keybindings such as '.' and ',' that are > not widely used in other programs, and therefore must be learned anew. Should we expand it to other places in Emacs? Suggestions welcome. >> This can be made configurable, though. For instance, `C-o' could be that "other gesture". Would you prefer the window configuration restored before point moves to a different line, or should the new buffer keep being displayed? The latter presents a challenge if we want `q' in the xref buffer to restore the original window configuration before xref-find-definitions was invoked, as long as the user hadn't made any manual changes thereafter. > > Why is it a challenge? Typing 'q' and 'C-o' can invoke different > functions, can't it? I'm probably missing something. The challenge is to preserve the window configuration, albeit only when it makes sense. > No, I prefer that the lines that show file names be not reachable at > all. They are just clutter, as far as moving point is concerned. Let > point jump over them. If the point is at the first reference already, and we've configured xref not to display its buffer automatically, the user will have to reach for `C-o' instead of `.', to have it displayed. >> Finally, invoking the same command from the menu bar ought to present >> a dialog box with the candidates, according to the general rule: if a >> command was invoked by a mouse gesture, selection of candidates is via >> a GUI dialog, not a special-purpose buffer. But that doesn't happen. >> >> Example? > > Click File->Quit when you have unsaved edits. Apparently, this is easier to implement using the native dialogs. How would you create a replacement for the *xref* buffer, without losing the grouping or ./, functionality? > But this is not completion, this is a list of completion results. > Completion happens _before_ the *xref* buffer is popped up. Or am I > missing something? I've just misunderstood. "Selection of candidates" makes me think of completion. >> As a counterpoint, Buffers->Select Named Buffer... uses the minibuffer. > > That _is_ completion. I'm not talking about prompting the user for a > symbol, I'm talking about _displaying_ the matching symbols once the > user has typed her input. Well, how about Buffers->List All Buffers, then? > I'm sorry I didn't participate. The reason is that I never understood > this is meant as a replacement for find-tag etc., until you asked > whether to remove them from the menu bar. The discussion was long > enough and focused on technicalities enough to turn me off. The intention to replace find-tag came naturally later. Either way, maybe it's good that you didn't get into technicalities then, and evaluate this now purely on the basis of behavior. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Helmut Eller Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 22:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Eli Zaretskii , 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141998030319978 (code B ref 19468); Tue, 30 Dec 2014 22:59:01 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 22:58:23 +0000 Received: from localhost ([127.0.0.1]:33216 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y65k6-0005CA-JJ for submit@debbugs.gnu.org; Tue, 30 Dec 2014 17:58:22 -0500 Received: from mail-wg0-f42.google.com ([74.125.82.42]:41860) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y65k4-0005C0-Hq for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 17:58:21 -0500 Received: by mail-wg0-f42.google.com with SMTP id k14so21503012wgh.15 for <19468@debbugs.gnu.org>; Tue, 30 Dec 2014 14:58:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=KfVghU96Qm6gGUYAuptZUvwm8a8F9FY127Qh55jDd8Y=; b=DrHhdwvNDS0ds+Z1uvP3fxTkgZP/xdpPjuq1xpPiC/9oGbOccEuoLyvIwHhnlelCdv BgFRunf9ZXq8zt6U0J/CrwdtCaJZvuUg+/nXmXQ0ao/2+CwznepA7tDvmXcdB7J4/FBU O0FNgsf1iAg+VwWp6tBZhKZuB28N1TdGx9WUg9OqX4g/RhhO/K4qNapZhvbPWleecK4I whUPxDX9C5R2KqEV+uIxdFCp9hgSyt+lJY8uJE8wHwYTe1V4+L2b6A/W6MCNs5HNmhF6 8dpp2woePjpIDoMBqxvAO4uca/NQOb6up08mWXDJkGh50oCWgsRfuXyq+qVHTR/o1SN1 dE+Q== X-Received: by 10.194.78.229 with SMTP id e5mr78512171wjx.11.1419980299531; Tue, 30 Dec 2014 14:58:19 -0800 (PST) Received: from ix ([212.46.172.21]) by mx.google.com with ESMTPSA id gb10sm30259708wjb.21.2014.12.30.14.58.18 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 30 Dec 2014 14:58:18 -0800 (PST) Received: from helmut by ix with local (Exim 4.80) (envelope-from ) id 1Y65k2-0001Uc-2r; Tue, 30 Dec 2014 23:58:18 +0100 From: Helmut Eller References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> Date: Tue, 30 Dec 2014 23:58:18 +0100 In-Reply-To: <54A2FF47.6010207@yandex.ru> (Dmitry Gutov's message of "Tue, 30 Dec 2014 21:38:47 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Tue, Dec 30 2014, Dmitry Gutov wrote: > Suggestions for a better implementation are welcome. Should we mess > around with `window-configuration-change-hook'? My suggestion would be to stay away from window management as much as you can because it's very difficult to get it right. q followed by M-, usually brings back the original window configuration. Based on that, maybe q should combine quit-window and xref-pop-marker-stack (preferably recognizing whether q was pressed multiple times). Helmut From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 Jan 2015 21:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Helmut Eller Cc: Eli Zaretskii , 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14203210841772 (code B ref 19468); Sat, 03 Jan 2015 21:39:02 +0000 Received: (at 19468) by debbugs.gnu.org; 3 Jan 2015 21:38:04 +0000 Received: from localhost ([127.0.0.1]:35854 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y7WOZ-0000SR-IA for submit@debbugs.gnu.org; Sat, 03 Jan 2015 16:38:03 -0500 Received: from mail-la0-f45.google.com ([209.85.215.45]:40343) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y7WOW-0000S4-0R for 19468@debbugs.gnu.org; Sat, 03 Jan 2015 16:38:00 -0500 Received: by mail-la0-f45.google.com with SMTP id gq15so16739905lab.32 for <19468@debbugs.gnu.org>; Sat, 03 Jan 2015 13:37:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=63GmsANbhhEV1x7H39BzfapYfpl8sWjtMohMQK8DEnk=; b=rwTzIVonKplASwjh+IsPgncR6ZKCH+h9+GPaV5PA2sui2DlIGVyBZ8vIQ3io1z69Z8 QmeH4EDGnSnPMJbrmajoszcWBYOmT5HuF9GJNxTQobHX4FglkJufg3QtH1AEakyoDXBf ncS/qbdNN55dX4ybDjCGUTXHQoeEaFt4DwIXackcdj6HX+1ZgeA64khBp5NHJ3bPMcax x8nKrB5B48PoaIBOnCWSB2zK//pJO5Aqa9ne8CZoa6exJrbAk0WuTGvALpIIYVP/x63s MzZRVhBh4esBdi4S9Fxw6FGr7LL/redbXqLjouNBwKftYc+Rg5QdqsfN9zZuS//VsjP7 oI1A== X-Received: by 10.152.6.8 with SMTP id w8mr84889547law.41.1420321079132; Sat, 03 Jan 2015 13:37:59 -0800 (PST) Received: from [192.168.1.3] ([178.252.98.87]) by mx.google.com with ESMTPSA id i5sm6659079lbh.47.2015.01.03.13.37.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Jan 2015 13:37:58 -0800 (PST) Message-ID: <54A86135.7080004@yandex.ru> Date: Sat, 03 Jan 2015 23:37:57 +0200 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 12/31/2014 12:58 AM, Helmut Eller wrote: > My suggestion would be to stay away from window management as much as you > can because it's very difficult to get it right. I agree it can be a minefield, so if anyone sees a case that's particularly difficult to handle this way, please let me know. > q followed by M-, usually brings back the original window configuration. Only it doesn't exactly work that way if there are more than two windows, because we open the xrefs' buffers in the "other window" in reference to the *xrefs* window, and that's not the original window. We could try to always use the original window for that, but that would be more limiting (why not use different windows, if they are available?). If someone really dislikes the current behavior, we can go that way, but for now I've installed some of the already mentioned minor tweaks (5496236583e22bce185650988a1ae675216e883e). From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Jan 2015 08:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov , Helmut Eller Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.142036174616356 (code B ref 19468); Sun, 04 Jan 2015 08:56:02 +0000 Received: (at 19468) by debbugs.gnu.org; 4 Jan 2015 08:55:46 +0000 Received: from localhost ([127.0.0.1]:35958 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y7gyQ-0004Fj-3D for submit@debbugs.gnu.org; Sun, 04 Jan 2015 03:55:46 -0500 Received: from mout.gmx.net ([212.227.17.22]:49896) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y7gyN-0004FT-QQ for 19468@debbugs.gnu.org; Sun, 04 Jan 2015 03:55:44 -0500 Received: from [88.117.57.210] ([88.117.57.210]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Metpl-1YRJOG3KwL-00Obka; Sun, 04 Jan 2015 09:55:41 +0100 Message-ID: <54A90002.7080009@gmx.at> Date: Sun, 04 Jan 2015 09:55:30 +0100 From: martin rudalics MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> In-Reply-To: <54A86135.7080004@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:kDksUvPHNn2BPpfOOZds/7FhKaIDSJjq1cDtWc5GhbzF+j9q1Cp oRhjqhJmjQu1YmMJ3KkQ6XFIqM1s3CF7V5OGswD0gN/cH+0mdJhDT9UlcFwPvVSjeYgvZ5J SAxPqoTBw4fra317Kh7ST8RH53kcGSzIgiJXbtJ0LJ5QNP7IxT66hIb6hWPmQ6l2G6r7zQn X8fjNaw+Di4ktqZcpdrvQ== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> My suggestion would be to stay away from window management as much as you >> can because it's very difficult to get it right. > > I agree it can be a minefield, so if anyone sees a case that's particularly difficult to handle this way, please let me know. > >> q followed by M-, usually brings back the original window configuration. If and only if the selected window is the only window that changed. The idea of `quit-window' is to undo only changes made for this particular window. It should _never_ undo changes made to the rest of the window configuration. > Only it doesn't exactly work that way if there are more than two windows, because we open the xrefs' buffers in the "other window" in reference to the *xrefs* window, and that's not the original window. You could try to bind "q" to a function that invokes `quit-window' for both windows (preferably in inverse order of how they were made). martin From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Jan 2015 22:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics , Helmut Eller Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.142041190710587 (code B ref 19468); Sun, 04 Jan 2015 22:52:01 +0000 Received: (at 19468) by debbugs.gnu.org; 4 Jan 2015 22:51:47 +0000 Received: from localhost ([127.0.0.1]:36747 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y7u1T-0002kg-6U for submit@debbugs.gnu.org; Sun, 04 Jan 2015 17:51:47 -0500 Received: from mail-la0-f48.google.com ([209.85.215.48]:47762) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y7u1Q-0002kW-U8 for 19468@debbugs.gnu.org; Sun, 04 Jan 2015 17:51:45 -0500 Received: by mail-la0-f48.google.com with SMTP id gf13so16982674lab.7 for <19468@debbugs.gnu.org>; Sun, 04 Jan 2015 14:51:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=zUYEIibyns54bOivUg6gSNhDS/5GHXjkZQVvZaRZzXA=; b=mKoVgqoifbc/09A1gn4tyrtbOmDkGqFqDl+7QrWG5mhhM+EFKcHuQyoSyazMyfufSg 5P3Vx7DAH4BTvc7Z8Xx5YzAyVpkNmeFXytxBXZz3Z4aWt2BislL/Ak/06YhwIMoKmvIl fetSt6oV9PVTUeWITuggcG4buEmmm7hfq76RtCuVkS3+hZFp/Z1VpEvTE5APqcIOfFK7 K5tN7IOA8T3FLPTFR2Qog2WnR/AuDFMKVG8DZujwSW38KmdXgfDNUbK94FSfHgakLWfg y842VzE5bBa6saqpugYj7atQbPwBqujsqYL/91OoXiKbJfW+04DdczmiQivhHzmsWcXH SlFw== X-Received: by 10.152.27.8 with SMTP id p8mr89853612lag.69.1420411904078; Sun, 04 Jan 2015 14:51:44 -0800 (PST) Received: from [192.168.1.3] ([178.252.98.87]) by mx.google.com with ESMTPSA id i5sm7331181lbh.47.2015.01.04.14.51.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jan 2015 14:51:43 -0800 (PST) Message-ID: <54A9C3FB.7000602@yandex.ru> Date: Mon, 05 Jan 2015 01:51:39 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> In-Reply-To: <54A90002.7080009@gmx.at> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 01/04/2015 11:55 AM, martin rudalics wrote: > You could try to bind "q" to a function that invokes `quit-window' for > both windows (preferably in inverse order of how they were made). In all likelihood, we've displayed several buffers in succession in that other window. Or none. Doing `quit-window' there exactly once won't suffice. So I guess this amounts to keeping a buffer-window history of everything that was opened from *xrefs*, and on `q', iterate through that list and, if the given window displays the given buffer, `quit-buffer' on it. Then clear the history and quit *xrefs*. I kinda like that. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Jan 2015 23:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: eller.helmut@gmail.com, 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.142041557716689 (code B ref 19468); Sun, 04 Jan 2015 23:53:01 +0000 Received: (at 19468) by debbugs.gnu.org; 4 Jan 2015 23:52:57 +0000 Received: from localhost ([127.0.0.1]:36781 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y7uye-0004L7-W5 for submit@debbugs.gnu.org; Sun, 04 Jan 2015 18:52:57 -0500 Received: from mail-la0-f47.google.com ([209.85.215.47]:47471) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y7uyd-0004Kz-7y for 19468@debbugs.gnu.org; Sun, 04 Jan 2015 18:52:55 -0500 Received: by mail-la0-f47.google.com with SMTP id hz20so17694151lab.34 for <19468@debbugs.gnu.org>; Sun, 04 Jan 2015 15:52:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7CTE4SLOvA2iWtlAVijAsn19NFEWPIc2D373La93qpQ=; b=LnOu6hN6iYXtc/D50TSlI70KF/hCOcrp8Kp/NalxlTXbA4qcRodhLZR354RqOERKPM HbvXLvKuo76tClA+kQFbP3nZTlEIVmbrUwAgC2xzO9T52LrA/pC/fym4kcAsnBxPu3wA IBPp1UIobpL+QEMxofBJci2QD2zWk2bfd5bKDtxtkKH6oPbhvCcZJtE0oE4dKiuaeNxr 8lOP+J6sHKvGR7xjoshGjg3Zf1HDllhIg3bMdoUpnIOCGgl0wOI6QEiTgQ9E7QKNamsg 9pvnWsXAu8XYGFcDCIQ9k+wcfm/sN54UbuOhbfDKPGyorL4MhzIxHSo4lGno0HvgV1ih 1zNA== X-Received: by 10.152.28.71 with SMTP id z7mr89255704lag.60.1420415574413; Sun, 04 Jan 2015 15:52:54 -0800 (PST) Received: from [192.168.1.3] ([178.252.98.87]) by mx.google.com with ESMTPSA id t10sm10859739lat.31.2015.01.04.15.52.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jan 2015 15:52:53 -0800 (PST) Message-ID: <54A9D253.7050104@yandex.ru> Date: Mon, 05 Jan 2015 02:52:51 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <83tx0db0x5.fsf@gnu.org> In-Reply-To: <83tx0db0x5.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 12/30/2014 06:41 PM, Eli Zaretskii wrote: > More importantly, it will tell the user what she needs to do, even if > she doesn't use the mouse, because mouse-sensitive portions of Emacs > display generally behave very similarly. I've added some button-like interaction, but not exactly using buttons (largely because of bug#19500). The interaction might be a bit unconventional by Emacs standards (mouse-2 works like C-o; mouse-1 works like RET), but see how it works for you. Reverting the bindings is not out of the question. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 05 Jan 2015 07:10:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov , Helmut Eller Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.142044174330378 (code B ref 19468); Mon, 05 Jan 2015 07:10:03 +0000 Received: (at 19468) by debbugs.gnu.org; 5 Jan 2015 07:09:03 +0000 Received: from localhost ([127.0.0.1]:36916 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y81mg-0007tu-LT for submit@debbugs.gnu.org; Mon, 05 Jan 2015 02:09:02 -0500 Received: from mout.gmx.net ([212.227.17.21]:64735) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y81md-0007tU-UV for 19468@debbugs.gnu.org; Mon, 05 Jan 2015 02:09:00 -0500 Received: from [178.191.136.61] ([178.191.136.61]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MWkZL-1YIlS92sVn-00Xstu; Mon, 05 Jan 2015 08:08:54 +0100 Message-ID: <54AA3881.3080304@gmx.at> Date: Mon, 05 Jan 2015 08:08:49 +0100 From: martin rudalics MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> In-Reply-To: <54A9C3FB.7000602@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:0J4KRdsSeZwmFx+QpBfAdm3aFU8niEsMh/G5Dh67GRXEyNOGofy eaKhutbhNFMQgS+BW9FPnJkqZlFJIBgfwy9Ix/9g00NGsNKndWq0nq+PWStRAmTNwBQkqD7 PU0u78tCBc6hdhUcsej5UXeyfO7iwOJC/v4AZD/X3ShAcZfInp/NQa39oe8d8Vln8TwRXF6 jrzTeuGqR1lVH5wgDx1Eg== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > In all likelihood, we've displayed several buffers in succession in that other window. Or none. Doing `quit-window' there exactly once won't suffice. It should, conceptually. > So I guess this amounts to keeping a buffer-window history of everything that was opened from *xrefs*, and on `q', iterate through that list and, if the given window displays the given buffer, `quit-buffer' on it. Then clear the history and quit *xrefs*. We have two windows we want to quit simultaneously. Any of them could have been made specially for xrefing or have displayed some other buffer before. In the former case the window would have to be deleted in the latter made to show the buffer it showed before xrefing. The entire information what to do should be in the `quit-restore' parameter of any of these windows. If what I described above doesn't work out automatically you might have to adjust the `quit-restore' parameter manually. But it should work automatically. > I kinda like that. You shouldn't. martin From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 05 Jan 2015 19:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: eller.helmut@gmail.com, 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.142048698027988 (code B ref 19468); Mon, 05 Jan 2015 19:43:02 +0000 Received: (at 19468) by debbugs.gnu.org; 5 Jan 2015 19:43:00 +0000 Received: from localhost ([127.0.0.1]:37801 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y8DYJ-0007HL-Gx for submit@debbugs.gnu.org; Mon, 05 Jan 2015 14:42:59 -0500 Received: from mtaout25.012.net.il ([80.179.55.181]:41644) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y8DYF-0007HB-Ph for 19468@debbugs.gnu.org; Mon, 05 Jan 2015 14:42:57 -0500 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NHP00200Y9HGZ00@mtaout25.012.net.il> for 19468@debbugs.gnu.org; Mon, 05 Jan 2015 21:38:51 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHP002ZHYKQ0F10@mtaout25.012.net.il>; Mon, 05 Jan 2015 21:38:50 +0200 (IST) Date: Mon, 05 Jan 2015 21:43:00 +0200 From: Eli Zaretskii In-reply-to: <54A9D253.7050104@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83fvbp814r.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <83tx0db0x5.fsf@gnu.org> <54A9D253.7050104@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Mon, 05 Jan 2015 02:52:51 +0300 > From: Dmitry Gutov > CC: 19468@debbugs.gnu.org, eller.helmut@gmail.com > > On 12/30/2014 06:41 PM, Eli Zaretskii wrote: > > > More importantly, it will tell the user what she needs to do, even if > > she doesn't use the mouse, because mouse-sensitive portions of Emacs > > display generally behave very similarly. > > I've added some button-like interaction, but not exactly using buttons > (largely because of bug#19500). > > The interaction might be a bit unconventional by Emacs standards > (mouse-2 works like C-o; mouse-1 works like RET), but see how it works > for you. Reverting the bindings is not out of the question. Looks OK; adding help-echo will make it even better. Thanks. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Jan 2015 10:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics , Helmut Eller Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.142054075222209 (code B ref 19468); Tue, 06 Jan 2015 10:40:02 +0000 Received: (at 19468) by debbugs.gnu.org; 6 Jan 2015 10:39:12 +0000 Received: from localhost ([127.0.0.1]:37960 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y8RXb-0005m9-R3 for submit@debbugs.gnu.org; Tue, 06 Jan 2015 05:39:12 -0500 Received: from mail-lb0-f182.google.com ([209.85.217.182]:42064) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y8RXZ-0005m1-UK for 19468@debbugs.gnu.org; Tue, 06 Jan 2015 05:39:10 -0500 Received: by mail-lb0-f182.google.com with SMTP id u10so715761lbd.13 for <19468@debbugs.gnu.org>; Tue, 06 Jan 2015 02:39:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5xV0ioNx1KVKLFNxRgvSDbHSVswYWQNLX8549eds0i8=; b=pMdkYshAeVM4ItkfxsIWxZDQCV4rBQlL+DCrBNwk8jdbwTiozglYufKhsBPo15xgM1 98bV2fSwPKgspNoKy/2FLtJTMw/Ot+cF5Q6fegHADdOfFOIsj7dJHBok19wBMaQWlpdu OEp79pJ1rjq5MESJ5JH5LaiBhpbD8dCOpOz80D32XltOBT0isw2/Ggw8n/G9ryoLC5tl Dg0NfrbND8hTg0wVDBNxI4LGD8FsC9OQ/GMkBYafqUTSlvETIAzF8TuYdd4YArRlj5jB ipgwPoT2kVx8dwuuhmw/pB4Q6uuxinmfszPyaEbRc8HG5zmf7h3Wcnk4BV2KSYqVfOMv /HGg== X-Received: by 10.112.235.137 with SMTP id um9mr98810522lbc.41.1420540749066; Tue, 06 Jan 2015 02:39:09 -0800 (PST) Received: from [192.168.1.3] ([178.252.98.87]) by mx.google.com with ESMTPSA id g7sm15276773lae.15.2015.01.06.02.39.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jan 2015 02:39:08 -0800 (PST) Message-ID: <54ABBB47.7010603@yandex.ru> Date: Tue, 06 Jan 2015 13:39:03 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> In-Reply-To: <54AA3881.3080304@gmx.at> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 01/05/2015 10:08 AM, martin rudalics wrote: > > In all likelihood, we've displayed several buffers in succession in > that other window. Or none. Doing `quit-window' there exactly once won't > suffice. > > It should, conceptually. One `quit-window' would switch to the buffer below it. If that one was also displayed by xref, we don't gain much at all. And what if, like I already mentioned, xref hasn't displayed any xref definitions yet? > We have two windows we want to quit simultaneously. Quit windows or not, that's an implementation detail. We want to restore window configuration before xref, but only if the user hasn't tampered with it in the process. > Any of them could > have been made specially for xrefing Not really: `xref--display-position' calls (display-buffer (current-buffer) t). > The entire information what to do should be in the `quit-restore' > parameter of any of these windows. If what I described above doesn't > work out automatically you might have to adjust the `quit-restore' > parameter manually. But it should work automatically. What then, you would rather I save the original buffer displayed in the other window, and then changed the `quit-restore' parameter in that window before quitting? I could just as well do all the `bury-buffer' myself. And that won't take care of the case when the window configuration is changed by anything other than xref. I've pushed my implementation using `quit-window' to scratch/xref, please take a look. What would you do better? From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Apr 2015 14:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143006028029704 (code B ref 19468); Sun, 26 Apr 2015 14:58:02 +0000 Received: (at 19468) by debbugs.gnu.org; 26 Apr 2015 14:58:00 +0000 Received: from localhost ([127.0.0.1]:40523 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmO0O-0007j2-3k for submit@debbugs.gnu.org; Sun, 26 Apr 2015 10:58:00 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:54732) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmO0L-0007ik-4y for 19468@debbugs.gnu.org; Sun, 26 Apr 2015 10:57:58 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NNF00K005762800@mtaout27.012.net.il> for 19468@debbugs.gnu.org; Sun, 26 Apr 2015 17:51:53 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNF00J0L5AHG010@mtaout27.012.net.il>; Sun, 26 Apr 2015 17:51:53 +0300 (IDT) Date: Sun, 26 Apr 2015 17:56:37 +0300 From: Eli Zaretskii In-reply-to: <54ABBB47.7010603@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <837fszx7iy.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) So, prompted by the renewed discussion of 'xref', I took another look at the current states of affairs with the UI, and found the following issues: . xref-etags-mode: I tried this mode, and found a few places for improvement: . It's not available by default: emacs -Q M-x xref-et TAB => [No match] It should be autoloaded, IMO. Perhaps there should also be a global minor mode, for those who'd like that. . It does nothing when point is on a unique symbol: M-. set_cursor_from_row RET Now, with point on its position under set_cursor_from_row, type M-. again => nothing(??!!) happens I guess it looks for more symbols matching set_cursor_from_row, finds out that this is the only one, and does nothing. This is not useful. It should at the very least say something like "set_cursor_from_row: this is the only match". Bonus points for prompting for a symbol, like it does when there's no symbol at point, because I think this is more useful in this situation. . Some problems with key bindings in the *xref* buffer: . RET displays the candidate listed on the current line, but closes the window displaying *xref*, so it's not easy to try another candidate afterwards. I think it would be more helpful to just switch to the window showing the definition, but leave the *xref* buffer shown. . You need to use the unconventional '.' and ',' to both move and display the definitions -- this should at least be mentioned in the initial echo-area message when *xref* is first displayed. (This was reported as a problem in the original report, but seems to be left unchanged.) . No replacement for tags-loop-continue: If I somehow let the window showing *xref* close (e.g., by typing RET, see above), what is the equivalent for tags-loop-continue, i.e. display the next candidate, without explicitly displaying the *xref* buffer again? If there isn't one, please provide it, at least as part of xref-etags-mode. (Other similar Emacs modes, like Compilation and Grep, do provide commands to move to the next item without first switching to the buffer that shows all the hits.) . The back-end issue: . Caveat: I couldn't find any documentation of back-ends, so perhaps I'm missing something important. That being said... . I tried the ELisp back-end and found that it somehow affects the UI, so that the UI behaves differently than with the default etags back-end, when the user types something that is "complete, but not unique": when using the etags back-end, Emacs displays a list of candidates in the *xref* buffer, whereas with the elisp-mode back-end it shows the "complete" candidate, doesn't display *xref*, and doesn't insert the other candidates into *xref*. Is this difference intended? It's confusing, to say the least. . xref.el says: ;; For now, make the etags backend the default. (defvar xref-find-function #'etags-xref-find But what are the alternatives, if any? I could only find something related in ada-mode and in elisp-mode. This means that, for example, for C/C++ and Java, etags is the only available back-end, and this change is currently just a different UI wrapping the same basic functionality? Is there any further development planned for the near future? . The doc string of xref-find-function mentions several variants of invoking the function, but there doesn't seem to be any way of controlling that when invoking the function interactively, is there? I think it would be good to be able to lookup only the definitions or only the references of a symbol. HTH From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 04:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org, Dmitry Gutov Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143010905125194 (code B ref 19468); Mon, 27 Apr 2015 04:31:02 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 04:30:51 +0000 Received: from localhost ([127.0.0.1]:40760 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymagz-0006YH-Bl for submit@debbugs.gnu.org; Mon, 27 Apr 2015 00:30:50 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:17802) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymagx-0006Y4-38 for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 00:30:47 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFAGvvdVRMCqjW/2dsb2JhbAA3gVOfQYIugQiBdQEBBAFWIwULCzQSFBgNJIYjgXCiEYwDGAZDDAODPgODcASjY4RYgUA X-IPAS-Result: AnEFAGvvdVRMCqjW/2dsb2JhbAA3gVOfQYIugQiBdQEBBAFWIwULCzQSFBgNJIYjgXCiEYwDGAZDDAODPgODcASjY4RYgUA X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="117510155" Received: from 76-10-168-214.dsl.teksavvy.com (HELO ceviche.home) ([76.10.168.214]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Apr 2015 00:30:41 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 63B4B6610A; Mon, 27 Apr 2015 00:30:41 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> Date: Mon, 27 Apr 2015 00:30:41 -0400 In-Reply-To: <837fszx7iy.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 26 Apr 2015 17:56:37 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > . I tried the ELisp back-end and found that it somehow affects the > UI, so that the UI behaves differently than with the default > etags back-end, when the user types something that is "complete, > but not unique": when using the etags back-end, Emacs displays a > list of candidates in the *xref* buffer, whereas with the > elisp-mode back-end it shows the "complete" candidate, doesn't > display *xref*, and doesn't insert the other candidates into > *xref*. Is this difference intended? It's confusing, to say the > least. I don't understand exactly the scenario you're talking about. Can you give a recipe? > But what are the alternatives, if any? I could only find > something related in ada-mode and in elisp-mode. This means > that, for example, for C/C++ and Java, etags is the only > available back-end, and this change is currently just a different > UI wrapping the same basic functionality? Is there any further > development planned for the near future? There should very much be other backends on the way, e.g. using Semantic (for C/C++), SLIME (for CL), ... > . The doc string of xref-find-function mentions several variants of > invoking the function, but there doesn't seem to be any way of > controlling that when invoking the function interactively, is > there? I think it would be good to be able to lookup only the > definitions or only the references of a symbol. Indeed, the current UI does not offer access to all features of the API. Improvements welcome, Stefan From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 15:10:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 19468@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14301473736881 (code B ref 19468); Mon, 27 Apr 2015 15:10:03 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 15:09:33 +0000 Received: from localhost ([127.0.0.1]:41354 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymkf4-0001mp-3m for submit@debbugs.gnu.org; Mon, 27 Apr 2015 11:09:33 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:49645) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymkez-0001mU-5C for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 11:09:28 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NNH00C000K5ZV00@mtaout26.012.net.il> for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 18:09:30 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNH00BGB0RT6D20@mtaout26.012.net.il>; Mon, 27 Apr 2015 18:09:30 +0300 (IDT) Date: Mon, 27 Apr 2015 18:07:44 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83r3r5wqwv.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: Dmitry Gutov , 19468@debbugs.gnu.org > Date: Mon, 27 Apr 2015 00:30:41 -0400 > > > . I tried the ELisp back-end and found that it somehow affects the > > UI, so that the UI behaves differently than with the default > > etags back-end, when the user types something that is "complete, > > but not unique": when using the etags back-end, Emacs displays a > > list of candidates in the *xref* buffer, whereas with the > > elisp-mode back-end it shows the "complete" candidate, doesn't > > display *xref*, and doesn't insert the other candidates into > > *xref*. Is this difference intended? It's confusing, to say the > > least. > > I don't understand exactly the scenario you're talking about. Can you > give a recipe? Yes: emacs -Q C-x C-f lisp/simple.el RET M-. find-tag RET This puts you at the first line of find-tag, without showing the other possible symbols whose names contain "find-tag" as their substring. If you want the other candidates, you need to type TAB instead of RET, and then select the one you want via the usual completion facilities. By contrast, this: emacs -Q C-x C-f lisp/simple.el RET M-x load-library RET xref RET M-x xref-etags-mode RET M-. find-tag RET does NOT show the definition of find-tag, but instead opens an *xref* buffer with possible matches, and expects you to pick one of them (and btw the defun I'm probably after is not the first or second hit there; looks like the candidates are arranged in the alphabetical order of the *.el files). I guess the elisp-mode back-end returns just one candidate, whereas the etags back-end returns a list. But it's confusing to have such evident differences just because you changed the back-end, I think. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 15:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 19468@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14301476317335 (code B ref 19468); Mon, 27 Apr 2015 15:14:02 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 15:13:51 +0000 Received: from localhost ([127.0.0.1]:41358 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmkjH-0001uF-8U for submit@debbugs.gnu.org; Mon, 27 Apr 2015 11:13:51 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:35761) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmkjF-0001u0-F1 for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 11:13:50 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NNH00H000R3A200@a-mtaout23.012.net.il> for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 18:13:16 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNH00HPX0Y38L30@a-mtaout23.012.net.il>; Mon, 27 Apr 2015 18:13:16 +0300 (IDT) Date: Mon, 27 Apr 2015 18:13:07 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83pp6pwqnw.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: Dmitry Gutov , 19468@debbugs.gnu.org > Date: Mon, 27 Apr 2015 00:30:41 -0400 > > > But what are the alternatives, if any? I could only find > > something related in ada-mode and in elisp-mode. This means > > that, for example, for C/C++ and Java, etags is the only > > available back-end, and this change is currently just a different > > UI wrapping the same basic functionality? Is there any further > > development planned for the near future? > > There should very much be other backends on the way, e.g. using Semantic > (for C/C++), SLIME (for CL), ... I certainly hope that at least the Semantic one materializes soon enough, otherwise it sounds like all this move to xref was for the benefit of unbundled packages, and users of Emacs are just punished by having to learn a new UI for no real advantage. > > . The doc string of xref-find-function mentions several variants of > > invoking the function, but there doesn't seem to be any way of > > controlling that when invoking the function interactively, is > > there? I think it would be good to be able to lookup only the > > definitions or only the references of a symbol. > > Indeed, the current UI does not offer access to all features of the API. > Improvements welcome, Not from me: I've been told in this discussion that I don't understand the new UI, don't appreciate its many virtues, and generally am no more than an obstacle on the way of progress. So I really don't think I should mess with this UI. That said, the usual way in Emacs to provide minor variants of a command is via special values of the prefix argument, like, for example, "C-x C-s" does. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 17:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.1430155276634 (code B ref 19468); Mon, 27 Apr 2015 17:22:02 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 17:21:16 +0000 Received: from localhost ([127.0.0.1]:41463 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmmiX-0000A8-NK for submit@debbugs.gnu.org; Mon, 27 Apr 2015 13:21:15 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:53943) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmmiU-00009t-2O for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 13:21:11 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t3RHL7aV016490; Mon, 27 Apr 2015 13:21:07 -0400 Received: by pastel.home (Postfix, from userid 20848) id 8497F19DA; Mon, 27 Apr 2015 13:21:07 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> Date: Mon, 27 Apr 2015 13:21:07 -0400 In-Reply-To: <83pp6pwqnw.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 27 Apr 2015 18:13:07 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5289=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5289> : inlines <2801> : streams <1429557> : uri <1916904> X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > I certainly hope that at least the Semantic one materializes soon > enough, otherwise it sounds like all this move to xref was for the > benefit of unbundled packages, IMO one of the main tasks of the maintainers is to provide infrastructure that consolidates the features that are duplicated out there in many different packages, all mutually slightly incompatible. So the usefulness does not directly depend on whether that feature is used by bundled or unbundled packages. Emacs thrives in large part thanks to all the unbundled packages out there and we shouldn't treat them as second-rate citizens. [ Of course, I much prefer when a package's copyright is assigned and when it's either in GNU ELPA or in Emacs proper, especially because it makes it easier to incorporate its features into the core so as to expand the general infrastructure and let other packages build on it. ] > and users of Emacs are just punished by having to learn a new UI for > no real advantage. I like the new UI, FWIW. But clearly, we need to work to make it better for those users who miss some aspects of the old UI. BTW, w.r.t the use of etags, what do you think of the patch below, which lets the elisp-xref functionality fallback on etags for functions/vars that aren't currently bound? [ Clearly, the patch doesn't work as is, since it only works once xref is loaded, but I hope you see what this is intended to do. ] > That said, the usual way in Emacs to provide minor variants of a > command is via special values of the prefix argument, like, for > example, "C-x C-s" does. The different ways to call xref-find-function are to distinguish jumping to the definition or to "all uses", and currently few backends support those features, I don't think we have a clear idea yet of how they should be presented to the user, and there are too many variants to collapse them all into C-u. So they'd probably be provided via different commands instead of all being accessed via M-. Stefan diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el index f289068..04bf49d 100644 --- a/lisp/progmodes/elisp-mode.el +++ b/lisp/progmodes/elisp-mode.el @@ -235,9 +235,9 @@ Blank lines separate paragraphs. Semicolons start comments. (setq imenu-case-fold-search nil) (add-function :before-until (local 'eldoc-documentation-function) #'elisp-eldoc-documentation-function) - (setq-local xref-find-function #'elisp-xref-find) - (setq-local xref-identifier-completion-table-function - #'elisp--xref-identifier-completion-table) + (add-function :before-until (local 'xref-find-function) #'elisp-xref-find) + (add-function :before-until (local 'xref-identifier-completion-table-function) + #'elisp--xref-identifier-completion-table) (add-hook 'completion-at-point-functions #'elisp-completion-at-point nil 'local)) From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 17:36:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14301561302512 (code B ref 19468); Mon, 27 Apr 2015 17:36:03 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 17:35:30 +0000 Received: from localhost ([127.0.0.1]:41472 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmmwL-0000eR-4y for submit@debbugs.gnu.org; Mon, 27 Apr 2015 13:35:29 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:48810) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmmwJ-0000eH-Mp for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 13:35:28 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t3RHZPrZ014073; Mon, 27 Apr 2015 13:35:25 -0400 Received: by pastel.home (Postfix, from userid 20848) id 67D4619DA; Mon, 27 Apr 2015 13:35:25 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> Date: Mon, 27 Apr 2015 13:35:25 -0400 In-Reply-To: <83r3r5wqwv.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 27 Apr 2015 18:07:44 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5289=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5289> : inlines <2802> : streams <1429562> : uri <1916914> X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) >> I don't understand exactly the scenario you're talking about. Can you >> give a recipe? > > Yes: > > emacs -Q > C-x C-f lisp/simple.el RET > M-. find-tag RET > > This puts you at the first line of find-tag, without showing the other > possible symbols whose names contain "find-tag" as their substring. Yes, that's the expected behavior, and matches the behavior of Emacs-24. Is that a behavior you like or a behavior you dislike? > By contrast, this: > > emacs -Q > C-x C-f lisp/simple.el RET > M-x load-library RET xref RET > M-x xref-etags-mode RET > M-. find-tag RET > > does NOT show the definition of find-tag, but instead opens an *xref* > buffer with possible matches, and expects you to pick one of them (and Indeed, one of the differences in the new UI is that we don't have the "C-u M-. lets you cycle among matches" any more. Instead we pop up an *xref* buffer where you can choose the match that interests you. I find this easier (and generally faster) to use. This is an issue that only affects the UI (not the API and hence not the backends), so we can easily fix it by providing either different UIs, or some config var, or ... > btw the defun I'm probably after is not the first or second hit there; > looks like the candidates are arranged in the alphabetical order of > the *.el files). Indeed, the ordering looks incorrect. This is a bug. > I guess the elisp-mode back-end returns just one candidate, whereas > the etags back-end returns a list. Exactly. > But it's confusing to have such evident differences just because you > changed the back-end, I think. But popping up the *xref* buffer when there's only one element in it doesn't make much sense I think. Stefan From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 19:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 19468@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143016215617936 (code B ref 19468); Mon, 27 Apr 2015 19:16:02 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 19:15:56 +0000 Received: from localhost ([127.0.0.1]:41531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmoVV-0004fC-Su for submit@debbugs.gnu.org; Mon, 27 Apr 2015 15:15:55 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:35933) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmoVS-0004ew-4l for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 15:15:51 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NNH00J00C4Z5S00@mtaout26.012.net.il> for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 22:17:19 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNH00ACRC8VB180@mtaout26.012.net.il>; Mon, 27 Apr 2015 22:17:19 +0300 (IDT) Date: Mon, 27 Apr 2015 22:15:34 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83lhhdwfft.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: dgutov@yandex.ru, 19468@debbugs.gnu.org > Date: Mon, 27 Apr 2015 13:21:07 -0400 > > > I certainly hope that at least the Semantic one materializes soon > > enough, otherwise it sounds like all this move to xref was for the > > benefit of unbundled packages, > > IMO one of the main tasks of the maintainers is to provide > infrastructure that consolidates the features that are duplicated out > there in many different packages, all mutually slightly incompatible. > > So the usefulness does not directly depend on whether that feature is > used by bundled or unbundled packages. Emacs thrives in large part > thanks to all the unbundled packages out there and we shouldn't treat > them as second-rate citizens. We shouldn't treat the Emacs core as second-rate citizen, either. A feature as central to code development and Emacs in general as finding definitions and references of symbols cannot thrive only (or mainly) outside the core, IMO. > > and users of Emacs are just punished by having to learn a new UI for > > no real advantage. > > I like the new UI, FWIW. Where did you see me say I dislike it? I'm just saying that learning a new UI for the sake of a new UI is a waste. I _am_ prepared to learn a new UI if it brings new useful functionality with it. > BTW, w.r.t the use of etags, what do you think of the patch below, which > lets the elisp-xref functionality fallback on etags for functions/vars > that aren't currently bound? What's it supposed to do? Anyway, I once again think that if we will mostly "fall back on etags" every time the new back-ends are somehow imperfect, then what exactly did we gain with this move? I heard more than once in recent discussions that the etags back-end is less than perfect, to put it mildly; after hearing this so much, I wonder how it makes sense to fall back on it all the time. If it's not good, let's replace it with something better, not fall back on it. > > That said, the usual way in Emacs to provide minor variants of a > > command is via special values of the prefix argument, like, for > > example, "C-x C-s" does. > > The different ways to call xref-find-function are to distinguish > jumping to the definition or to "all uses", and currently few backends > support those features Sounds like another feature that was planned, but never implemented. Once again, why did we switch to xref if so much of its promise is yet to come? > I don't think we have a clear idea yet of how they should be > presented to the user There's prior art out there in other IDEs, we could start by learning from them. > and there are too many variants to collapse them all into C-u. "C-x C-s" manages to provide no less than 4 variants with C-u, so I see no problem to use it with this command. That said, ... > So they'd probably be provided via different commands instead of all > being accessed via M-. ... I won't mind this alternative, either, although we don't have too many keys left to use for those other commands. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 19:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 19468@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143016281918906 (code B ref 19468); Mon, 27 Apr 2015 19:27:01 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 19:26:59 +0000 Received: from localhost ([127.0.0.1]:41535 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmogE-0004ur-Ir for submit@debbugs.gnu.org; Mon, 27 Apr 2015 15:26:59 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:52751) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmogB-0004ud-E3 for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 15:26:56 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NNH00900BSMB800@mtaout24.012.net.il> for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 22:18:01 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNH002T4CA1IA70@mtaout24.012.net.il>; Mon, 27 Apr 2015 22:18:01 +0300 (IDT) Date: Mon, 27 Apr 2015 22:26:40 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83k2wxwexb.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: dgutov@yandex.ru, 19468@debbugs.gnu.org > Date: Mon, 27 Apr 2015 13:35:25 -0400 > > >> I don't understand exactly the scenario you're talking about. Can you > >> give a recipe? > > > > Yes: > > > > emacs -Q > > C-x C-f lisp/simple.el RET > > M-. find-tag RET > > > > This puts you at the first line of find-tag, without showing the other > > possible symbols whose names contain "find-tag" as their substring. > > Yes, that's the expected behavior, and matches the behavior of Emacs-24. Emacs 24 also had "C-u M-." to go to the next one. This one doesn't; moreover, if you try "C-u M-.", you get prompted for the symbol again, and if you type the same one, you get nowhere. The other matches are only available via completion, see below. > Is that a behavior you like or a behavior you dislike? It's surprising, since I expected to see the *xref* buffer, as I understood this is the core of the new UI. But it sounds like the back-end can easily affect the UI in radical ways, which I think is not a good thing: the entire idea of the back-end means to me that the front-end is not affected, UI-wise. > > By contrast, this: > > > > emacs -Q > > C-x C-f lisp/simple.el RET > > M-x load-library RET xref RET > > M-x xref-etags-mode RET > > M-. find-tag RET > > > > does NOT show the definition of find-tag, but instead opens an *xref* > > buffer with possible matches, and expects you to pick one of them (and > > Indeed, one of the differences in the new UI is that we don't have the > "C-u M-. lets you cycle among matches" any more. Instead we pop up an > *xref* buffer where you can choose the match that interests you. I find > this easier (and generally faster) to use. OK, but then why aren't we shown *xref* in the first case? > > But it's confusing to have such evident differences just because you > > changed the back-end, I think. > > But popping up the *xref* buffer when there's only one element in it > doesn't make much sense I think. Oh, but there shouldn't be only one element: you will see the others if you type TAB instead of RET. IOW, the elisp-mode back-end does know about the other candidates, it just doesn't show them in *xref*. It somehow decided for me that I want only the exact match. And btw, there is another confusing difference between these back-ends that somehow bubbles up to the UI level: the elisp-mode back-end only supports finding multiple matches via completion, and completion, at least by default, only finds candidates whose leading substring matches what you type. By contrast, the *xref* buffer popped when the etags back-end is in use shows substring matches _anywhere_ in the symbol names, so it shows much more candidates. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 21:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143017097316111 (code B ref 19468); Mon, 27 Apr 2015 21:43:02 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 21:42:53 +0000 Received: from localhost ([127.0.0.1]:41648 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymqnl-0004Bn-AX for submit@debbugs.gnu.org; Mon, 27 Apr 2015 17:42:53 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:47292) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymqnj-0004Bf-5d for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 17:42:52 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t3RLgnRu029207; Mon, 27 Apr 2015 17:42:49 -0400 Received: by pastel.home (Postfix, from userid 20848) id 1DBB71E3F; Mon, 27 Apr 2015 17:42:49 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <83lhhdwfft.fsf@gnu.org> Date: Mon, 27 Apr 2015 17:42:49 -0400 In-Reply-To: <83lhhdwfft.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 27 Apr 2015 22:15:34 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5289=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5289> : inlines <2804> : streams <1429656> : uri <1917065> X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) >> BTW, w.r.t the use of etags, what do you think of the patch below, which >> lets the elisp-xref functionality fallback on etags for functions/vars >> that aren't currently bound? > What's it supposed to do? Let you find the definition of a function that's not defined yet, thanks to the use of the TAGS database. > Anyway, I once again think that if we will mostly "fall back on etags" > every time the new back-ends are somehow imperfect, then what exactly > did we gain with this move? I just suggest it to cover those cases where the user likes the old etags behavior. I personally preferred using C-h f until now over etags's M-. because it was more reliable, so I find the new M-. to be a good change and don't need to fallback to etags's backend. > ... I won't mind this alternative, either, although we don't have too > many keys left to use for those other commands. They don't have to be single-key bindings. Stefan From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 21:55:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143017167722704 (code B ref 19468); Mon, 27 Apr 2015 21:55:03 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 21:54:37 +0000 Received: from localhost ([127.0.0.1]:41656 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymqz6-0005u6-AH for submit@debbugs.gnu.org; Mon, 27 Apr 2015 17:54:36 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:55334) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymqz3-0005ty-QC for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 17:54:34 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t3RLsU5b023410; Mon, 27 Apr 2015 17:54:30 -0400 Received: by pastel.home (Postfix, from userid 20848) id 80F861E3F; Mon, 27 Apr 2015 17:54:30 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <83k2wxwexb.fsf@gnu.org> Date: Mon, 27 Apr 2015 17:54:30 -0400 In-Reply-To: <83k2wxwexb.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 27 Apr 2015 22:26:40 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5289=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5289> : inlines <2804> : streams <1429661> : uri <1917071> X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > Emacs 24 also had "C-u M-." to go to the next one. This one doesn't; > moreover, if you try "C-u M-.", you get prompted for the symbol again, > and if you type the same one, you get nowhere. The other matches are > only available via completion, see below. Maybe we should write an xref-old-ui-mode. It would make M-. always prompt and it would always jump to the first entry and then let you use C-u M-. to jump to the next match. >> But popping up the *xref* buffer when there's only one element in it >> doesn't make much sense I think. > Oh, but there shouldn't be only one element: you will see the others > if you type TAB instead of RET. No: there's only one definition of `find-tag' so Elisp's xref backend just returns that one and that's it. > IOW, the elisp-mode back-end does know about the other candidates, it > just doesn't show them in *xref*. None of the others are definitions of `find-tag'. Arguably, the find-tag advice in org-ctags.el could be offered as well, if org-ctags.el happens to be loaded (tho currently we could only do that for an advice added via advice-add rather than via defadvice since defadvice does not keep track of the origin). > It somehow decided for me that I want only the exact match. It's rather that the old etags interface was not sure enough of itself, so it offered anything that had "find-tag" as a substring somewhere, i.e. lots and lots of false positives. > And btw, there is another confusing difference between these back-ends > that somehow bubbles up to the UI level: the elisp-mode back-end only > supports finding multiple matches via completion, No. `semantic-symref-find-tags-by-name' is not a match for "show me the definition of find-tag" and neither is "find-tag-tag". The problem here is that the current etags xref backend returns confusingly many so-called "matches" which are really irrelevant and should only be included in the completions. There's a difference between: I know the name, I need to find out its definition. and I remember the name includes something like "find-tag" The old code did not distinguish between the two, but the new code does. I think that's an important feature of the new code in this respect. Stefan From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 22:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier , Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143017216623474 (code B ref 19468); Mon, 27 Apr 2015 22:03:01 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 22:02:46 +0000 Received: from localhost ([127.0.0.1]:41664 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymr6z-00066Y-V8 for submit@debbugs.gnu.org; Mon, 27 Apr 2015 18:02:46 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:33539) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymr6x-00066K-Jo for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 18:02:44 -0400 Received: by wief7 with SMTP id f7so3255582wie.0 for <19468@debbugs.gnu.org>; Mon, 27 Apr 2015 15:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=eA7Ev59yBtuMiSGjcFnh1TH5xRaauyKbebeFOhQNGbA=; b=zKsuQa0M9Xlm5iO2J6QMFvwVaV7QXtYUeZO6wOP5Pkd7ynBkrZoq7uR60pTCW2MTaT bzgiBIlJkckHCpxZeybiQ5QB1GZSDh2ifFAhhd3NElH74u+VqIi/fiw4MyiptiuAEaZU YK4EHGH3wGT6wP/eRw/iAqwFLHHXNFx8Absb8jTsX6rqpPaNlDVbm/XSB67lxNcqbXBj 0TbAFxICBtcgdrFfH9LPTZPYgVrBseNOI8JOgx3lcZpMTLlmZKZXXzkh4CSUyDOHs0gW D1II4GEEg2ZJUjLabN8yx5/CrwFyW4ym58/I4tPSJg3bRhRDZ29Aa7skjZPL2iFUJbqN lKWw== X-Received: by 10.194.187.16 with SMTP id fo16mr26999008wjc.86.1430172158001; Mon, 27 Apr 2015 15:02:38 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id ex5sm13435484wib.2.2015.04.27.15.02.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 15:02:37 -0700 (PDT) Message-ID: <553EB1FC.1020601@yandex.ru> Date: Tue, 28 Apr 2015 01:02:36 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/27/2015 07:30 AM, Stefan Monnier wrote: > There should very much be other backends on the way, e.g. using Semantic > (for C/C++), SLIME (for CL), ... Both CIDER and SLIME look like a good candidate among third-party packages. I also intend to use it in Robe (which can't be added to GNU ELPA because of inf-ruby dependency; it's also begging for a rewrite...) >> . The doc string of xref-find-function mentions several variants of >> invoking the function, but there doesn't seem to be any way of >> controlling that when invoking the function interactively, is >> there? I think it would be good to be able to lookup only the >> definitions or only the references of a symbol. `M-.' only looks up definitions. Or at least, that's the . > Indeed, the current UI does not offer access to all features of the API. There is M-x xref-find-references. Neither of the two current backends implements it, though (but I know SLIME has such a feature, and CEDET probably has something comparable). We could bind it to `C-M-?. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 22:10:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Stefan Monnier Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143017259024066 (code B ref 19468); Mon, 27 Apr 2015 22:10:03 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 22:09:50 +0000 Received: from localhost ([127.0.0.1]:41669 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmrDp-0006G6-TV for submit@debbugs.gnu.org; Mon, 27 Apr 2015 18:09:50 -0400 Received: from mail-wg0-f44.google.com ([74.125.82.44]:35715) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmrDn-0006Ft-S6 for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 18:09:48 -0400 Received: by wgyo15 with SMTP id o15so131172701wgy.2 for <19468@debbugs.gnu.org>; Mon, 27 Apr 2015 15:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3enG29WdPtWAGjKX0tCN7aJmUhpxG7DYvmDKkSiOe5g=; b=sDBN4GngOTjN6Dd+69qa9I5XaWWoaM6usTcBLQrR+W+jPHN17GkwPSoaHmhnbE9qYb jwwYfWUEvoc2gT7m3OHsAfqNYAQZmxEwnpQYIBOIfylbeS08hubsX0U25X8DzXPuHDuV DiUGscmWmW5g30GWuEsuS+Hc0hTVs2cq7iIiKXgan34iUrzScEse7FbdcpWnTP43lJQR ufsvGvkNQwOOpU6EFT97wmAYEalJRpLFAVzzJnMVUjMFgG462Xu+dHeqXtzPrx2xBE/i 6+AF6GvKDL78KMstMZMJoeBJasA4C9IZwPaHqiv0euDyFoJi9Y1k+eJ51V/XhNpZDkWw ahyw== X-Received: by 10.180.219.42 with SMTP id pl10mr24523305wic.70.1430172582364; Mon, 27 Apr 2015 15:09:42 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id wr2sm31240343wjb.45.2015.04.27.15.09.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 15:09:42 -0700 (PDT) Message-ID: <553EB3A4.9090107@yandex.ru> Date: Tue, 28 Apr 2015 01:09:40 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> In-Reply-To: <83r3r5wqwv.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/27/2015 06:07 PM, Eli Zaretskii wrote: > This puts you at the first line of find-tag, without showing the other > possible symbols whose names contain "find-tag" as their substring. > If you want the other candidates, you need to type TAB instead of RET, > and then select the one you want via the usual completion facilities. Yes, if you want all matches, try `xref-find-apropos' (bound to `C-M-.'). Usually I prefer the new, more precise behavior of `M-.'. > I guess the elisp-mode back-end returns just one candidate, whereas > the etags back-end returns a list. But it's confusing to have such > evident differences just because you changed the back-end, I think. etags showing all matches is, in general, the limitation of the tags file format. But if someone submits a patch making it more precise without creating false negatives, I'm all for it. And hey, you changed the back-end. It uses a different mechanism under the covers. *Of course* you're going to get different results, in many cases. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 22:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Stefan Monnier Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143017292624579 (code B ref 19468); Mon, 27 Apr 2015 22:16:02 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 22:15:26 +0000 Received: from localhost ([127.0.0.1]:41673 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmrJG-0006ON-13 for submit@debbugs.gnu.org; Mon, 27 Apr 2015 18:15:26 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:36212) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmrJD-0006OA-Tq for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 18:15:24 -0400 Received: by wizk4 with SMTP id k4so117118259wiz.1 for <19468@debbugs.gnu.org>; Mon, 27 Apr 2015 15:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Kp7lOW7xIari+6/1W2ROPm/37EsuI7R7N0uexZ/iGjc=; b=rdOXDjzSIgrX//8/1NbYiaNe8znbMX5kvcxvTtkFZmw9rOvbctP0xKW7Gd64r5m2ny 4/hxT6z2CiO6mIzD3UnuC2V3ezGf1ZnrwxhI+oApJmyN5+MfEG8RaLtew/QK4VuwdMbh A4c5+jA8qceUcXY1dZ69owduyL3e1zpaLGgEwRc/ABlur7GVlOYHbq8qHHvSQqYmjvJf uZ/nuiC6z7eua3rC5tzxcYcvUh63kFoWDmF/qpSOr0PJQvxn238nMJieswxEHfBc1nbx 15CKX1YP73A5wWzp1w/3NYM3tbWhr2JaciCTQhwt0vn+rnTrmTWKZDccWr0TzCRteNei b3KA== X-Received: by 10.180.160.145 with SMTP id xk17mr24535621wib.85.1430172918351; Mon, 27 Apr 2015 15:15:18 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id df1sm13446554wib.12.2015.04.27.15.15.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 15:15:18 -0700 (PDT) Message-ID: <553EB4F4.1090704@yandex.ru> Date: Tue, 28 Apr 2015 01:15:16 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> In-Reply-To: <83pp6pwqnw.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/27/2015 06:13 PM, Eli Zaretskii wrote: > I certainly hope that at least the Semantic one materializes soon > enough, otherwise it sounds like all this move to xref was for the > benefit of unbundled packages, and users of Emacs are just punished by > having to learn a new UI for no real advantage. It's probably up to CEDET developers. But the UI itself is one of the benefits. If the old one was considered superior, the new API could have been introduced without really changing the UI. >>> . The doc string of xref-find-function mentions several variants of >>> invoking the function, but there doesn't seem to be any way of >>> controlling that when invoking the function interactively, is >>> there? I think it would be good to be able to lookup only the >>> definitions or only the references of a symbol. There seems some confusion here: you do now invoke xref-find-function. It's not a function anyway, it's a variable, which different backends can set to implement the backend interface. You invoke different commands from the xref package. Try typing `M-x xref-find- TAB'. > Not from me: I've been told in this discussion that I don't understand > the new UI, don't appreciate its many virtues, and generally am no > more than an obstacle on the way of progress. I really don't remember stating that in this discussion. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 22:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier , Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143017352625440 (code B ref 19468); Mon, 27 Apr 2015 22:26:02 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 22:25:26 +0000 Received: from localhost ([127.0.0.1]:41678 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmrSt-0006cE-Up for submit@debbugs.gnu.org; Mon, 27 Apr 2015 18:25:25 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:36638) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmrSs-0006bz-6h for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 18:25:22 -0400 Received: by wizk4 with SMTP id k4so117327543wiz.1 for <19468@debbugs.gnu.org>; Mon, 27 Apr 2015 15:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=UfONkjZ8M8vcShbr8/TM/omO/hNlvi79GUxVgqRy22w=; b=afmB0xTaKYnm80ycf3v/m8QmlCh16sGF/DQRYAd7fojS1lcCWo1RaAha2JXKHRpIIi UmpLi2Wz7uqNkNoqrnEvJyXJghTj4D0aPqBQzhKkh/exzjwqvc5oDHAv9TqzA0/u6rEC L83izATnLnSLKiaSXIXdMmWp4/gU4qD3iZEddtE01O6RDsW3GGCn5il5ZL2UWCG9CTt9 1iD5FbeA7/dLWLSeDe8IdgfmbhMJ5n+7Qo0eX0qKcGW3NyAqfOHj5VKHGjPEHQpUiAlb VOjCa/u1TJIDNVcdDpw9wj5sgVUu/0Cgk2/FBTjCAj8+/Lxndu53+LYDbtMvfdXe5bO2 RQWg== X-Received: by 10.194.62.83 with SMTP id w19mr27042734wjr.40.1430173516639; Mon, 27 Apr 2015 15:25:16 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id wo10sm31271413wjb.35.2015.04.27.15.25.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 15:25:16 -0700 (PDT) Message-ID: <553EB74A.4030208@yandex.ru> Date: Tue, 28 Apr 2015 01:25:14 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/27/2015 08:21 PM, Stefan Monnier wrote: > The different ways to call xref-find-function are to distinguish > jumping to the definition or to "all uses", and currently few backends > support those features, I don't think we have a clear idea yet of how > they should be presented to the user, and there are too many variants to > collapse them all into C-u. So they'd probably be provided via > different commands instead of all being accessed via M-. M-x xref-find-references, for starters. > - (setq-local xref-find-function #'elisp-xref-find) > - (setq-local xref-identifier-completion-table-function > - #'elisp--xref-identifier-completion-table) > + (add-function :before-until (local 'xref-find-function) #'elisp-xref-find) > + (add-function :before-until (local 'xref-identifier-completion-table-function) > + #'elisp--xref-identifier-completion-table) This doesn't look right: - When I try to jump to a symbol, and there isn't one with that name, I want to see the message "no definitions found", not a "Visit tags table" prompt. - If I do have a tags table loaded, it's likely for a different project than Emacs. This is most likely true for the majority of our users. I think Eli (and everyone like-minded) should advise elisp-xref-find and xref-identifier-completion-table-function instead, inside their init script, like suggested by Daniel in another thread. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 22:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Stefan Monnier Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143017396526156 (code B ref 19468); Mon, 27 Apr 2015 22:33:01 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 22:32:45 +0000 Received: from localhost ([127.0.0.1]:41691 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymra0-0006no-UG for submit@debbugs.gnu.org; Mon, 27 Apr 2015 18:32:45 -0400 Received: from mail-wg0-f41.google.com ([74.125.82.41]:35693) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmrZy-0006na-Tl for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 18:32:43 -0400 Received: by wgyo15 with SMTP id o15so131590620wgy.2 for <19468@debbugs.gnu.org>; Mon, 27 Apr 2015 15:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=rNT51ECNRxU0JFZ47LMtfU9aN6dApSJ1J/90HRn9pVk=; b=xqqQa2wAQiK+oYamu9topS5bD77Vmz0lHrqIKA+Dos5h0POHm5mk5qq/uyoh6aRTBa yezGpmC9EMB0yMZRJb41835Aw3Dm7U+zpjf4YEd6jY+m0LebwZKqpNbswcP7y9MdlJuU 64365kDb9xlLiosW1hzo6DhHgbFKOD1RV8fY4CyCWEa4fc/Z5Zj1e6eGFqe8rJKCoweO L+DSSdP9+tOCA9jad8XnYya0dftd+O/P+8qUun4IyxMQct07GPWSTe4zxBKGQSBjJoYu TV62IRzCOkq0C1bhlk9XDxKtzfQq5e0SPphM4Vug1nR3I9y1qD0CPb/1dylTZClsmV1Z TIZQ== X-Received: by 10.180.81.200 with SMTP id c8mr23802120wiy.49.1430173957387; Mon, 27 Apr 2015 15:32:37 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id g14sm3922265wjs.47.2015.04.27.15.32.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 15:32:37 -0700 (PDT) Message-ID: <553EB903.9060000@yandex.ru> Date: Tue, 28 Apr 2015 01:32:35 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <83lhhdwfft.fsf@gnu.org> In-Reply-To: <83lhhdwfft.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/27/2015 10:15 PM, Eli Zaretskii wrote: > We shouldn't treat the Emacs core as second-rate citizen, either. A > feature as central to code development and Emacs in general as finding > definitions and references of symbols cannot thrive only (or mainly) > outside the core, IMO. So? What are you doing to help with that? Are you asking anyone currently participating in this thread to work on CEDET? > Where did you see me say I dislike it? I'm just saying that learning > a new UI for the sake of a new UI is a waste. I _am_ prepared to > learn a new UI if it brings new useful functionality with it. The new UI itself brings tangible improvements by itself, as well as a unified interface that can (and hopefully will) be used by different projects. I don't know how you don't see the value in that. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 22:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Stefan Monnier Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143017417726480 (code B ref 19468); Mon, 27 Apr 2015 22:37:02 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 22:36:17 +0000 Received: from localhost ([127.0.0.1]:41695 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmrdQ-0006t2-Uy for submit@debbugs.gnu.org; Mon, 27 Apr 2015 18:36:17 -0400 Received: from mail-wg0-f51.google.com ([74.125.82.51]:34171) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmrdO-0006sp-CS for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 18:36:15 -0400 Received: by wgso17 with SMTP id o17so131871335wgs.1 for <19468@debbugs.gnu.org>; Mon, 27 Apr 2015 15:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=TqNOOPnDxlmmDlA8JfBJ6/yzNsiiBFaimDnuxneiawE=; b=EFGh1aEpAw8DXunv5+/C3fbFyPU2Ar54wxce/6ZH8lSTZkBiBHf91Fa0IIeULIyOIF skKvsS1UJuoMT7s4aw/CY5+r0avqQm792GBlDhHGkiIaO1nZqe6tQ7gvH8X8xv+BgwTr ZWmbSNeu2dLeh5nEpLgHJ9FcenNfMjf0tKIHw4PvGA+vnq3QbN7tsO+72c7vcRkm42kO Uj7b/pSl3b9u6kEcYdlFcaTPN3bnNrAbxPcDS7XCHn1gi0cm1o90UtatYqTxkaGUtRK5 s+ulAShtqAKTHxDDahYXTJ3rTV33mc48wUwXQOX6UHqTuIX4lpr8p34inS+3OKwAZa7M cjqw== X-Received: by 10.180.94.39 with SMTP id cz7mr23820388wib.66.1430174168872; Mon, 27 Apr 2015 15:36:08 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id gi17sm31275983wjc.8.2015.04.27.15.36.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 15:36:08 -0700 (PDT) Message-ID: <553EB9D7.7010002@yandex.ru> Date: Tue, 28 Apr 2015 01:36:07 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <83k2wxwexb.fsf@gnu.org> In-Reply-To: <83k2wxwexb.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/27/2015 10:26 PM, Eli Zaretskii wrote: > And btw, there is another confusing difference between these back-ends > that somehow bubbles up to the UI level: the elisp-mode back-end only > supports finding multiple matches via completion, and completion, at > least by default, only finds candidates whose leading substring > matches what you type. The substring vs. prefix matching is an interesting distinction. Our completion tables only work with prefix matching. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 22:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier , Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143017466427153 (code B ref 19468); Mon, 27 Apr 2015 22:45:02 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 22:44:24 +0000 Received: from localhost ([127.0.0.1]:41699 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmrlI-00073s-6E for submit@debbugs.gnu.org; Mon, 27 Apr 2015 18:44:24 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:35719) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmrlG-00073d-DM for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 18:44:22 -0400 Received: by widdi4 with SMTP id di4so117505271wid.0 for <19468@debbugs.gnu.org>; Mon, 27 Apr 2015 15:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QYfkBvKSwMIYgKaifxpxqD834OiEkxh0lCutD/nLmTs=; b=r4GNwgEYL9uZtqoMcnYq/xEYN/ZnPixsSjAKYig9CbnzOb8R35My4gTqkZ5vgzLWe3 em0cIfGYa5ehWvuMJBSXMaVZHmLIuMcjeQom+H8KjmTuZVuRjuyKIXoXLHd0UXT0aYVt lyk9wEZPRTMZ8qDYgIJ2/YSGycw07cw2rmv6m/BnFye4h0Hz7gmIr9Rg9pCY1aT9tME6 Bbf15FeCOxRSzvGq4TFtD2Rk5smB+2iCeEOSU3IqgD/18GvpSKk8zUPZgInbxRstwNql ljJVemWb6ZLAIQvpuY2IqTlD6FAKMBQm0InuC03u/SW7YqkiQ6f6bROX3duRgTRL6Xk9 kjPw== X-Received: by 10.180.218.108 with SMTP id pf12mr24943446wic.13.1430174656831; Mon, 27 Apr 2015 15:44:16 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id wr2sm31334919wjb.45.2015.04.27.15.44.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 15:44:16 -0700 (PDT) Message-ID: <553EBBBF.6070509@yandex.ru> Date: Tue, 28 Apr 2015 01:44:15 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/27/2015 08:35 PM, Stefan Monnier wrote: >> btw the defun I'm probably after is not the first or second hit there; >> looks like the candidates are arranged in the alphabetical order of >> the *.el files). > > Indeed, the ordering looks incorrect. This is a bug. The idea here is to group candidates belonging to different files together. Sorting the files alphabetically after that is the first natural choice, but how else to do it better? - Should xref always try to preserve the order in which xrefs are returned? Some backends might not mean anything by it. - Suppose one xref in a.el is returned before all xrefs in b.el. And another xref in a.el is returned after. In what order will we display a.el and b.el? From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 22:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier , Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143017475827364 (code B ref 19468); Mon, 27 Apr 2015 22:46:02 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 22:45:58 +0000 Received: from localhost ([127.0.0.1]:41703 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymrmn-00077I-SZ for submit@debbugs.gnu.org; Mon, 27 Apr 2015 18:45:58 -0400 Received: from mail-wi0-f182.google.com ([209.85.212.182]:34911) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymrml-000771-Cd for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 18:45:55 -0400 Received: by widdi4 with SMTP id di4so117534699wid.0 for <19468@debbugs.gnu.org>; Mon, 27 Apr 2015 15:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sQsJNGDi4DlVTcIuxK2sE2ECL/bIjpRUlwII52wGgn8=; b=IM/jkZDpkrlK9VCayxskyNm7RdkCLVbIj+ytg3gBjojAR0V3FpFD8lVi/vlbWFkAKf yEDNwEFn39vDUygSfKwxWXfAWnPHMcaYSvmU+Veb0lC3I1B2zuYOOPgWduA/hX+yeuaX XrrtEXS4/sgalqClBApYyEqUJkmqoAvktRA53CiXQ/88O9jdgJAnjS1K60+AnJNbKmCA UHZL+GML7zMcr+boghY2zmQEmcc5gyCr5SMX9LbxsFF/XsjS0OEObtxPZg3nXaYxlvl6 BQA18s33M30AVAIcyASc7WxoJJCIloGlNtGB+MrODrOy+QSO+dzK6VJNJz1a4m4LLjOI AXJA== X-Received: by 10.180.74.37 with SMTP id q5mr24601261wiv.59.1430174749728; Mon, 27 Apr 2015 15:45:49 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id b10sm13536256wiz.9.2015.04.27.15.45.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 15:45:49 -0700 (PDT) Message-ID: <553EBC1C.4050705@yandex.ru> Date: Tue, 28 Apr 2015 01:45:48 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <83k2wxwexb.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/28/2015 12:54 AM, Stefan Monnier wrote: > Maybe we should write an xref-old-ui-mode. > It would make M-. always prompt and it would always jump to the first > entry and then let you use C-u M-. to jump to the next match. That's doable, but it's not high on my priorities list. In case anyone's wondering. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 22:55:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Eli Zaretskii , 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143017525028101 (code B ref 19468); Mon, 27 Apr 2015 22:55:03 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 22:54:10 +0000 Received: from localhost ([127.0.0.1]:41711 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymruj-0007JA-Gz for submit@debbugs.gnu.org; Mon, 27 Apr 2015 18:54:09 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:49816) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymrui-0007J3-Jx for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 18:54:08 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t3RMs5VN026762; Mon, 27 Apr 2015 18:54:05 -0400 Received: by pastel.home (Postfix, from userid 20848) id 7C1401E3F; Mon, 27 Apr 2015 18:54:05 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> Date: Mon, 27 Apr 2015 18:54:05 -0400 In-Reply-To: <553EB74A.4030208@yandex.ru> (Dmitry Gutov's message of "Tue, 28 Apr 2015 01:25:14 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5289=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5289> : inlines <2804> : streams <1429683> : uri <1917103> X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > - When I try to jump to a symbol, and there isn't one with that name, I want > to see the message "no definitions found", not a "Visit tags table" prompt. I tend to agree. > - If I do have a tags table loaded, it's likely for a different project than > Emacs. This is most likely true for the majority of our users. I really think the etags backend should only return data when the TAGS file is in one of the parents of the current directory. And it should also be able to keep several independent TAGS tables opened for different projects in different directory trees. > I think Eli (and everyone like-minded) should advise elisp-xref-find and > xref-identifier-completion-table-function instead, inside their init script, > like suggested by Daniel in another thread. It seems a common enough request that we should accommodate them better. At the very least provide a minor mode which sets up such advice. Stefan From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 23:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143017652230064 (code B ref 19468); Mon, 27 Apr 2015 23:16:01 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 23:15:22 +0000 Received: from localhost ([127.0.0.1]:41743 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmsFG-0007op-2v for submit@debbugs.gnu.org; Mon, 27 Apr 2015 19:15:22 -0400 Received: from mail-wg0-f46.google.com ([74.125.82.46]:34059) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmsFD-0007oZ-Ln for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 19:15:20 -0400 Received: by wgso17 with SMTP id o17so132542920wgs.1 for <19468@debbugs.gnu.org>; Mon, 27 Apr 2015 16:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=q9hNKngJinaCmZhyTO7SxrSAXxHCWZcmKvFg6bJA+VE=; b=vhEVr9yUwlAuE7bWlBIg9lm0u92cVLJQtoehFFaXeS3A+oY4Ij9ETXTbapEHHz7zWz C+R1Aq+7uwhpZGuaSer78TEEsneoBfwDb7Pqw13oXCPSR2yNtlCSmXCh9GkbyccYOeZv BsMPQN7bx7GhO8wjEO7KIpXdm13TPK0fawY0gPsO16w97hu04WztzJ98IDVZbHfVb/+y MIWEyj5vd9rMgl6T0YjVqN90dTY3VVfq+nDeBMv6AgbCFvaBHoen3lyNiWfxu8ug2vWP 0Ku2ZUKOIIVkfLNHFZJxjdvcM4pGeWeudOMAfgDs0pSa60enClpHZLdOw8Y71UI/UdRB 0wOA== X-Received: by 10.194.193.66 with SMTP id hm2mr2478240wjc.111.1430176514187; Mon, 27 Apr 2015 16:15:14 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id mv11sm13587765wic.23.2015.04.27.16.15.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 16:15:14 -0700 (PDT) Message-ID: <553EC300.9030904@yandex.ru> Date: Tue, 28 Apr 2015 02:15:12 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/28/2015 01:54 AM, Stefan Monnier wrote: > I really think the etags backend should only return data when the TAGS > file is in one of the parents of the current directory. That goes against what Eli asked for in the past, though. And unless loading of the TAGS file happens automatically (another change), this will do away with the convenience of the automatic suggestion when I do want to use etags. > It seems a common enough request that we should accommodate > them better. At the very least provide a minor mode which sets up > such advice. But how common is it, really? I've only seen one person ask for it so far. Surely the 5 or so people who actually use tags with Elisp are a distinct minority compared to the whole Emacs user base. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 23:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Eli Zaretskii , 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143017655930113 (code B ref 19468); Mon, 27 Apr 2015 23:16:02 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 23:15:59 +0000 Received: from localhost ([127.0.0.1]:41746 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmsFq-0007pc-Np for submit@debbugs.gnu.org; Mon, 27 Apr 2015 19:15:59 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:41806) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmsFo-0007pT-Nq for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 19:15:57 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t3RNFtIZ004825; Mon, 27 Apr 2015 19:15:55 -0400 Received: by pastel.home (Postfix, from userid 20848) id 6D28E1E3F; Mon, 27 Apr 2015 19:15:55 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <83k2wxwexb.fsf@gnu.org> <553EB9D7.7010002@yandex.ru> Date: Mon, 27 Apr 2015 19:15:55 -0400 In-Reply-To: <553EB9D7.7010002@yandex.ru> (Dmitry Gutov's message of "Tue, 28 Apr 2015 01:36:07 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5289=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5289> : inlines <2804> : streams <1429692> : uri <1917112> X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) >> And btw, there is another confusing difference between these back-ends >> that somehow bubbles up to the UI level: the elisp-mode back-end only >> supports finding multiple matches via completion, and completion, at >> least by default, only finds candidates whose leading substring >> matches what you type. > The substring vs. prefix matching is an interesting distinction. Our > completion tables only work with prefix matching. While the underlying completion tables indeed only provide prefix completion, the normal completion UI provides the `substring' completion style. Stefan From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 23:20:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Eli Zaretskii , 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143017676130435 (code B ref 19468); Mon, 27 Apr 2015 23:20:03 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 23:19:21 +0000 Received: from localhost ([127.0.0.1]:41751 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmsJ6-0007uo-Nf for submit@debbugs.gnu.org; Mon, 27 Apr 2015 19:19:21 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:53873) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmsJ4-0007ue-6C for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 19:19:18 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t3RNJGwN028342; Mon, 27 Apr 2015 19:19:16 -0400 Received: by pastel.home (Postfix, from userid 20848) id 794491E3F; Mon, 27 Apr 2015 19:19:16 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> Date: Mon, 27 Apr 2015 19:19:16 -0400 In-Reply-To: <553EBBBF.6070509@yandex.ru> (Dmitry Gutov's message of "Tue, 28 Apr 2015 01:44:15 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5289=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5289> : inlines <2804> : streams <1429693> : uri <1917113> X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) >>> btw the defun I'm probably after is not the first or second hit there; >>> looks like the candidates are arranged in the alphabetical order of >>> the *.el files). >> Indeed, the ordering looks incorrect. This is a bug. > The idea here is to group candidates belonging to different > files together. That makes a lot of sense when the candidates are equally likely to be The One that the user's looking for. In the case of etags I think the problem comes from the substring matching it uses. Can't etags do better than substring matching and only return matches that actually have the requested name (and maybe fallback on substring matching if there's no exact match)? Stefan From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 23:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143017715231029 (code B ref 19468); Mon, 27 Apr 2015 23:26:02 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 23:25:52 +0000 Received: from localhost ([127.0.0.1]:41759 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmsPP-00084P-M1 for submit@debbugs.gnu.org; Mon, 27 Apr 2015 19:25:51 -0400 Received: from mail-wg0-f47.google.com ([74.125.82.47]:34338) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmsPO-00084B-3K for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 19:25:50 -0400 Received: by wgso17 with SMTP id o17so132713216wgs.1 for <19468@debbugs.gnu.org>; Mon, 27 Apr 2015 16:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QNUQJzBgf66Qw+zIvXDr3veZXy3IpbSuPSa57az+AJE=; b=v3+hFiR53XE4zt8Kdb0ARIi2RMpzI+MXRPrKkcE9ny5AtT4xWEZCKBr4eE5XkUTaZh PqGzAVoCjlNTqbgNvByO6Ro5lcBKXE54pRM/uBCGqT9Z4On669fu0afSwcfO4BDJ51sz 7KCbbzhMR+EUVc2Cp00ouQ/JY0EzNfz41HsmU48YQW67duzLduya7Rpzo7IH0Ea29MDn 30zIXx1DhVJ2f5JdVq5DiF4SCzMirYXx165ExBy4qLf70QVAQqOvFCDje29tS9q0fwrW lg9qa+kaPefxCeqtkV5WmhzZly0K6+E77T5O6URmr5yGFFeQl7j99+x6ZBTI7t2kzsqE 4tOA== X-Received: by 10.180.37.3 with SMTP id u3mr24738247wij.43.1430177144546; Mon, 27 Apr 2015 16:25:44 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id v3sm13641988wix.8.2015.04.27.16.25.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 16:25:44 -0700 (PDT) Message-ID: <553EC576.70903@yandex.ru> Date: Tue, 28 Apr 2015 02:25:42 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <83k2wxwexb.fsf@gnu.org> <553EB9D7.7010002@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/28/2015 02:15 AM, Stefan Monnier wrote: > While the underlying completion tables indeed only provide prefix > completion, the normal completion UI provides the `substring' > completion style. We can't use that in minibuffer though, right? From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 23:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14301784731467 (code B ref 19468); Mon, 27 Apr 2015 23:48:02 +0000 Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 23:47:53 +0000 Received: from localhost ([127.0.0.1]:41771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymski-0000NZ-5v for submit@debbugs.gnu.org; Mon, 27 Apr 2015 19:47:53 -0400 Received: from mail-wi0-f171.google.com ([209.85.212.171]:35400) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymskf-0000N6-DM for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 19:47:50 -0400 Received: by widdi4 with SMTP id di4so118735495wid.0 for <19468@debbugs.gnu.org>; Mon, 27 Apr 2015 16:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=PykAzdGCTuwRZA61OyS7c6znCe8p4RjmXiMJg+ilm+M=; b=rYVFGjs9RTHsCQi9UL5q6RU6VM9Mynqe7ak7Gz+QHleIt+cfnzYl43VRjfT3BB4Kk3 RKOoPNiGfMZRNeVT4GT+BgKwxChcv2RTreVLXeOf3QgEMR7798vUWdvC73Mns5Yqx2jk 5ZDhk4Pi2n8UC6Sjtub08kaF3BMntgXWqeeJVUJ4N2JiAZCs8wH4QC04klZawecpp8pe M2KCLaNhqtNY5YsgEkU54RU95awlG87/pSx/CZvfZNe2+x/kx8kh+DQBObKk6lYVDSh3 VFp2+ORLcBepPn1fwDKjaAZ104vpjT6UBwpatO06mMdDbLLzaQysKm/QOhntVjwf3EkE MseQ== X-Received: by 10.180.8.34 with SMTP id o2mr24668738wia.18.1430178463764; Mon, 27 Apr 2015 16:47:43 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id kc4sm31456692wjc.2.2015.04.27.16.47.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 16:47:43 -0700 (PDT) Message-ID: <553ECA9D.6090306@yandex.ru> Date: Tue, 28 Apr 2015 02:47:41 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> In-Reply-To: <837fszx7iy.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/26/2015 05:56 PM, Eli Zaretskii wrote: > emacs -Q > M-x xref-et TAB => [No match] > > It should be autoloaded, IMO. Perhaps there should also be a > global minor mode, for those who'd like that. I don't know if we want to settle on that solution, actually. Have you seen this thread? http://lists.gnu.org/archive/html/emacs-devel/2015-04/msg01236.html That's not so easy to wrap in a global minor mode. I'm not even sure a minor mode would be a good approach here at all. However, it's a lot more flexible than using xref-etags-mode, especially with the changes to help buffers proposed by Daniel. > . It does nothing when point is on a unique symbol: > > M-. set_cursor_from_row RET > Now, with point on its position under set_cursor_from_row, type > M-. again => nothing(??!!) happens > > I guess it looks for more symbols matching set_cursor_from_row, > finds out that this is the only one, and does nothing. This is > not useful. It should at the very least say something like > "set_cursor_from_row: this is the only match". `M-x find-tag' behaves exactly the same: even when the result is that we don't move anywhere (for the same reason), there's no helpful message. Just "Mark set" in the echo area. I don't know if adding a new message in this case will be too helpful, but you're welcome to suggest the wording. > Bonus points for > prompting for a symbol, like it does when there's no symbol at > point, because I think this is more useful in this situation. I'd take a look at the patch. > . Some problems with key bindings in the *xref* buffer: > > . RET displays the candidate listed on the current line, but > closes the window displaying *xref*, so it's not easy to try > another candidate afterwards. There's also the `C-o' binding, which displays the xref, but keeps the current focus. > I think it would be more helpful > to just switch to the window showing the definition, but leave > the *xref* buffer shown. Some packages take this approach; I don't like it. But this should be easy to implement with a user option that would slightly change the behavior of `xref-goto-xref'. Care to take a stab at it? > . You need to use the unconventional '.' and ',' to both move and > display the definitions -- this should at least be mentioned in > the initial echo-area message when *xref* is first displayed. > (This was reported as a problem in the original report, but > seems to be left unchanged.) Should those be `n' and `p' instead, by default? I've found myself using these bindings very rarely anyway, and `n' is still very close. > (Other similar Emacs modes, > like Compilation and Grep, do provide commands to move to the > next item without first switching to the buffer that shows all > the hits.) Compilation and Grep both use M-g M-n/M-g M-p, and the next-error-function variable. Do you want xref to reuse it? Would you be comfortable with forgetting the current list of errors after navigating somewhere with xref? > But what are the alternatives, if any? I could only find > something related in ada-mode and in elisp-mode. This means > that, for example, for C/C++ and Java, etags is the only > available back-end, and this change is currently just a different > UI wrapping the same basic functionality? Is there any further > development planned for the near future? There's also ggtags in GNU ELPA. I'm sure it could provide some integration, too. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 00:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier , Dmitry Gutov Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14301792924146 (code B ref 19468); Tue, 28 Apr 2015 00:02:02 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 00:01:32 +0000 Received: from localhost ([127.0.0.1]:41779 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymsxt-00014d-46 for submit@debbugs.gnu.org; Mon, 27 Apr 2015 20:01:30 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:36746) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymsxp-00014G-TM for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 20:01:26 -0400 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t3S01JTo015549 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Apr 2015 00:01:19 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t3S01JI9005149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Apr 2015 00:01:19 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t3S01IQZ027804; Tue, 28 Apr 2015 00:01:19 GMT MIME-Version: 1.0 Message-ID: <85733e8a-0064-4ccb-89bc-f450ba7bfcb5@default> Date: Mon, 27 Apr 2015 17:01:18 -0700 (PDT) From: Drew Adams References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0022.oracle.com [156.151.31.74] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > > - When I try to jump to a symbol, and there isn't one with that > > name, I want to see the message "no definitions found", not a > > "Visit tags table" prompt. >=20 > I tend to agree. IIUC, that seems a bit ironic. You took the opposite point of view when I said the same thing about `completion-styles' that you seem to be saying here. I made just that argument: let users know when a given completion method finds no matches, and let them choose whether to go on to trying another method. This seems similar - the difference being that instead of different ways of matching completion candidates you are dealing with different "backends" their candidate sets. Giving users feedback such as "No definitions found" and "No completions", instead of blindly going on to look for other hits using other means, is helpful and gives them more control. At the very least it should be an option: let them decide whether to go on automatically to other attempts. Which is also the argument I made wrt `completion-styles': let users choose which styles should chain automatically to which others, by grouping them. No group(s) means no automatic chaining. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 00:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14301806547962 (code B ref 19468); Tue, 28 Apr 2015 00:25:02 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 00:24:14 +0000 Received: from localhost ([127.0.0.1]:41799 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmtJt-00024J-1d for submit@debbugs.gnu.org; Mon, 27 Apr 2015 20:24:13 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:36571) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmtJq-00023x-Hz for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 20:24:11 -0400 Received: by wizk4 with SMTP id k4so119639019wiz.1 for <19468@debbugs.gnu.org>; Mon, 27 Apr 2015 17:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hxz86fYR5DzuFFOcHqniJbEkUcF5ttP/8qZuEnSr9aU=; b=KogWb8BaL/MsbitR0WJ/V0zEvY4bAqWCfFKbK7DTNgVcHGw0alNy9LcltF0rJImh7e 4Jqf5HOuPnJEOhnDMIUz3+Fh1r2WwIxGaYOmXEyalCbDqfUBMIwxC8nz99ozRfUQpUNH 9OkKp8XSUuuYbSMDllIDpGvpCYCryoImTTt2CECrfq6Xaz0xj3Jw5GR5swhzi0RIiMag TyHe64ZxN0X2R7MoBoq/CUuOEEO+J2RlybnD5BTsk9q2Jvnn4CwumAnOndlBO2Dxqbrq Il+E+0/lBP7zSsGqzj8ah3eoQrqFHu6dC35lhOUYPWjeVKrO4OTLaqhi/H4VdTJwEuVn ++4g== X-Received: by 10.180.97.7 with SMTP id dw7mr25172882wib.74.1430180645084; Mon, 27 Apr 2015 17:24:05 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id b10sm13784765wiz.9.2015.04.27.17.24.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 17:24:04 -0700 (PDT) Message-ID: <553ED323.6080603@yandex.ru> Date: Tue, 28 Apr 2015 03:24:03 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/28/2015 02:19 AM, Stefan Monnier wrote: >> The idea here is to group candidates belonging to different >> files together. ^^^ to the same file, sorry. > That makes a lot of sense when the candidates are equally likely to be > The One that the user's looking for. In the case of etags I think the > problem comes from the substring matching it uses. etags puts some effort into returning the candidates in the most plausible way. Should we ignore that? etags--xref-find-definitions tries to honor it, at least according to the comment. Further, xref-find-apropos will return a lot of candidates, and that will be what the user wants. > Can't etags do better than substring matching and only return matches > that actually have the requested name (and maybe fallback on substring > matching if there's no exact match)? I don't know if this problem is solvable in a generic way. How reliable is tag-exact-match-p? We could, for instance, filter out all non-exact matches when we're just looking for definitions. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 01:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143018436122917 (code B ref 19468); Tue, 28 Apr 2015 01:26:02 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 01:26:01 +0000 Received: from localhost ([127.0.0.1]:41819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmuHg-0005xY-GO for submit@debbugs.gnu.org; Mon, 27 Apr 2015 21:26:00 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:10611) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmuHd-0005xD-VJ for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 21:25:59 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFAGvvdVRMCqjW/2dsb2JhbAA3gVOfQYIugQiBdQEBBAFWIwULCw4mEhQYDSSIE6IRi3YoAwk6DAODPgODcASjY4RY X-IPAS-Result: AnEFAGvvdVRMCqjW/2dsb2JhbAA3gVOfQYIugQiBdQEBBAFWIwULCw4mEhQYDSSIE6IRi3YoAwk6DAODPgODcASjY4RY X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="117610604" Received: from 76-10-168-214.dsl.teksavvy.com (HELO pastel.home) ([76.10.168.214]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Apr 2015 21:25:52 -0400 Received: by pastel.home (Postfix, from userid 20848) id DFFBF187C; Mon, 27 Apr 2015 21:25:51 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <553EC300.9030904@yandex.ru> Date: Mon, 27 Apr 2015 21:25:51 -0400 In-Reply-To: <553EC300.9030904@yandex.ru> (Dmitry Gutov's message of "Tue, 28 Apr 2015 02:15:12 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> I really think the etags backend should only return data when the TAGS >> file is in one of the parents of the current directory. > That goes against what Eli asked for in the past, though. Yes, we've been through that, indeed. But it can be accomodated by requiring the user to explicitly say that some TAGS file covers "these and these extra directory trees" or to link TAGS file together. > And unless loading of the TAGS file happens automatically (another change), > this will do away with the convenience of the automatic suggestion when I do > want to use etags. The automatic suggestion could be restricted to only come about when there is a TAGS file in one of the parent dirs. > But how common is it, really? I've only seen one person ask for it so > far. Surely the 5 or so people who actually use tags with Elisp are > a distinct minority compared to the whole Emacs user base. Could be. But etags has been around for a long time and was the only "standard feature" of the kind until very recently in Emacs, so I think it's fair to assume that there are more such users out there. Stefan From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 01:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Eli Zaretskii , 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143018439823022 (code B ref 19468); Tue, 28 Apr 2015 01:27:01 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 01:26:38 +0000 Received: from localhost ([127.0.0.1]:41823 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmuII-0005zG-7N for submit@debbugs.gnu.org; Mon, 27 Apr 2015 21:26:38 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:39134) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmuIG-0005yx-9O for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 21:26:36 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFAGvvdVRMCqjW/2dsb2JhbAA3gVOfQYIugQiBdQEBBAFWIxALDiYSFBgNJIgTohGMZAkBAgECgz4Dg3AEo2OEWA X-IPAS-Result: AnEFAGvvdVRMCqjW/2dsb2JhbAA3gVOfQYIugQiBdQEBBAFWIxALDiYSFBgNJIgTohGMZAkBAgECgz4Dg3AEo2OEWA X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="117610629" Received: from 76-10-168-214.dsl.teksavvy.com (HELO pastel.home) ([76.10.168.214]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Apr 2015 21:26:30 -0400 Received: by pastel.home (Postfix, from userid 20848) id C1E3C187C; Mon, 27 Apr 2015 21:26:30 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <83k2wxwexb.fsf@gnu.org> <553EB9D7.7010002@yandex.ru> <553EC576.70903@yandex.ru> Date: Mon, 27 Apr 2015 21:26:30 -0400 In-Reply-To: <553EC576.70903@yandex.ru> (Dmitry Gutov's message of "Tue, 28 Apr 2015 02:25:42 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> While the underlying completion tables indeed only provide prefix >> completion, the normal completion UI provides the `substring' >> completion style. > We can't use that in minibuffer though, right? Of course we can (and we do for example in C-x b). Stefan From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 01:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143018490824435 (code B ref 19468); Tue, 28 Apr 2015 01:36:01 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 01:35:08 +0000 Received: from localhost ([127.0.0.1]:41828 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmuQV-0006M0-AB for submit@debbugs.gnu.org; Mon, 27 Apr 2015 21:35:07 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:19791) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmuQS-0006LN-RJ for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 21:35:05 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFAGvvdVRMCqjW/2dsb2JhbAA3gVOfQYIugQiBdQEBBAFWIwULCw4mEhQYDSSIE6IRjAIEGEYJAwODPgODcASjY4RY X-IPAS-Result: AnEFAGvvdVRMCqjW/2dsb2JhbAA3gVOfQYIugQiBdQEBBAFWIwULCw4mEhQYDSSIE6IRjAIEGEYJAwODPgODcASjY4RY X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="117611225" Received: from 76-10-168-214.dsl.teksavvy.com (HELO pastel.home) ([76.10.168.214]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Apr 2015 21:34:59 -0400 Received: by pastel.home (Postfix, from userid 20848) id 530C6187C; Mon, 27 Apr 2015 21:34:57 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> <553ED323.6080603@yandex.ru> Date: Mon, 27 Apr 2015 21:34:57 -0400 In-Reply-To: <553ED323.6080603@yandex.ru> (Dmitry Gutov's message of "Tue, 28 Apr 2015 03:24:03 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> That makes a lot of sense when the candidates are equally likely to be >> The One that the user's looking for. In the case of etags I think the >> problem comes from the substring matching it uses. > etags puts some effort into returning the candidates in the most plausible > way. Indeed. > Should we ignore that? IIUC, in the current xref/etags code, it seems we do ignore that, apparently because of the reordering. > Further, xref-find-apropos will return a lot of candidates, and that will be > what the user wants. For xref-find-apropos that's fine. But not for M-. > How reliable is tag-exact-match-p? Don't know. > We could, for instance, filter out all > non-exact matches when we're just looking for definitions. I think that would make sense, yes. Stefan From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 01:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143018507424838 (code B ref 19468); Tue, 28 Apr 2015 01:38:01 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 01:37:54 +0000 Received: from localhost ([127.0.0.1]:41832 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmuTC-0006SW-7r for submit@debbugs.gnu.org; Mon, 27 Apr 2015 21:37:54 -0400 Received: from mail-wi0-f171.google.com ([209.85.212.171]:36770) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmuT9-0006S8-Jj for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 21:37:52 -0400 Received: by wizk4 with SMTP id k4so121028860wiz.1 for <19468@debbugs.gnu.org>; Mon, 27 Apr 2015 18:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=yRRh/DA0LmNeJ0u76xWZcS7wwYQsE/wd9CmEaCQcTqo=; b=hzb/twUWWe4uJ/U0aCX6cQWwocN/Y/C8beiFs3pNfFU8CUgxD55F/iqSir5M26+tXj EjRheExnKtChmkGKIyWpR9Rii5890DJ+N5B7NpErfOfoZy/3SDgu9+uD+dJJdIA+YORN i4XMGB9Y9qnZwmb/9FBzF0L8ksqSTNmK0m71vKySKiQD0sTWSZI5pbMEudxj+lmsJ32j Sly51sQVwmdijsZC19WtM+ofA6a+x1LlQ/j9UMB/BukXp+ptsB1xTN0jMb5bjFqLvJPz lCRgeYWtR9rgvMVt4Xgn3/v0q0/FET15skulnZ/bRIJVGVXQrWpgkAM+1ppg96tM5fPH rtVw== X-Received: by 10.194.62.83 with SMTP id w19mr28071761wjr.40.1430185065843; Mon, 27 Apr 2015 18:37:45 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id q4sm31747638wja.24.2015.04.27.18.37.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 18:37:45 -0700 (PDT) Message-ID: <553EE468.4070203@yandex.ru> Date: Tue, 28 Apr 2015 04:37:44 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <83k2wxwexb.fsf@gnu.org> <553EB9D7.7010002@yandex.ru> <553EC576.70903@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/28/2015 04:26 AM, Stefan Monnier wrote: > Of course we can (and we do for example in C-x b). Is that because in that case the collection is not a function? From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 02:16:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143018731528461 (code B ref 19468); Tue, 28 Apr 2015 02:16:03 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 02:15:15 +0000 Received: from localhost ([127.0.0.1]:41837 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymv3K-0007Oy-LW for submit@debbugs.gnu.org; Mon, 27 Apr 2015 22:15:15 -0400 Received: from mail-wi0-f180.google.com ([209.85.212.180]:37747) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymv3I-0007Ol-20 for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 22:15:12 -0400 Received: by widdi4 with SMTP id di4so11623447wid.0 for <19468@debbugs.gnu.org>; Mon, 27 Apr 2015 19:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=mCy9AvmA3UB4GDA6OE9f5NwqLOr7QAsJMcH8sgyAASg=; b=hz67kyImKJqNt9Nj2uoajPIFR196aQXSOf6noONhu5xpQ17RmoeppI+6gEjynK9a7h NYs7W2z5QzEIlm3p9XSzPkRc1Ehy5C9xiJipZ/PpYgeWayfDHs4ft8y50quhW8TkegZg 1ukpZaeqcOVO7n7U7pI4XVWJKZXs3i67Qnjyhi1PbB64mzI2ImLwKru0Ms9NI0m4bBzW zWB508WHyiLGcojbHjXn5N7I+Xuh2YmAaEzTwjSPc7/H4AGNa1ddTYP6iuwgnt3vDgoC TrCSk5JOc99Hy0N2pxSJmzo0TexCIzzZU+C9xNbBnRNO1d1cg2dI38Gbi5An1xwNP0G8 Wtpw== X-Received: by 10.180.160.145 with SMTP id xk17mr25738711wib.85.1430187306593; Mon, 27 Apr 2015 19:15:06 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id z12sm31824667wjq.12.2015.04.27.19.15.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 19:15:06 -0700 (PDT) Message-ID: <553EED28.5050902@yandex.ru> Date: Tue, 28 Apr 2015 05:15:04 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <553EC300.9030904@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/28/2015 04:25 AM, Stefan Monnier wrote: > Yes, we've been through that, indeed. But it can be accomodated by > requiring the user to explicitly say that some TAGS file covers "these > and these extra directory trees" or to link TAGS file together. Well, that's a bigger project than the 4-line patch you've suggested, and it requires manual intervention from the user. You suggested it before too, and I don't remember Eli being very enthusiastic. > The automatic suggestion could be restricted to only come about when > there is a TAGS file in one of the parent dirs. That won't help when I'm inside Emacs sources; I still don't want to use tags for Elisp. > Could be. But etags has been around for a long time and was the only > "standard feature" of the kind until very recently in Emacs, so I think > it's fair to assume that there are more such users out there. etags might be popular (so some sort a general solution might be welcome), but that doesn't mean it's used with Elisp a lot. For instance, if we consider Debian-like distributions, https://packages.debian.org/jessie/all/emacs24-el/filelist does not include the TAGS file. I don't think the C sources are generally included in the binary distributions. And if we're just talking about Emacs developers, I wonder why nobody else spoke up on emacs-devel or in this bug yet. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 13:32:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Eli Zaretskii , 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14302278713192 (code B ref 19468); Tue, 28 Apr 2015 13:32:03 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 13:31:11 +0000 Received: from localhost ([127.0.0.1]:42176 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn5bR-0000pO-QG for submit@debbugs.gnu.org; Tue, 28 Apr 2015 09:31:10 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:9735) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn5bC-0000op-Nz for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 09:30:55 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFAGvvdVRMCqjW/2dsb2JhbAA3gVOfQYIugQiBdQEBBAFWIxALDiYSFBgNJIgTohGLfGgJAwECgz4Dg3AEo2OEWA X-IPAS-Result: AnEFAGvvdVRMCqjW/2dsb2JhbAA3gVOfQYIugQiBdQEBBAFWIxALDiYSFBgNJIgTohGLfGgJAwECgz4Dg3AEo2OEWA X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="117676200" Received: from 76-10-168-214.dsl.teksavvy.com (HELO pastel.home) ([76.10.168.214]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2015 09:30:49 -0400 Received: by pastel.home (Postfix, from userid 20848) id 9A92ECC6; Tue, 28 Apr 2015 09:30:48 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <83k2wxwexb.fsf@gnu.org> <553EB9D7.7010002@yandex.ru> <553EC576.70903@yandex.ru> <553EE468.4070203@yandex.ru> Date: Tue, 28 Apr 2015 09:30:48 -0400 In-Reply-To: <553EE468.4070203@yandex.ru> (Dmitry Gutov's message of "Tue, 28 Apr 2015 04:37:44 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> Of course we can (and we do for example in C-x b). > Is that because in that case the collection is not a function? No. As a matter of fact, in that case the collection *is* a function (which removes the current buffer from the available choices). The reason is because that `completion-metadata' says that the completion category is `buffer' and because completion-category-defaults says that for `buffer' completion, we should use the `substring' style by default. Stefan From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 13:37:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14302282063684 (code B ref 19468); Tue, 28 Apr 2015 13:37:03 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 13:36:46 +0000 Received: from localhost ([127.0.0.1]:42180 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn5gr-0000xL-96 for submit@debbugs.gnu.org; Tue, 28 Apr 2015 09:36:45 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:43741) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn5gm-0000wx-53 for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 09:36:41 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFAGvvdVRMCqjW/2dsb2JhbAA3gVOfQYIugQiBdQEBBAFWIwULCw4mEhQYDSSIE6IRjAMYA0YJAwODPgODcASjY4RY X-IPAS-Result: AnEFAGvvdVRMCqjW/2dsb2JhbAA3gVOfQYIugQiBdQEBBAFWIwULCw4mEhQYDSSIE6IRjAMYA0YJAwODPgODcASjY4RY X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="117676658" Received: from 76-10-168-214.dsl.teksavvy.com (HELO pastel.home) ([76.10.168.214]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2015 09:36:34 -0400 Received: by pastel.home (Postfix, from userid 20848) id 5AD5DCC6; Tue, 28 Apr 2015 09:36:34 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <553EC300.9030904@yandex.ru> <553EED28.5050902@yandex.ru> Date: Tue, 28 Apr 2015 09:36:34 -0400 In-Reply-To: <553EED28.5050902@yandex.ru> (Dmitry Gutov's message of "Tue, 28 Apr 2015 05:15:04 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> Yes, we've been through that, indeed. But it can be accomodated by >> requiring the user to explicitly say that some TAGS file covers "these >> and these extra directory trees" or to link TAGS file together. > Well, that's a bigger project than the 4-line patch you've suggested, Indeed, and it's largely unrelated since it would be a patch to the xref/etags backend and wouldn't touch elisp-mode.el. > and it requires manual intervention from the user. More manual interventions in some cases, and less in others. >> The automatic suggestion could be restricted to only come about when >> there is a TAGS file in one of the parent dirs. > That won't help when I'm inside Emacs sources; I still don't want to use > tags for Elisp. As mentioned, this suggestion is not directly related to other backends, so whether xref/elisp completely shadows xref/etags or not is orthogonal. BTW: Do you have a lisp/TAGS file? If so, why? Stefan From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 14:50:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 19468@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143023254410517 (code B ref 19468); Tue, 28 Apr 2015 14:50:04 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 14:49:04 +0000 Received: from localhost ([127.0.0.1]:42853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn6op-0002jY-9z for submit@debbugs.gnu.org; Tue, 28 Apr 2015 10:49:04 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:50781) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn6ol-0002j2-Sy for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 10:49:01 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NNI00400U4X9V00@a-mtaout21.012.net.il> for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 17:48:53 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNI004BHUHGAI00@a-mtaout21.012.net.il>; Tue, 28 Apr 2015 17:48:53 +0300 (IDT) Date: Tue, 28 Apr 2015 17:48:47 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83fv7kwbow.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <83k2wxwexb.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: dgutov@yandex.ru, 19468@debbugs.gnu.org > Date: Mon, 27 Apr 2015 17:54:30 -0400 > > > Emacs 24 also had "C-u M-." to go to the next one. This one doesn't; > > moreover, if you try "C-u M-.", you get prompted for the symbol again, > > and if you type the same one, you get nowhere. The other matches are > > only available via completion, see below. > > Maybe we should write an xref-old-ui-mode. I didn't ask for the old UI. (If I want it, I can still have it, since the etags.el commands are still available.) I'm okay with the new UI. This bug report is about the new UI, and its goal is to make the new UI better. > It would make M-. always prompt and it would always jump to the first > entry and then let you use C-u M-. to jump to the next match. That's not what I meant by the above. It was you who mentioned the old UI, not me. What I wanted to point out in response was that the old UI was consistent and complete: it always displayed the first/next match and provided a command to go to the next/previous one. By contrast, the new UI is inconsistent: with some back-ends it shows the list of matches and allows to navigate it, with others it shows only the first match and does not give any way to get the next match. > >> But popping up the *xref* buffer when there's only one element in it > >> doesn't make much sense I think. > > Oh, but there shouldn't be only one element: you will see the others > > if you type TAB instead of RET. > > No: there's only one definition of `find-tag' so Elisp's xref backend > just returns that one and that's it. There's more than one matching definition, see below. But that's largely immaterial: this bug report is not about the back-end, it's about the UI. The UI should be independent of the back-end, otherwise the users will be confused when they switch between languages. (If it turns out that some back-ends need to be augmented so that they allow the front-end to present similar UI for the same query, then those back-ends should be enhanced.) > > IOW, the elisp-mode back-end does know about the other candidates, it > > just doesn't show them in *xref*. > > None of the others are definitions of `find-tag'. At least one is, the one in org-ctags. And I can make a case for the others as well, because no one said partial matches found by etags are not legitimate, even if you personally don't consider them to be. > Arguably, the find-tag advice in org-ctags.el could be offered as well, > if org-ctags.el happens to be loaded ??? Why should the xref matches depend on what is and isn't loaded? That would make xref exactly equivalent to "M-x apropos", which means this mode of operation would make xref entirely redundant. To say nothing of the fact that this doesn't scale to any language except ELisp. We could offer this mode as an optional feature, but it certainly shouldn't be the default. (One of my worst annoyances is to type a C-h command and be presented with "[No match]", because some package is not loaded or some function is not available in the Emacs configuration I happen to be using.) > > It somehow decided for me that I want only the exact match. > > It's rather that the old etags interface was not sure enough of itself, > so it offered anything that had "find-tag" as a substring somewhere, > i.e. lots and lots of false positives. That's one way of looking at it. Another is to say that etags gave you more information and thus allowed to find more loose matches, which is helpful when your memory is failing you. But in the context of this bug report, that, too, is immaterial: if we think the etags back-end gives too much information, by all means let's filter it before presenting the matches. Bonus points for making the filtering optional, since some people might like that, and in some situations even you might need it. The important point for the purposes of this bug report is that the stuff presented by the UI for the same query does not differ so radically when you switch the back-end. > > And btw, there is another confusing difference between these back-ends > > that somehow bubbles up to the UI level: the elisp-mode back-end only > > supports finding multiple matches via completion, > > No. `semantic-symref-find-tags-by-name' is not a match for "show me the > definition of find-tag" and neither is "find-tag-tag". The problem here > is that the current etags xref backend returns confusingly many > so-called "matches" which are really irrelevant and should only be > included in the completions. Then let's fix the results we display with the etags back-end to show only the relevant ones. Please don't forget that currently, and probably for the foreseeable future, the etags back-end is the only one we have for most languages, so the things you dislike about it are pretty much in our face for months, if not years, to come. If we think this back-end "needs work", let's do that now. Saying that the back-end returns a confusingly large amount of bogus matches, and then switching to a UI that assumes much smarter back-ends (which don't really exist) makes very little sense to me. Whatever we do, let's make the UI more consistent and independent of the back-ends. Otherwise, we have a significant usability problem waiting to happen. > There's a difference between: > > I know the name, I need to find out its definition. > > and > > I remember the name includes something like "find-tag" > > The old code did not distinguish between the two, but the new code does. The old code attempted to support both use cases, by showing the exact match(es) first, followed by less likely ones. We do similar things in other commands. The advantages of such a method are that (1) you don't need to second-guess the user, (2) you provide only one command for the user to remember, and (3) if the user only _thinks_ she knows the name, but really doesn't, she can find the information without having to invoke another command. > I think that's an important feature of the new code in this respect. But it is incomplete without a means to get to the other possible matches in this case. To summarize my points in this sub-thread: . the UI should depend much less on the back-end, ideally not at all . there should be a way to go to the next/previous match if the *xref* buffer is not displayed (or not created in the first place); if this happens because there's only one match, we should say so explicitly . when there are more than one possible match, the UI should behave similarly, i.e. display the *xref* buffer; when there's only one match, it should _never_ display *xref*, and should display an indication of the fact that there's only one match . if the criteria for filtering of the matches are very different between the possible back-ends, there should be some agreed-upon uniform default that returns roughly the same number of matches with all back-ends, and the rest should be controlled by user options From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 14:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: monnier@iro.umontreal.ca, 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143023261410645 (code B ref 19468); Tue, 28 Apr 2015 14:51:02 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 14:50:14 +0000 Received: from localhost ([127.0.0.1]:42857 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn6pw-0002la-Ot for submit@debbugs.gnu.org; Tue, 28 Apr 2015 10:50:13 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:35348) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn6ps-0002l1-Gi for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 10:50:09 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NNI00300UF4FJ00@a-mtaout22.012.net.il> for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 17:50:01 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNI00355UJDFZ00@a-mtaout22.012.net.il>; Tue, 28 Apr 2015 17:50:01 +0300 (IDT) Date: Tue, 28 Apr 2015 17:49:55 +0300 From: Eli Zaretskii In-reply-to: <553EB3A4.9090107@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83egn4wbn0.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EB3A4.9090107@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 28 Apr 2015 01:09:40 +0300 > From: Dmitry Gutov > CC: 19468@debbugs.gnu.org > > This puts you at the first line of find-tag, without showing the other > possible symbols whose names contain "find-tag" as their substring. > If you want the other candidates, you need to type TAB instead of RET, > and then select the one you want via the usual completion facilities. > > Yes, if you want all matches, try `xref-find-apropos' (bound to `C-M-.'). Some would say it's a disadvantage to need another command. It means the user has to decide up front which one she needs. Showing the rest of matches after the exact one doesn't have this disadvantage. Once again, this bug is about the UI. The UI shows only one match with one back-end, and all of them with another. That's the problem I think we should address. > I guess the elisp-mode back-end returns just one candidate, whereas > the etags back-end returns a list. But it's confusing to have such > evident differences just because you changed the back-end, I think. > > etags showing all matches is, in general, the limitation of the tags file format. ??? How can what we show be the limitation of the format of the database where we keep the data? If we think we should not display everything, let's filter the irrelevant stuff before showing it. > But if someone submits a patch making it more precise without creating false negatives, I'm all for it. I'd generally expect the people who worked on a feature and lobbied for its introduction to be the ones who work on such significant issues with that feature. But if not, I hope that someone materializes soon. > And hey, you changed the back-end. It uses a different mechanism under the covers. *Of course* you're going to get different results, in many cases. I changed the back-end, not the UI. The UI should not depend on the back-end so much -- this is what this thread is all about. I'm okay with getting slightly different results, and I'm okay with having user options to control the amount of filtering so that I could get significantly more or less results when I need that. But presenting such widely different results _by_default_ is a terrible usability problem. Just imagine a user who needs to switch languages. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 14:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: monnier@iro.umontreal.ca, 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143023267410755 (code B ref 19468); Tue, 28 Apr 2015 14:52:02 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 14:51:14 +0000 Received: from localhost ([127.0.0.1]:42862 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn6qu-0002nO-VE for submit@debbugs.gnu.org; Tue, 28 Apr 2015 10:51:13 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:50885) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn6qq-0002mv-JY for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 10:51:09 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NNI00400UKGAS00@a-mtaout21.012.net.il> for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 17:51:02 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNI004QQUL1AI00@a-mtaout21.012.net.il>; Tue, 28 Apr 2015 17:51:02 +0300 (IDT) Date: Tue, 28 Apr 2015 17:50:55 +0300 From: Eli Zaretskii In-reply-to: <553EB4F4.1090704@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83d22owblc.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB4F4.1090704@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 28 Apr 2015 01:15:16 +0300 > From: Dmitry Gutov > CC: 19468@debbugs.gnu.org > > I certainly hope that at least the Semantic one materializes soon > enough, otherwise it sounds like all this move to xref was for the > benefit of unbundled packages, and users of Emacs are just punished by > having to learn a new UI for no real advantage. > > It's probably up to CEDET developers. I hope they are reading this. (Personally, I'd expect the back-ends for at least the most popular languages be ready before the switch to the new API and the new UI, but that's me.) > But the UI itself is one of the benefits. If the old one was considered superior, the new API could have been introduced without really changing the UI. I didn't ask for the old UI; I can still have it if I want it. This bug report is about improving the new UI. > . The doc string of xref-find-function mentions several variants of > invoking the function, but there doesn't seem to be any way of > controlling that when invoking the function interactively, is > there? I think it would be good to be able to lookup only the > definitions or only the references of a symbol. > > There seems some confusion here: you do now invoke xref-find-function. It's not a function anyway, it's a variable, which different backends can set to implement the backend interface. Then the confusion is the doc string's fault: it should make this aspect clear. And if there are no back-ends currently that support these options, I'd suggest to remove that from the doc string -- we shouldn't advertise in the docs stuff that no one implemented. > Not from me: I've been told in this discussion that I don't understand > the new UI, don't appreciate its many virtues, and generally am no > more than an obstacle on the way of progress. > > I really don't remember stating that in this discussion. Indeed, you didn't. But you are not alone in this discussion. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 14:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: monnier@IRO.UMontreal.CA, 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143023276710900 (code B ref 19468); Tue, 28 Apr 2015 14:53:02 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 14:52:47 +0000 Received: from localhost ([127.0.0.1]:42866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn6sR-0002pk-7k for submit@debbugs.gnu.org; Tue, 28 Apr 2015 10:52:47 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:53827) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn6sP-0002pT-47 for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 10:52:46 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NNI00F00U1VJ200@mtaout24.012.net.il> for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 17:43:51 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNI00F2YU93JW10@mtaout24.012.net.il>; Tue, 28 Apr 2015 17:43:51 +0300 (IDT) Date: Tue, 28 Apr 2015 17:52:32 +0300 From: Eli Zaretskii In-reply-to: <553EB74A.4030208@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83bni8wbin.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 28 Apr 2015 01:25:14 +0300 > From: Dmitry Gutov > CC: 19468@debbugs.gnu.org > > The different ways to call xref-find-function are to distinguish > jumping to the definition or to "all uses", and currently few backends > support those features, I don't think we have a clear idea yet of how > they should be presented to the user, and there are too many variants to > collapse them all into C-u. So they'd probably be provided via > different commands instead of all being accessed via M-. > > M-x xref-find-references, for starters. It doesn't seem to work for me: it says "no references found" whatever symbol I try, even those I know are referenced. What am I missing? > - If I do have a tags table loaded, it's likely for a different project than Emacs. This is most likely true for the majority of our users. etags.el supports more than one loaded tag table, so this shouldn't be a problem. > I think Eli (and everyone like-minded) should advise elisp-xref-find and xref-identifier-completion-table-function instead, inside their init script, like suggested by Daniel in another thread. Please don't make advice the default Emacs customization method. User options are much easier to use, so let's do what's possible with them, and leave advice etc. for more exotic use cases. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 14:56:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: monnier@IRO.UMontreal.CA, 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143023292611156 (code B ref 19468); Tue, 28 Apr 2015 14:56:03 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 14:55:26 +0000 Received: from localhost ([127.0.0.1]:42870 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn6uz-0002tr-1S for submit@debbugs.gnu.org; Tue, 28 Apr 2015 10:55:25 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:44115) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn6uv-0002tc-5t for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 10:55:22 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NNI00H00UDIZ900@mtaout27.012.net.il> for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 17:50:15 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNI008Y5UJRZE90@mtaout27.012.net.il>; Tue, 28 Apr 2015 17:50:15 +0300 (IDT) Date: Tue, 28 Apr 2015 17:55:03 +0300 From: Eli Zaretskii In-reply-to: <553EB903.9060000@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83a8xswbeg.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <83lhhdwfft.fsf@gnu.org> <553EB903.9060000@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 28 Apr 2015 01:32:35 +0300 > From: Dmitry Gutov > CC: 19468@debbugs.gnu.org > > We shouldn't treat the Emacs core as second-rate citizen, either. A > feature as central to code development and Emacs in general as finding > definitions and references of symbols cannot thrive only (or mainly) > outside the core, IMO. > > So? What are you doing to help with that? I filed this bug report, for starters. I then invested a non-trivial amount of my time into learning this feature, trying different things, describing my experiences, thinking about ways to improve this, etc. And I continue doing that. I hope this does help; if not, feel free to close this bug report as "won't fix" and tell me not to bother anymore. > Are you asking anyone currently participating in this thread to work on CEDET? That would be nice, yes. But I'd settle with merely having us agreed to the above statement. > Where did you see me say I dislike it? I'm just saying that learning > a new UI for the sake of a new UI is a waste. I _am_ prepared to > learn a new UI if it brings new useful functionality with it. > > The new UI itself brings tangible improvements by itself, as well as a unified interface that can (and hopefully will) be used by different projects. I don't know how you don't see the value in that. I'm saying that improvement that is only a potential one, without any feature that actually uses it, is incomplete, to say the least. If there are no back-ends that make use of these niceties, they simply don't exist as far as users are concerned, and consequently their value is purely theoretical. This feature, including the new UI and API, was introduced 4 months ago, and we still have only 2 back-ends supporting it: ELisp and Ada. All the other languages, including C/C++/Java, and other important ones, still use etags, which is said to be inadequate. Is someone working on more back-ends as we speak? If not, I see currently no practical benefits from introducing these changes. They are nothing more than infrastructure waiting for programmers to use it, and those programmers don't seem to be coming. Putting on my cynic hat, I'd say it's a solution looking for the problem. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 14:56:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: monnier@IRO.UMontreal.CA, 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143023295911208 (code B ref 19468); Tue, 28 Apr 2015 14:56:04 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 14:55:59 +0000 Received: from localhost ([127.0.0.1]:42873 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn6vW-0002uh-Un for submit@debbugs.gnu.org; Tue, 28 Apr 2015 10:55:59 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:51154) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn6vT-0002uS-O9 for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 10:55:56 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NNI00400UKGAS00@a-mtaout21.012.net.il> for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 17:55:49 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNI004UBUT1AI10@a-mtaout21.012.net.il>; Tue, 28 Apr 2015 17:55:49 +0300 (IDT) Date: Tue, 28 Apr 2015 17:55:43 +0300 From: Eli Zaretskii In-reply-to: <553EBBBF.6070509@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <838udcwbdc.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 28 Apr 2015 01:44:15 +0300 > From: Dmitry Gutov > CC: 19468@debbugs.gnu.org > > btw the defun I'm probably after is not the first or second hit there; > looks like the candidates are arranged in the alphabetical order of > the *.el files). > > Indeed, the ordering looks incorrect. This is a bug. > > The idea here is to group candidates belonging to different files together. Sorting the files alphabetically after that is the first natural choice, but how else to do it better? You could have the few "best matches" listed separately in the beginning of the list, followed by the grouping shown today. > - Should xref always try to preserve the order in which xrefs are returned? No! This would make the UI even more dependent on the back-ends. > - Suppose one xref in a.el is returned before all xrefs in b.el. And another xref in a.el is returned after. In what order will we display a.el and b.el? See above: the best matches could be listed irrespective of the files they were found in. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 14:57:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: monnier@IRO.UMontreal.CA, 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143023298411280 (code B ref 19468); Tue, 28 Apr 2015 14:57:03 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 14:56:24 +0000 Received: from localhost ([127.0.0.1]:42878 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn6vu-0002vr-Ta for submit@debbugs.gnu.org; Tue, 28 Apr 2015 10:56:23 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:51184) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn6vt-0002vd-0E for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 10:56:21 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NNI00400UKGAS00@a-mtaout21.012.net.il> for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 17:56:15 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNI004X3UTQAI10@a-mtaout21.012.net.il>; Tue, 28 Apr 2015 17:56:15 +0300 (IDT) Date: Tue, 28 Apr 2015 17:56:09 +0300 From: Eli Zaretskii In-reply-to: <553EBC1C.4050705@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <837fswwbcm.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <83k2wxwexb.fsf@gnu.org> <553EBC1C.4050705@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 28 Apr 2015 01:45:48 +0300 > From: Dmitry Gutov > CC: 19468@debbugs.gnu.org > > Maybe we should write an xref-old-ui-mode. > It would make M-. always prompt and it would always jump to the first > entry and then let you use C-u M-. to jump to the next match. > > That's doable, but it's not high on my priorities list. In case anyone's wondering. I don't think anyone asked for it, so feel free not to do anything about that. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 14:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 19468@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143023305811401 (code B ref 19468); Tue, 28 Apr 2015 14:58:02 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 14:57:38 +0000 Received: from localhost ([127.0.0.1]:42882 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn6x7-0002xo-85 for submit@debbugs.gnu.org; Tue, 28 Apr 2015 10:57:37 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:36923) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn6x5-0002xa-2C for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 10:57:35 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NNI00300UNWGQ00@a-mtaout22.012.net.il> for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 17:57:13 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNI00302UVCEF40@a-mtaout22.012.net.il>; Tue, 28 Apr 2015 17:57:12 +0300 (IDT) Date: Tue, 28 Apr 2015 17:57:06 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83618gwbb1.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: Eli Zaretskii , 19468@debbugs.gnu.org > Date: Mon, 27 Apr 2015 18:54:05 -0400 > > > - If I do have a tags table loaded, it's likely for a different project than > > Emacs. This is most likely true for the majority of our users. > > I really think the etags backend should only return data when the TAGS > file is in one of the parents of the current directory. That goes back to the "working on several projects" discussion of yore. Specifically, you might be working on two related packages (e.g., one calls the other) that live in two different directories. > And it should also be able to keep several independent TAGS tables > opened for different projects in different directory trees. It already does that. > > I think Eli (and everyone like-minded) should advise elisp-xref-find and > > xref-identifier-completion-table-function instead, inside their init script, > > like suggested by Daniel in another thread. > > It seems a common enough request that we should accommodate > them better. At the very least provide a minor mode which sets up > such advice. User options if possible, minor modes if not, yes. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 14:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: monnier@IRO.UMontreal.CA, 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143023309811488 (code B ref 19468); Tue, 28 Apr 2015 14:59:02 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 14:58:18 +0000 Received: from localhost ([127.0.0.1]:42886 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn6xk-0002zE-VN for submit@debbugs.gnu.org; Tue, 28 Apr 2015 10:58:17 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:55870) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn6xi-0002yw-4t for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 10:58:14 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NNI00I00UKJXU00@mtaout27.012.net.il> for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 17:53:14 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNI008LXUOPZEA0@mtaout27.012.net.il>; Tue, 28 Apr 2015 17:53:14 +0300 (IDT) Date: Tue, 28 Apr 2015 17:58:02 +0300 From: Eli Zaretskii In-reply-to: <553EC300.9030904@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <834mo0wb9h.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <553EC300.9030904@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 28 Apr 2015 02:15:12 +0300 > From: Dmitry Gutov > Cc: 19468@debbugs.gnu.org > > It seems a common enough request that we should accommodate > them better. At the very least provide a minor mode which sets up > such advice. > > But how common is it, really? I've only seen one person ask for it so far. Surely the 5 or so people who actually use tags with Elisp are a distinct minority compared to the whole Emacs user base. Why are you only talking about Elisp? What about other languages? Emacs exists not only for developing Emacs or Emacs-related packages. More importantly, this bug report is not about my preferences (although I did describe them when asked). It is about the inconsistencies and incompleteness of the new UI. Let's talk about that, and not about personal preferences. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 15:00:07 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 19468@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143023316311594 (code B ref 19468); Tue, 28 Apr 2015 15:00:07 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 14:59:23 +0000 Received: from localhost ([127.0.0.1]:42890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn6yo-00030w-Pn for submit@debbugs.gnu.org; Tue, 28 Apr 2015 10:59:23 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:37317) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn6ym-00030h-Tp for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 10:59:21 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NNI00300UVLJ700@a-mtaout22.012.net.il> for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 17:59:11 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNI003HFUYNEF40@a-mtaout22.012.net.il>; Tue, 28 Apr 2015 17:59:11 +0300 (IDT) Date: Tue, 28 Apr 2015 17:59:05 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83383kwb7q.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: Eli Zaretskii , 19468@debbugs.gnu.org > Date: Mon, 27 Apr 2015 19:19:16 -0400 > > Can't etags do better than substring matching and only return matches > that actually have the requested name (and maybe fallback on substring > matching if there's no exact match)? See the various *-match-p functions in etags.el, which can be used for that. You will see in etags-recognize-tags-table that etags.el programs the order in which the matches are found into the find-tag-tag-order variable. We could remove some of the criteria from that list, preferably under control of some user option, thus making the results more accurate. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 15:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143023325711823 (code B ref 19468); Tue, 28 Apr 2015 15:01:02 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 15:00:57 +0000 Received: from localhost ([127.0.0.1]:42895 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn70H-00034X-Bb for submit@debbugs.gnu.org; Tue, 28 Apr 2015 11:00:57 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:41241) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn70B-00034G-K5 for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 11:00:52 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NNI00K00USQ5T00@mtaout27.012.net.il> for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 17:55:47 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNI0087TUSZZEB0@mtaout27.012.net.il>; Tue, 28 Apr 2015 17:55:47 +0300 (IDT) Date: Tue, 28 Apr 2015 18:00:35 +0300 From: Eli Zaretskii In-reply-to: <553ECA9D.6090306@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <831tj4wb58.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <553ECA9D.6090306@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 28 Apr 2015 02:47:41 +0300 > From: Dmitry Gutov > CC: 19468@debbugs.gnu.org > > emacs -Q > M-x xref-et TAB => [No match] > > It should be autoloaded, IMO. Perhaps there should also be a > global minor mode, for those who'd like that. > > I don't know if we want to settle on that solution, actually. Have you seen this thread? > > http://lists.gnu.org/archive/html/emacs-devel/2015-04/msg01236.html Yes, but I'm unsure how is that relevant. Are you talking about auto-loading, or are you talking about a global minor mode? > That's not so easy to wrap in a global minor mode. I'm not even sure a minor mode would be a good approach here at all. Sorry, you lost me. What aspects prevent us from making a global minor mode that uses xref-etags-mode in all buffers? > . It does nothing when point is on a unique symbol: > > M-. set_cursor_from_row RET > Now, with point on its position under set_cursor_from_row, type > M-. again => nothing(??!!) happens > > I guess it looks for more symbols matching set_cursor_from_row, > finds out that this is the only one, and does nothing. This is > not useful. It should at the very least say something like > "set_cursor_from_row: this is the only match". > > `M-x find-tag' behaves exactly the same: even when the result is that we don't move anywhere (for the same reason), there's no helpful message. Just "Mark set" in the echo area. How is the old UI relevant here? We are talking about the new UI. (I already explained elsewhere that the old UI had "C-u M-." to go to the next match, whereas the new UI provides the *xref* buffer for that instead. So what the old UI did in this situation is not relevant, because the crucial feature of going to the next match, which was part of dealing with this situation in the old UI, is missing in the new UI. Thus, the new UI should find a different solution for this situation.) > I don't know if adding a new message in this case will be too helpful, but you're welcome to suggest the wording. I thought I already did, see above. > . Some problems with key bindings in the *xref* buffer: > > . RET displays the candidate listed on the current line, but > closes the window displaying *xref*, so it's not easy to try > another candidate afterwards. > > There's also the `C-o' binding, which displays the xref, but keeps the current focus. OK (did I say the documentation is missing?), but RET is the usual way of doing this, so I guess many users will. > > I think it would be more helpful > > to just switch to the window showing the definition, but leave > > the *xref* buffer shown. > > Some packages take this approach; I don't like it. But this should be easy to implement with a user option that would slightly change the behavior of `xref-goto-xref'. Care to take a stab at it? Maybe, if/when I have time. The more important issue is how to go to the next candidate once the window showing *xref* is closed. > . You need to use the unconventional '.' and ',' to both move and > display the definitions -- this should at least be mentioned in > the initial echo-area message when *xref* is first displayed. > (This was reported as a problem in the original report, but > seems to be left unchanged.) > > Should those be `n' and `p' instead, by default? I've found myself using these bindings very rarely anyway, and `n' is still very close. Possibly. > (Other similar Emacs modes, > like Compilation and Grep, do provide commands to move to the > next item without first switching to the buffer that shows all > the hits.) > > Compilation and Grep both use M-g M-n/M-g M-p, and the next-error-function variable. Do you want xref to reuse it? Something like that, yes. There's also "C-x `". Or maybe you should bring the equivalent of tags-loop-continue back ;-) > Would you be comfortable with forgetting the current list of errors after navigating somewhere with xref? No, I don't think so. > But what are the alternatives, if any? I could only find > something related in ada-mode and in elisp-mode. This means > that, for example, for C/C++ and Java, etags is the only > available back-end, and this change is currently just a different > UI wrapping the same basic functionality? Is there any further > development planned for the near future? > > There's also ggtags in GNU ELPA. I'm sure it could provide some integration, too. I don't see any xref-related code in ggtags. Did I miss something? From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 15:03:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: monnier@IRO.UMontreal.CA, 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143023333611977 (code B ref 19468); Tue, 28 Apr 2015 15:03:03 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 15:02:16 +0000 Received: from localhost ([127.0.0.1]:42899 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn71b-000376-Le for submit@debbugs.gnu.org; Tue, 28 Apr 2015 11:02:16 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:37669) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn71Y-00036q-3f for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 11:02:14 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NNI00I00UY74000@a-mtaout20.012.net.il> for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 18:02:04 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNI00H4YV3FWO70@a-mtaout20.012.net.il>; Tue, 28 Apr 2015 18:02:03 +0300 (IDT) Date: Tue, 28 Apr 2015 18:01:57 +0300 From: Eli Zaretskii In-reply-to: <553ED323.6080603@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83y4lcuwii.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> <553ED323.6080603@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 28 Apr 2015 03:24:03 +0300 > From: Dmitry Gutov > Cc: 19468@debbugs.gnu.org > > That makes a lot of sense when the candidates are equally likely to be > The One that the user's looking for. In the case of etags I think the > problem comes from the substring matching it uses. > > etags puts some effort into returning the candidates in the most plausible way. Should we ignore that? etags--xref-find-definitions tries to honor it, at least according to the comment. etags--xref-find-definitions doesn't honor the etags order well enough, because it groups the matches by file, whereas the etags back-end returns them ungrouped. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 15:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: monnier@iro.umontreal.ca, 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143023347112222 (code B ref 19468); Tue, 28 Apr 2015 15:05:02 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 15:04:31 +0000 Received: from localhost ([127.0.0.1]:42910 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn73k-0003Az-9d for submit@debbugs.gnu.org; Tue, 28 Apr 2015 11:04:31 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:42240) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn73e-0003Ac-FT for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 11:04:26 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NNI00L00UVDIX00@a-mtaout23.012.net.il> for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 18:03:26 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNI00LBRV5KFB60@a-mtaout23.012.net.il>; Tue, 28 Apr 2015 18:03:20 +0300 (IDT) Date: Tue, 28 Apr 2015 18:03:14 +0300 From: Eli Zaretskii In-reply-to: <553EED28.5050902@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83wq0wuwgd.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <553EC300.9030904@yandex.ru> <553EED28.5050902@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 28 Apr 2015 05:15:04 +0300 > From: Dmitry Gutov > Cc: 19468@debbugs.gnu.org > > Could be. But etags has been around for a long time and was the only > "standard feature" of the kind until very recently in Emacs, so I think > it's fair to assume that there are more such users out there. > > etags might be popular (so some sort a general solution might be welcome), but that doesn't mean it's used with Elisp a lot. What alternatives were there, before xref? > For instance, if we consider Debian-like distributions, https://packages.debian.org/jessie/all/emacs24-el/filelist does not include the TAGS file. I don't think the C sources are generally included in the binary distributions. It's easy to generate TAGS for Lisp files, if one needs them. We describe all that in the user manual. > And if we're just talking about Emacs developers, I wonder why nobody else spoke up on emacs-devel or in this bug yet. This goes both ways: no one spoke about xref, either. I wouldn't assign any significance to that. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 18:48:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: monnier@IRO.UMontreal.CA, 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14302468496490 (code B ref 19468); Tue, 28 Apr 2015 18:48:03 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 18:47:29 +0000 Received: from localhost ([127.0.0.1]:42991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnAXZ-0001gb-Dl for submit@debbugs.gnu.org; Tue, 28 Apr 2015 14:47:29 -0400 Received: from mail-wi0-f176.google.com ([209.85.212.176]:36200) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnAXX-0001gM-8i for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 14:47:27 -0400 Received: by wizk4 with SMTP id k4so152137380wiz.1 for <19468@debbugs.gnu.org>; Tue, 28 Apr 2015 11:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=V8UXOJtBnhtXve3ZT1vPzNcQw3nyLzMqpft5qBazQ2U=; b=bq4yOi7MBbnYP9ILe4YUfSZxAV9kLynuWHssBZmOS/GAX8rycjqFFyoh40LIso3P+l yrZww89aRW8LAiB8AyoekAdSKymUtyKLaSZuFjdofUFoMsiYG6WVLzKr+7jn8X4/eEWx chGgZHCpojqSZdxkpphJ/fzdB/yzc5sARc/DYIuDEATE8OEHYq9sh+0qriCM1zP7oX81 TkkhUuRr8mAdeyxA0lGzPKMMx0xql/PQw3VNee/Hw3gRQD+zwtEOFd6tsXcRy2mutulN lmX6hnJ3FcSRJs3b+7BZbNfWrTHoncN+xUFoUqAnYZIrPnOO1cLb6tBeoSWmpuxpTzRI 66QQ== X-Received: by 10.180.74.132 with SMTP id t4mr33296508wiv.55.1430246841525; Tue, 28 Apr 2015 11:47:21 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id jq3sm35469722wjc.22.2015.04.28.11.47.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 11:47:21 -0700 (PDT) Message-ID: <553FD5B3.2060803@yandex.ru> Date: Tue, 28 Apr 2015 21:47:15 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> <553ED323.6080603@yandex.ru> <83y4lcuwii.fsf@gnu.org> In-Reply-To: <83y4lcuwii.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/28/2015 06:01 PM, Eli Zaretskii wrote: > etags--xref-find-definitions doesn't honor the etags order well > enough, because it groups the matches by file, whereas the etags > back-end returns them ungrouped. That's incorrect. That function doesn't group anything. The xref UI does the grouping. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 21:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Stefan Monnier Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14302548446819 (code B ref 19468); Tue, 28 Apr 2015 21:01:02 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 21:00:44 +0000 Received: from localhost ([127.0.0.1]:55250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnCcU-0001lt-3c for submit@debbugs.gnu.org; Tue, 28 Apr 2015 17:00:43 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:36039) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnCcQ-0001lf-La for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 17:00:40 -0400 Received: by wizk4 with SMTP id k4so156209944wiz.1 for <19468@debbugs.gnu.org>; Tue, 28 Apr 2015 14:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+qSHsPstaOYK7swpOMnNIIiBLnfX5lpRUj6x96X0JzM=; b=fNqDUzks2OoRR79Zw/PUkv5Legld9jc7cLTGPn+u97kKgTk8Swe3ExWncmjj7IBwUh 76FxmaK76d5yhxdw/leBzireubUz5uWejFBZmNbbx9IZIpMX/4paPVYnhAjf6gE2SSt3 yrSoYDukwyOVIq4pmvO869mj072nWj4oreJAXCyPHWHs+Q3yWw2QvPBBB550EyRkzJNT OTHYWwqLniAnMx8bXgUVgkk26fp/T4RvWcp+QUkInURTu/I41zo+4RluCJ13gwBSzn6a Q/Vt1I/o92bBl5aPNXlkE+qADtfoMSWGqL2xRPrTCUz/6o9M4LQiP23w9QL8TbK05XPE KyaA== X-Received: by 10.194.242.101 with SMTP id wp5mr9445615wjc.4.1430254832985; Tue, 28 Apr 2015 14:00:32 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id ei4sm18115046wib.22.2015.04.28.14.00.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 14:00:32 -0700 (PDT) Message-ID: <553FF4EF.4080003@yandex.ru> Date: Wed, 29 Apr 2015 00:00:31 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <83k2wxwexb.fsf@gnu.org> <83fv7kwbow.fsf@gnu.org> In-Reply-To: <83fv7kwbow.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/28/2015 05:48 PM, Eli Zaretskii wrote: > By > contrast, the new UI is inconsistent: with some back-ends it shows the > list of matches and allows to navigate it, with others it shows only > the first match and does not give any way to get the next match. The UI has nothing to do with it. It's just the etags backend often returns multiple results to the "find-definitions" command. The elisp backend is more precise, but it can also return multiple results under certain conditions. For instance, when the exact name we're looking for corresponds to a function, a feature name, and a face (there's certain effort there not to show both a function and a variable with the same name, because they usually both point to a minor mode definition). >> No: there's only one definition of `find-tag' so Elisp's xref backend >> just returns that one and that's it. > > There's more than one matching definition, see below. If you want "matching" definitions, use xref-find-apropos. > But that's largely immaterial: this bug report is not about the > back-end, it's about the UI. The UI should be independent of the > back-end, otherwise the users will be confused when they switch > between languages. The UI can only work with that a backend returns to it. A non-ideal implementation can result in non-ideal behavior in the end. > (If it turns out that some back-ends need to be > augmented so that they allow the front-end to present similar UI for > the same query, then those back-ends should be enhanced.) Sure. I'd be happy to leave that to someone else, but there doesn't seem to be someone actively maintaining it. In that situation, we first try to make the backend work as well as `find-tag'. Patches, as well as specific technical suggestions, are very welcome. >> Arguably, the find-tag advice in org-ctags.el could be offered as well, >> if org-ctags.el happens to be loaded > > ??? Why should the xref matches depend on what is and isn't loaded? The above is referring to the Elisp xref backend, which is based on the package `find-func'. Which, yes, > That would make xref exactly equivalent to "M-x apropos", which means > this mode of operation would make xref entirely redundant. I don't know how to respond to this. Yes, they use the same data available at runtime. No, they're not exact duplicates of each other; the data is used in slightly different ways and presented in a different interface. > To say > nothing of the fact that this doesn't scale to any language except > ELisp. Yes, the Elisp backend doesn't scale to other languages. > (One of my worst annoyances is to type a > C-h command and be presented with "[No match]", because some package > is not loaded or some function is not available in the Emacs > configuration I happen to be using.) It's the cost of doing business, as far as I'm concerned. You can't use tags for non-core Elisp code anyway, such as anything in your init directory (installed packages, etc), and any Elisp files installed separately by the operating system's distribution. Actually, if you're not working on a Git checkout, I don't think you can use the tags even for the Elisp code that's part of Emacs. > The important point for the purposes of this bug report is that the > stuff presented by the UI for the same query does not differ so > radically when you switch the back-end. In general, it's the concern of each particular backend, to adhere to the described interface. The UI has nothing to do with it. > . there should be a way to go to the next/previous match if the > *xref* buffer is not displayed (or not created in the first > place); if this happens because there's only one match, we should > say so explicitly I don't see the point. That fact that we've jumped to a new location means there was a match, and since we haven't seen the xref buffer, there were no other matches. The message might feel assuring to you in the beginning, but over time I think it'll just become a nuisance. > . when there are more than one possible match, the UI should behave > similarly, i.e. display the *xref* buffer; when there's only one > match, it should _never_ display *xref*, That's how it works already. With the exception of the "possible match" phrasing, which is nonsense to me. There either are matches of the kind that the current command is asking for, or there aren't. > . if the criteria for filtering of the matches are very different > between the possible back-ends, there should be some agreed-upon > uniform default that returns roughly the same number of matches > with all back-ends, and the rest should be controlled by user > options These criteria are described in the xref-find-function docstring. Maybe not ideally: feel free to suggest a more clear wording. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 21:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14302550767169 (code B ref 19468); Tue, 28 Apr 2015 21:05:02 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 21:04:36 +0000 Received: from localhost ([127.0.0.1]:55254 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnCgF-0001rZ-Ac for submit@debbugs.gnu.org; Tue, 28 Apr 2015 17:04:35 -0400 Received: from mail-wi0-f180.google.com ([209.85.212.180]:38731) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnCgD-0001rM-FO for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 17:04:34 -0400 Received: by wiun10 with SMTP id n10so43949031wiu.1 for <19468@debbugs.gnu.org>; Tue, 28 Apr 2015 14:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=twdhOZJMUdMjDfZhtwqI8GxC2HEAQkR8uumihN2SSng=; b=ltCfUDymhxoMDGb4jkifTD2arC8b4NI8QRKnMP6extpsRimOyE7Sp0Pv2YwVh6BbBO cmYypgNiwj0z4MI4pTccPFQzcv0TAP85uadCzdT2Cw9yqlSdFiN6K1JPHREpdP5bX9Tj K6yoqisMgmXQeG/62REDuMDrfmblYdZmwgaGmcnJrlvNkPCnBNerHbD54PpIISOa4ccu sshW+Y1Ij/5DIAGAYhV+WLFZIm1isAXpPCHu9ydzW0hW9muxU0t1uEn1TtSZH1+ODM7T vIn8MYcy8kxkRmQwmgeiIGzTgKXhEyQ4FvbZB391o28snchiUYZB5yn0HXlbzmc/HCa4 zd5A== X-Received: by 10.180.84.130 with SMTP id z2mr2684431wiy.42.1430255067879; Tue, 28 Apr 2015 14:04:27 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id nb9sm18151221wic.10.2015.04.28.14.04.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 14:04:27 -0700 (PDT) Message-ID: <553FF5DA.4090408@yandex.ru> Date: Wed, 29 Apr 2015 00:04:26 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <83k2wxwexb.fsf@gnu.org> <553EB9D7.7010002@yandex.ru> <553EC576.70903@yandex.ru> <553EE468.4070203@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/28/2015 04:30 PM, Stefan Monnier wrote: > The reason is because that `completion-metadata' says that the > completion category is `buffer' and because completion-category-defaults > says that for `buffer' completion, we should use the `substring' style > by default. Hmm, maybe we should introduce a new category, for reading symbols. Aside from xref, we could use it in describe-function/variable/etc. Although the fact that it tries prefix matches first, and only falls back to substring matches, doesn't look too terrible to me. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 21:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: monnier@IRO.UMontreal.CA, 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14302568049720 (code B ref 19468); Tue, 28 Apr 2015 21:34:01 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 21:33:24 +0000 Received: from localhost ([127.0.0.1]:55258 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnD87-0002Wf-0t for submit@debbugs.gnu.org; Tue, 28 Apr 2015 17:33:23 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:36463) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnD84-0002WR-VH for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 17:33:21 -0400 Received: by wizk4 with SMTP id k4so157074170wiz.1 for <19468@debbugs.gnu.org>; Tue, 28 Apr 2015 14:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=eXLooS+Mkjf5G/PxoXWQ1ESwjYmOq1LILRWt+Iosq5I=; b=Q7dUQ0GPxiL7gUzEYdQoY9KC9xNeBX3jpzkIfm6opjJu+ocZHGidTuAiQn7wSIBMSd CooKVvF/Sw2LRXkhzrHjsT5KiRS4J+5EfGXqBLrlBJFp4T20uK4tgVED6dLqxlWRShhS QLxXd2lyAT2qJqWaeMDd6KisMQMg8+javFWYCdlO+dXnste3pnIrZEALvfM3nyYxrmxQ txhv2OhcxAF5xmRtcXHt98ecPQZGMNz0O7E262OseUEtf3j4J6gxVUAjnw658AWndH7m bhVYp5/Tuv3DIGRx/+8LuI1bOYUXy3+WoQ4bP2b2vmeGoe1vI6qg/mQThLRJKRTFVmbZ Y1dw== X-Received: by 10.194.142.232 with SMTP id rz8mr35520266wjb.78.1430256795427; Tue, 28 Apr 2015 14:33:15 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id bi3sm18259528wib.5.2015.04.28.14.33.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 14:33:15 -0700 (PDT) Message-ID: <553FFC99.5080701@yandex.ru> Date: Wed, 29 Apr 2015 00:33:13 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> <838udcwbdc.fsf@gnu.org> In-Reply-To: <838udcwbdc.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/28/2015 05:55 PM, Eli Zaretskii wrote: > You could have the few "best matches" listed separately in the > beginning of the list, followed by the grouping shown today. What's "best matches"? I suggested using `tag-exact-match-p' in the etags backend. What's your take on this? >> - Should xref always try to preserve the order in which xrefs are returned? > > No! This would make the UI even more dependent on the back-ends. Without using the order, in which matches are returned by the backend, we can't even know what the "best matches" are. What about the rest of the predicates in `find-tag-tag-order' set by `etags-recognize-tags-table'? Should we disregard all of them? From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 22:00:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: monnier@iro.umontreal.ca, 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143025839611981 (code B ref 19468); Tue, 28 Apr 2015 22:00:04 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 21:59:56 +0000 Received: from localhost ([127.0.0.1]:55264 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnDXn-00037A-HZ for submit@debbugs.gnu.org; Tue, 28 Apr 2015 17:59:56 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:35911) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnDXm-00036x-5m for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 17:59:54 -0400 Received: by wizk4 with SMTP id k4so157698149wiz.1 for <19468@debbugs.gnu.org>; Tue, 28 Apr 2015 14:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1XbFXop+WDu/tZjb02eyE2mmNRh7V/HbL2F9L+elaIs=; b=ESYDynNYHkASWJKl7eLkmG1u3Dq9jPlCd2PvBz3NFGW9vx1ARZQKhDLchFllvBOLvG pgQepLQsHuoxHpR+BkbH6/I9xTKCFpNIaUmI5SVVO86ki1aqoJtfr1l9E7DoK8x/qgcj ViECPWLxQLKFiwynJwIbgdM6WJoDq5XW8TrA8al4SjlQURKvIxvARwXFhTdxQmEvx4Op zGhDYpM1d5vN7ke8h12KstOXZLPoM4lkig1C3G3HyX7lLK3SNhVZmh0RbnRcTwrw2to1 CWNZtRXO+pgW6R0fQKLlRBh+cUV3E+62ROPIpkI1m7q5YEpU1uS6bjNy7Kq/mHtfKLIi 2XHQ== X-Received: by 10.194.185.207 with SMTP id fe15mr3545422wjc.92.1430258388464; Tue, 28 Apr 2015 14:59:48 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id ha4sm18341207wib.0.2015.04.28.14.59.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 14:59:48 -0700 (PDT) Message-ID: <554002D2.3000203@yandex.ru> Date: Wed, 29 Apr 2015 00:59:46 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EB3A4.9090107@yandex.ru> <83egn4wbn0.fsf@gnu.org> In-Reply-To: <83egn4wbn0.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/28/2015 05:49 PM, Eli Zaretskii wrote: > Some would say it's a disadvantage to need another command. It means > the user has to decide up front which one she needs. Showing the rest > of matches after the exact one doesn't have this disadvantage. On the plus side, if there's just one exact match, Emacs will jump to it automatically. > Once again, this bug is about the UI. The UI shows only one match > with one back-end, and all of them with another. That's the problem I > think we should address. UI shows all matches that a backend returns. > ??? How can what we show be the limitation of the format of the > database where we keep the data? If we think we should not display > everything, let's filter the irrelevant stuff before showing it. It would be a limitation with the format if any `tag-exact-match-p' implementation can't be 100% reliable. Some prior experience dealing with it told me that may be the case. But anyway, I've just opened lisp/TAGS, and I haven't been able to make `(tag-exact-match-p "...")' return t with any input and position I've tried. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 22:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143025869512492 (code B ref 19468); Tue, 28 Apr 2015 22:05:02 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 22:04:55 +0000 Received: from localhost ([127.0.0.1]:55268 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnDcc-0003FP-0E for submit@debbugs.gnu.org; Tue, 28 Apr 2015 18:04:54 -0400 Received: from mail-wg0-f54.google.com ([74.125.82.54]:36571) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnDcZ-0003F9-Nu for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 18:04:52 -0400 Received: by wgen6 with SMTP id n6so9115063wge.3 for <19468@debbugs.gnu.org>; Tue, 28 Apr 2015 15:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qijCuuxPrsDIvlyk+O48BDisn9ytjj5lmKVqPECQuE0=; b=E21pMcrukUs3iPVkb4T1rXNGyJhrWiWNfGITozsmWVKKUig6qLznv+0HAPa3HSw/hx ssSONWMmsjM4Mp98N3UkUwJfMnY2f6Oe53lucN6sVEAmmjvz0oSa5xJb+c3IQfCfpb/t SRrha5//U+DaptcsT8wmTE7/CYePSxuLZnxUNXxGzjyoTkumzlWpr0bhqlBfL3wsHxCS InyA43JR2X6jjYwNM31eF1ow3cGFT2cfECMI0O+hSdfqCH3zJxBgtpdOBgKUDos93bkb LyMb1jcT0TOgPlFhEp2tFNROtCmD9w5v55eADA5EsKj4NkzY9ioVbQC4rrddVmtj5f5w Isdw== X-Received: by 10.194.200.194 with SMTP id ju2mr35511500wjc.61.1430258686056; Tue, 28 Apr 2015 15:04:46 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id z12sm36109466wjq.12.2015.04.28.15.04.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 15:04:46 -0700 (PDT) Message-ID: <554003FC.9060007@yandex.ru> Date: Wed, 29 Apr 2015 01:04:44 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <83lhhdwfft.fsf@gnu.org> <553EB903.9060000@yandex.ru> <83a8xswbeg.fsf@gnu.org> In-Reply-To: <83a8xswbeg.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/28/2015 05:55 PM, Eli Zaretskii wrote: > I filed this bug report, for starters. I then invested a non-trivial > amount of my time into learning this feature, trying different things, > describing my experiences, thinking about ways to improve this, etc. > And I continue doing that. I hope this does help; if not, feel free > to close this bug report as "won't fix" and tell me not to bother > anymore. Let's concentrate on the interface and the current implementations instead. > This feature, including the new UI and API, was introduced 4 months > ago, and we still have only 2 back-ends supporting it: ELisp and Ada. And etags. Three backends isn't exactly the same as "no backends". > They are nothing > more than infrastructure waiting for programmers to use it, and those > programmers don't seem to be coming. Putting on my cynic hat, I'd say > it's a solution looking for the problem. I didn't see programmers running to improve the built-in C support in Emacs before. Certainly nobody expected to see them running now, simply because xref was introduced. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 22:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: monnier@iro.umontreal.ca, 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143025887912765 (code B ref 19468); Tue, 28 Apr 2015 22:08:02 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 22:07:59 +0000 Received: from localhost ([127.0.0.1]:55272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnDfa-0003Jo-6O for submit@debbugs.gnu.org; Tue, 28 Apr 2015 18:07:58 -0400 Received: from mail-wg0-f50.google.com ([74.125.82.50]:36021) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnDfY-0003Jb-NK for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 18:07:57 -0400 Received: by wgen6 with SMTP id n6so9178102wge.3 for <19468@debbugs.gnu.org>; Tue, 28 Apr 2015 15:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=LA3tGIgQnVosReQgAKOtI9Au9jAAqjg+ybpUiWoLG4s=; b=IR1onEp1/IH7QLEeOHxlj5IrGZ1unExU54/l16t46cTar3qk551QQzSzm+bJg3rKGL gX7+o3RNPfpkJ0gjUIG+BZfVPK8lEipI8vP3sl53hTB9JDr4muTkPYW67TV1lS4cFQSw KTiq1ctm/Pt3dDqMJr2NPPAg6ObkaOeoD0GwwXwlyuSMc4rIiFvgD5raUv2AITdkXUm3 gbgMSXTelpd/TEXsQkuPW4t8NOBsxHeouBFmPkKfgWUpZ2JPeeGdPZ2YQMz0MIVGcIYK 1jqP8+5oRTopP5o0CdCqcAh18vjSO3Q/QslnAm4UxeBntqXpSrfYr5it1mmJa834S/WG DWww== X-Received: by 10.194.192.226 with SMTP id hj2mr13427368wjc.51.1430258871308; Tue, 28 Apr 2015 15:07:51 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id w5sm18340484wiz.11.2015.04.28.15.07.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 15:07:51 -0700 (PDT) Message-ID: <554004B5.1080109@yandex.ru> Date: Wed, 29 Apr 2015 01:07:49 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <553EC300.9030904@yandex.ru> <553EED28.5050902@yandex.ru> <83wq0wuwgd.fsf@gnu.org> In-Reply-To: <83wq0wuwgd.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/28/2015 06:03 PM, Eli Zaretskii wrote: > What alternatives were there, before xref? 1. M-x find-function (some even used M-. as its binding). 2. C-h comment-forward RET, then click on the file name. > It's easy to generate TAGS for Lisp files, if one needs them. We > describe all that in the user manual. Could you point me to the exact section? > This goes both ways: no one spoke about xref, either. I wouldn't > assign any significance to that. Judging by a few comments by several people, it's being used. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 22:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143025893112862 (code B ref 19468); Tue, 28 Apr 2015 22:09:02 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 22:08:51 +0000 Received: from localhost ([127.0.0.1]:55276 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnDgQ-0003LO-Kc for submit@debbugs.gnu.org; Tue, 28 Apr 2015 18:08:51 -0400 Received: from mail-wi0-f180.google.com ([209.85.212.180]:35381) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnDgO-0003L8-HL for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 18:08:48 -0400 Received: by widdi4 with SMTP id di4so157591888wid.0 for <19468@debbugs.gnu.org>; Tue, 28 Apr 2015 15:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=RqE/Zpxf5a513J1PGhENj2am1n7g3jS1nv5E+qcCqQE=; b=uonevkYWfDgP1iWBFz9OowwYftnsoLxQP7J+hQHvRdkBDO/6DMr0AS8UsdfR4ahz98 20Or7R458Ilwq5Zr3Nx19vSpE0d716HUIZ6IoHc0Au58Kpg8rpf2Nb2PqSIEticlLya3 amU7ZVfxcPq/nIu7et9Fwkd0vykdImTAfSr61vzoVGSBXECfUH8sOamPjdHfsjqG3R7q NdKVnGFr8ZlmMKDljo6qOMYcfFcdGEjsMuHp0rU9qISvhxLS+7iCB+jTOu67qJKvR99X dgy6uF3BO4XLVSyY1FZ4Yoeku+mU6wtnJwhmUr4fYeZMNwaG42x54/zO78TMyGYmfPM5 ymUw== X-Received: by 10.180.99.39 with SMTP id en7mr3114403wib.31.1430258923132; Tue, 28 Apr 2015 15:08:43 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id wo10sm36152814wjb.35.2015.04.28.15.08.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 15:08:43 -0700 (PDT) Message-ID: <554004E9.4000202@yandex.ru> Date: Wed, 29 Apr 2015 01:08:41 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <553EC300.9030904@yandex.ru> <834mo0wb9h.fsf@gnu.org> In-Reply-To: <834mo0wb9h.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/28/2015 05:58 PM, Eli Zaretskii wrote: > Why are you only talking about Elisp? What about other languages? > Emacs exists not only for developing Emacs or Emacs-related packages. Simply because this subthread of discussion, for me, is about using etags in emacs-lisp-mode. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 22:16:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143025935313507 (code B ref 19468); Tue, 28 Apr 2015 22:16:03 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 22:15:53 +0000 Received: from localhost ([127.0.0.1]:55280 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnDnE-0003Vl-3D for submit@debbugs.gnu.org; Tue, 28 Apr 2015 18:15:52 -0400 Received: from mail-wg0-f43.google.com ([74.125.82.43]:34076) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnDnB-0003VX-Hm for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 18:15:50 -0400 Received: by wgso17 with SMTP id o17so9453099wgs.1 for <19468@debbugs.gnu.org>; Tue, 28 Apr 2015 15:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xM88AwMrNZecYtZzm9aaFzxeO3vo0CbuDlTkJUUnKrc=; b=bTrwasbt44Vv4trwR0N2PO9QJwHjq5IIyJ79MZPBMwJTPPXb7sCFBzAb5XTi/SymyG aYpxFS6S3fcluNkdcBDYpdxiky7joOtEifrD//5Ow/QXthX0h2kaAwEprM6yG3KcyR7n 5KsuLq5BQYjiNvKPvW+P2ZAckmEW3LzqAMMlIqvV84/KvolBpA6xhnIULYjMWNO42Q7q 85otKoeYiZ/zIW1Wj0hPeXt9X/PTiq3pJbebPqpa0AftB7+1O4rrkK4Z5aKT7Lhgc2hy fWHtnjSIy0O6L9SpOQ2q+LGbQJDNxd645EDQVbm8SQYbUO+SDUMoHih/ssO9hc1ZDhJ6 Ai6w== X-Received: by 10.194.158.193 with SMTP id ww1mr36998118wjb.100.1430259344049; Tue, 28 Apr 2015 15:15:44 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id a18sm10170541wja.46.2015.04.28.15.15.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 15:15:44 -0700 (PDT) Message-ID: <5540068E.4040308@yandex.ru> Date: Wed, 29 Apr 2015 01:15:42 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB4F4.1090704@yandex.ru> <83d22owblc.fsf@gnu.org> In-Reply-To: <83d22owblc.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/28/2015 05:50 PM, Eli Zaretskii wrote: > I hope they are reading this. (Personally, I'd expect the back-ends > for at least the most popular languages be ready before the switch to > the new API and the new UI, but that's me.) CEDET has been lagging quite a bit. Even the completion-at-point-functions (available since 24.1) support was only added half a year ago. >> There seems some confusion here: you do now invoke xref-find-function. It's not a function anyway, it's a variable, which different backends can set to implement the backend interface. > > Then the confusion is the doc string's fault: it should make this > aspect clear. And if there are no back-ends currently that support > these options, I'd suggest to remove that from the doc string -- we > shouldn't advertise in the docs stuff that no one implemented. The doc string is about the interface: as long as a given backend implements the `references' action, `M-x xref-find-references' will display the returned list. Please feel free to suggest better wording for the docstring. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 22:30:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: monnier@IRO.UMontreal.CA, 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143026014314668 (code B ref 19468); Tue, 28 Apr 2015 22:30:04 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 22:29:03 +0000 Received: from localhost ([127.0.0.1]:55291 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnDzy-0003oK-BR for submit@debbugs.gnu.org; Tue, 28 Apr 2015 18:29:03 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:35413) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnDzw-0003o0-4L for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 18:29:00 -0400 Received: by widdi4 with SMTP id di4so158020931wid.0 for <19468@debbugs.gnu.org>; Tue, 28 Apr 2015 15:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Cdq+G1I2tRXUrCHiuZSdKKjnXrv1/v+nT1X08PnZeNo=; b=KW87XKt/qB18BpVXxr/4VBXhbGwwFFbn0bd19h+PKTJBX/7aRjlme8phnhKq12nOnO pmhvhDxzO3mn7MtcNmnhxH+jseyroLYloPJNlGXA9kuwLkXrgbwi8fpmNMq2VufqiufD jmT49tmPfptV5KJqHiaihepndZRT43YmRMOzi9hU8yoezGC279NfrouJLlsYV7fk6u0j zORw91mTBkqZdmX5KlAGdG/ZKeGDsjK+91dHnPjsBEg6sXtMWdLn2B+rn/x0twgiJKdy LEMpb+Y2aHMdqlZFlKtHGF08856kuSpR6nBPVjg8nihkuzF4oYFKRm/ZVW7hlE6oDm8c YS9g== X-Received: by 10.180.96.196 with SMTP id du4mr33420451wib.77.1430260134644; Tue, 28 Apr 2015 15:28:54 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id c5sm4779204wjf.40.2015.04.28.15.28.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 15:28:54 -0700 (PDT) Message-ID: <554009A5.5020001@yandex.ru> Date: Wed, 29 Apr 2015 01:28:53 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> In-Reply-To: <83bni8wbin.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/28/2015 05:52 PM, Eli Zaretskii wrote: >> M-x xref-find-references, for starters. > > It doesn't seem to work for me: it says "no references found" whatever > symbol I try, even those I know are referenced. What am I missing? Do you know how to implement the "all uses" search using only a tags file? I don't. Likewise for Elisp. So, sorry to say, both currently implemented backends don't support it. ggtags, in GNU ELPA, might. > etags.el supports more than one loaded tag table, so this shouldn't be > a problem. If the only table I'm using is of my current Ruby project, that would be a problem anyway. Still, Stefan's suggestion of looking up the directory tree should solve that. > Please don't make advice the default Emacs customization method. User > options are much easier to use, so let's do what's possible with them, > and leave advice etc. for more exotic use cases. I'm suggesting its use lightly. As you've noticed, a minor mode was the first solution. However, if people want to use the Elisp xref backend is many other situations, you'll run out of hooks to add xref-etags-mode to. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 23:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143026351219799 (code B ref 19468); Tue, 28 Apr 2015 23:26:02 +0000 Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 23:25:12 +0000 Received: from localhost ([127.0.0.1]:55298 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnEsI-00059F-AJ for submit@debbugs.gnu.org; Tue, 28 Apr 2015 19:25:11 -0400 Received: from mail-wg0-f43.google.com ([74.125.82.43]:33776) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnEsE-00058h-QY for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 19:25:08 -0400 Received: by wgin8 with SMTP id n8so10669912wgi.0 for <19468@debbugs.gnu.org>; Tue, 28 Apr 2015 16:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+INCS0HNlZUCNEzKmulWSGBr6kEhRDGVgmB9u1eodWM=; b=tWy3lN/P1vpCfN9+8mTlNk3lMa4bPwoDPyMYEckIUH2v5vAOkPaGnuGBFSB9w1jD+o yDPD/uA5KIPN0FfDBujJAD34v+O4CYyV1qMUWLvyzbGNFck+4u9kyUo+2iAzi0fMlTa3 be2qXB6ir9Wn9ygwLm0BuloAM52qTx5ghMRzP8u4HYG0D5lVDTsLeeeWY7XgL/74l+kq iE4sYeB65vn0ZXhfvv/O7nT2A/jeTXgawsscoUZ3JKeSmY1/BK4W53WghkjG+A6m+O4V 8Wls/JLx3j5v5KldW4kthVuOOzuyr7owqsxyOgvPWvXd1huKoKfEI7KKBEcIzwIz+2To eFQQ== X-Received: by 10.180.231.4 with SMTP id tc4mr544033wic.27.1430263501019; Tue, 28 Apr 2015 16:25:01 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id gu7sm18548574wib.21.2015.04.28.16.25.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 16:25:00 -0700 (PDT) Message-ID: <554016CB.9080202@yandex.ru> Date: Wed, 29 Apr 2015 02:24:59 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <553ECA9D.6090306@yandex.ru> <831tj4wb58.fsf@gnu.org> In-Reply-To: <831tj4wb58.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/28/2015 06:00 PM, Eli Zaretskii wrote: > Yes, but I'm unsure how is that relevant. Are you talking about > auto-loading, or are you talking about a global minor mode? About replacing xref-etags-mode entirely, and using advice to use tags wherever elisp-xref-find is used. >> That's not so easy to wrap in a global minor mode. I'm not even sure a minor mode would be a good approach here at all. > > Sorry, you lost me. What aspects prevent us from making a global > minor mode that uses xref-etags-mode in all buffers? Um, yeah, it would work, if you want xref-etags-mode in *all* buffers at all, including those that might use yet another different backend. Actually, it still looks a good option for you, AFAICT. > How is the old UI relevant here? We are talking about the new UI. We need something to compare to. If I compare it to a popular IDE, they usually have this functionality bound to Ctrl-Click. If there's just one match, the user is taken to its location, if there are several, a context menu is shown. No message about the only match. Which makes sense to me. > (I already explained elsewhere that the old UI had "C-u M-." to go to the > next match, whereas the new UI provides the *xref* buffer for that > instead. So what the old UI did in this situation is not relevant, > because the crucial feature of going to the next match, which was part > of dealing with this situation in the old UI, is missing in the new > UI. Thus, the new UI should find a different solution for this > situation.) Where in the old UI you could go to the next match, in the old UI we display the xref buffer with all matches. Where this buffer is not displayed, in the old UI you wouldn't have been able to the next match. > I thought I already did, see above. Okay, sorry. It doesn't sounds like a good idea to me anyway. Especially when, in many environments (like Elisp), finding only one match will be the norm, not exception. > OK (did I say the documentation is missing?), but RET is the usual way > of doing this, so I guess many users will. They could also use winner-mode, or switch to *xref* manually. Where in the documentation would you mention the key bindings? >> Should those be `n' and `p' instead, by default? I've found myself using these bindings very rarely anyway, and `n' is still very close. > > Possibly. I'll wait for a stronger "yes" on this. > There's also "C-x `". Or maybe you should > bring the equivalent of tags-loop-continue back ;-) We've already taken up its binding, and since showing the whole list is a replacement for the "show first, allow to iterate through the rest" logic, we're unlikely to use a new binding for the `tags-loop-continue' equivalent. The next-error commands might make sense for what you're asking, as long as we've all considered the interaction with other commands that set next-error-function. >> Would you be comfortable with forgetting the current list of errors after navigating somewhere with xref? > > No, I don't think so. But that what happens if you run a compilation (with errors), and then call Grep. Doesn't it? > I don't see any xref-related code in ggtags. Did I miss something? Nope. It remains to be written. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2015 00:25:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143026707725301 (code B ref 19468); Wed, 29 Apr 2015 00:25:03 +0000 Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 00:24:37 +0000 Received: from localhost ([127.0.0.1]:55335 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnFno-0006a0-IA for submit@debbugs.gnu.org; Tue, 28 Apr 2015 20:24:36 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:35490) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnFnm-0006Zm-48 for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 20:24:34 -0400 Received: by widdi4 with SMTP id di4so160225811wid.0 for <19468@debbugs.gnu.org>; Tue, 28 Apr 2015 17:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=HTmSWCekSCTlRqqmhtWecME+DZj5KP2vfjYYK0KPsRQ=; b=h2ybrvo1oMZtzym9XMbw5FRI/7Om2Bwdc93aaoIBSS+X+QyVq1AAGkBa0vl36rdeeQ S+KKAXe3fnYkA5+W9qw9o7f3Mb3HOz2B/7NmSdz+PHl2OfFT6DN3NXW7LuG9f6MorhMo aVK62ENu17CaKGqoIYGp8EoPU5vQ2goFUOD9I0pPnQemC2gv1l6xL86g00aWotUWeSzJ 5HnhgBJ6RTWW0BDKOlNaaSrUAmPVQ1+MIO8IZBhvgW7If2bzvVwugmMaOJ9f1LXjusvI WZJsWulv9S+hHTHOdq2mvzMwX9hfT30KUa+IGHcP0f462YuJjOyIzQ5YGM6v11wziRwE EcGw== X-Received: by 10.195.12.48 with SMTP id en16mr37586604wjd.21.1430267068579; Tue, 28 Apr 2015 17:24:28 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id k2sm18722263wif.3.2015.04.28.17.24.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 17:24:28 -0700 (PDT) Message-ID: <554024BA.3090807@yandex.ru> Date: Wed, 29 Apr 2015 03:24:26 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <553EC300.9030904@yandex.ru> <553EED28.5050902@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/28/2015 04:36 PM, Stefan Monnier wrote: > Indeed, and it's largely unrelated since it would be a patch to the > xref/etags backend and wouldn't touch elisp-mode.el. On the other hand, tighter integration might have its benefits, too. Otherwise, the user wouldn't be able to use the Emacs's TAGS files for navigation when working on, say, an ELPA checkout. I'm not sure if somebody will really want to, but it makes sense to be able to use it both from core Elisp code, and third-party one equally. The tags part of the emacs-lisp-mode's xref backend could bind etags vars locally based on the value of source-directory, instead of using the current tags-table-list. > As mentioned, this suggestion is not directly related to other backends, > so whether xref/elisp completely shadows xref/etags or not is orthogonal. > BTW: Do you have a lisp/TAGS file? If so, why? That's a good question. Indeed, we could say I only had it built to see how tags work with Elisp. However, I do occasionally use src/TAGS, and 'make tags' builds both files. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Vitalie Spinu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2015 15:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 19468@debbugs.gnu.org, Dmitry Gutov Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143031964427433 (code B ref 19468); Wed, 29 Apr 2015 15:01:02 +0000 Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 15:00:44 +0000 Received: from localhost ([127.0.0.1]:56498 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnTTb-00078K-9B for submit@debbugs.gnu.org; Wed, 29 Apr 2015 11:00:43 -0400 Received: from mail-wg0-f45.google.com ([74.125.82.45]:35401) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnTTT-000782-P0 for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 11:00:36 -0400 Received: by wgyo15 with SMTP id o15so31454587wgy.2 for <19468@debbugs.gnu.org>; Wed, 29 Apr 2015 08:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=AZTDLfYt4y0LD5p0fVgnMxDn8argSWP8JZ70xXImAHk=; b=0RUHn2ygxZjLo3AtWY3WrtigLeqK17RLSOIi0//UEGFnlIXYv38adAgaU5DzuQcDDh F4YON9EnUGnbwcB5v5CN402V4iBDX3YX17QBIbEQTyOEyl5WCfTNAMaopyaTZqRZ3Ufe lOWjH7KUC9O2W/HW8aQYOZEpq+rwi33kSJHEeaytG/XQKZI3nj1zsb/3Ylwx4d9MhQ/f gOjHt4pJTuXk1fl1gcTDuKuqqxYYUb8ITglX5K/tN4a511gIsMMFrsvRIiby5duTFM4o b8AjSDXu3tfB5XZrZ4w4cO/Ge+ht+7gf+eCygCKB4Qhel+OviARnVSei/YbDP7t8QQss 1jOQ== X-Received: by 10.194.120.3 with SMTP id ky3mr43457523wjb.156.1430319626069; Wed, 29 Apr 2015 08:00:26 -0700 (PDT) Received: from localhost (dhcp-077-251-128-242.chello.nl. [77.251.128.242]) by mx.google.com with ESMTPSA id v3sm21568684wix.8.2015.04.29.08.00.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 08:00:24 -0700 (PDT) From: Vitalie Spinu References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> Date: Wed, 29 Apr 2015 17:00:24 +0200 In-Reply-To: (Stefan Monnier's message of "Mon, 27 Apr 2015 18:54:05 -0400") Message-ID: <87mw1r7zef.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >>> Stefan Monnier on Mon, 27 Apr 2015 18:54:05 -0400 wrote: >> - If I do have a tags table loaded, it's likely for a different >> project than Emacs. This is most likely true for the majority of >> our users. > I really think the etags backend should only return data when the > TAGS file is in one of the parents of the current directory. > And it should also be able to keep several independent TAGS tables > opened for different projects in different directory trees. This is close to perfect IMO. In addition I would like to be able to "link" tag tables. Let's say I have two projects A and B. By "linked" tag tables I mean that both tag tables are simultaneously accessible from descendant files of path/to/A and path/to/B. The UI is essentially one command - `etag-link-tag-table`. If I call `etag-link-tag-table` from project A and choose a tag table in B then A and B tag tables become linked, and vice versa. Simple as that. Vitalie From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2015 15:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Vitalie Spinu , Stefan Monnier Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143032115429665 (code B ref 19468); Wed, 29 Apr 2015 15:26:02 +0000 Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 15:25:54 +0000 Received: from localhost ([127.0.0.1]:56504 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnTrw-0007iL-FI for submit@debbugs.gnu.org; Wed, 29 Apr 2015 11:25:53 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:38542) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnTrp-0007i3-Vp for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 11:25:46 -0400 Received: by wiun10 with SMTP id n10so70151664wiu.1 for <19468@debbugs.gnu.org>; Wed, 29 Apr 2015 08:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=mDtzipchdziFLM7uPNth2wk0fr7K5250Qf3hEz5kyEU=; b=ZXVJ59j6VJzygWfcLR52ayUNLdGvsmas+51ufncKwPJHEinT+mZCPczPD0TOOr2svX uRsOtCnhQ7wFublyOZ4V8ernpRCh0p5H7bMmND5VTfJa+0LcF92ewp9SOdTP+TIN9YB1 3mXhBsT1nmnAiZQXknqNe9BAYqLvSptdmSQOuF2hKHZlQFsjnIH89cXmmM4VU6fCLaAf zuz11D2nmrjG/loyqe1mCwlcz9dyI6UNU3I7ZK6D7fgXXnoRLZ4WfgBllYJr1iQIQWEv 09h9hNXQcqjivP6UODNhxgz/IlzZ8EVJ2BhhIlospxPZHwhynFykf5bH2yleQ1rYgUI5 afBQ== X-Received: by 10.180.90.169 with SMTP id bx9mr9510434wib.50.1430321136135; Wed, 29 Apr 2015 08:25:36 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id df1sm21664562wib.12.2015.04.29.08.25.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 08:25:35 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <87mw1r7zef.fsf@gmail.com> From: Dmitry Gutov message-id: <5540F7ED.6050609@yandex.ru> Date: Wed, 29 Apr 2015 18:25:33 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <87mw1r7zef.fsf@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/29/2015 06:00 PM, Vitalie Spinu wrote: > Let's say I have two projects A and B. By "linked" tag tables I mean > that both tag tables are simultaneously accessible from descendant files > of path/to/A and path/to/B. The etags format already has a similar feature (etags --help | grep include), but it's only one-way, AFAIK. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2015 15:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: monnier@IRO.UMontreal.CA, 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143032214031226 (code B ref 19468); Wed, 29 Apr 2015 15:43:02 +0000 Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 15:42:20 +0000 Received: from localhost ([127.0.0.1]:56514 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnU7s-00087V-BL for submit@debbugs.gnu.org; Wed, 29 Apr 2015 11:42:20 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:55031) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnU7m-00087C-SO for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 11:42:14 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NNK00E00RGQ6Y00@mtaout29.012.net.il> for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 18:40:26 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNK00EEZRJE4V00@mtaout29.012.net.il>; Wed, 29 Apr 2015 18:40:26 +0300 (IDT) Date: Wed, 29 Apr 2015 18:41:37 +0300 From: Eli Zaretskii In-reply-to: <553FF4EF.4080003@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <838udbueku.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <83k2wxwexb.fsf@gnu.org> <83fv7kwbow.fsf@gnu.org> <553FF4EF.4080003@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 29 Apr 2015 00:00:31 +0300 > From: Dmitry Gutov > CC: 19468@debbugs.gnu.org > > No: there's only one definition of `find-tag' so Elisp's xref backend > just returns that one and that's it. > > There's more than one matching definition, see below. > > If you want "matching" definitions, use xref-find-apropos. That's a UI inconvenience, IMO. I already explained why: it requires me to know up front whether the symbol name I'm about to type is precise or not. > But that's largely immaterial: this bug report is not about the > back-end, it's about the UI. The UI should be independent of the > back-end, otherwise the users will be confused when they switch > between languages. > > The UI can only work with that a backend returns to it. A non-ideal implementation can result in non-ideal behavior in the end. We should not have "non-ideal" implementation that return radically different results. Each query by default should yield approximately the same result. If the differences are small, or differ only in their order, that's OK. But having one list of results be 2 orders of magnitude larger than another is something to avoid at all costs. > (If it turns out that some back-ends need to be > augmented so that they allow the front-end to present similar UI for > the same query, then those back-ends should be enhanced.) > > Sure. I'd be happy to leave that to someone else, but there doesn't seem to be someone actively maintaining it. That kind of thing happens every day in Emacs development, IME. There's no way around it, if you care about some component, and another one gets in the way, you need to fix that other component. > > To say > > nothing of the fact that this doesn't scale to any language except > > ELisp. > > Yes, the Elisp backend doesn't scale to other languages. I wasn't talking about the elis backend, I was talking about the design principles. > (One of my worst annoyances is to type a > C-h command and be presented with "[No match]", because some package > is not loaded or some function is not available in the Emacs > configuration I happen to be using.) > > It's the cost of doing business, as far as I'm concerned. No, it's a bug to be fixed. > You can't use tags for non-core Elisp code anyway, such as anything in your init directory (installed packages, etc), and any Elisp files installed separately by the operating system's distribution. Of course I can use TAGS: I just need to load those additional tags tables. > Actually, if you're not working on a Git checkout, I don't think you can use the tags even for the Elisp code that's part of Emacs. Why not? I do it all the time, and tried again just now: it works. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2015 15:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: monnier@iro.umontreal.ca, 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143032240931679 (code B ref 19468); Wed, 29 Apr 2015 15:47:02 +0000 Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 15:46:49 +0000 Received: from localhost ([127.0.0.1]:56525 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnUCH-0008Et-Ft for submit@debbugs.gnu.org; Wed, 29 Apr 2015 11:46:49 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:32967) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnUCF-0008EZ-99 for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 11:46:48 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NNK00500RF14I00@a-mtaout20.012.net.il> for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 18:46:40 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNK005M8RTS1460@a-mtaout20.012.net.il>; Wed, 29 Apr 2015 18:46:40 +0300 (IDT) Date: Wed, 29 Apr 2015 18:46:37 +0300 From: Eli Zaretskii In-reply-to: <554002D2.3000203@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83383jueci.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EB3A4.9090107@yandex.ru> <83egn4wbn0.fsf@gnu.org> <554002D2.3000203@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 29 Apr 2015 00:59:46 +0300 > From: Dmitry Gutov > CC: monnier@iro.umontreal.ca, 19468@debbugs.gnu.org > > But anyway, I've just opened lisp/TAGS, and I haven't been able to make `(tag-exact-match-p "...")' return t with any input and position I've tried. Probably because most tags have implicit names, so you need tag-implicit-name-match-p. For exact matches, try edit-abbrevs-map or allout-item-widget. See etc/ETAGS.EBNF for more details about explicit and implicit tag names. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2015 15:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: monnier@IRO.UMontreal.CA, 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143032242531744 (code B ref 19468); Wed, 29 Apr 2015 15:48:02 +0000 Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 15:47:05 +0000 Received: from localhost ([127.0.0.1]:56530 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnUCW-0008Fv-Q4 for submit@debbugs.gnu.org; Wed, 29 Apr 2015 11:47:05 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:49423) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnUCU-0008FA-Ib for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 11:47:03 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NNK00E00RGQ6Y00@mtaout29.012.net.il> for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 18:44:55 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNK00ECJRQV4V10@mtaout29.012.net.il>; Wed, 29 Apr 2015 18:44:55 +0300 (IDT) Date: Wed, 29 Apr 2015 18:46:06 +0300 From: Eli Zaretskii In-reply-to: <553FFC99.5080701@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <834mnzuedd.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> <838udcwbdc.fsf@gnu.org> <553FFC99.5080701@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 29 Apr 2015 00:33:13 +0300 > From: Dmitry Gutov > CC: monnier@IRO.UMontreal.CA, 19468@debbugs.gnu.org > > You could have the few "best matches" listed separately in the > beginning of the list, followed by the grouping shown today. > > What's "best matches"? I suggested using `tag-exact-match-p' in the etags backend. What's your take on this? I'd suggest first an exact match, followed by any matches that are exact but for letter-case. Note that I specifically didn't mention tag-exact-match-p, because of the implicit tag name issue, see below. > - Should xref always try to preserve the order in which xrefs are returned? > > No! This would make the UI even more dependent on the back-ends. > > Without using the order, in which matches are returned by the backend, we can't even know what the "best matches" are. Of course, we can: see above. Moreover, ideally the API to the back-end should allow the UI to control the matches applied by the back-end, so that the UI gets only the matches it wants in the first place. > What about the rest of the predicates in `find-tag-tag-order' set by `etags-recognize-tags-table'? Should we disregard all of them? Not sure what is included in "the rest". For example, I don't think it makes sense to disregard tag-implicit-name-match-p, since many tags don't have explicit names. In general, I think it would be good to have a user option that controls which predicates are used by the etags back-end. I think we should group the predicates into meaningful groups (e.g., it makes no sense to use tag-exact-match-p without tag-implicit-name-match-p). The default list of the predicates should IMO include these: tag-exact-match-p tag-implicit-name-match-p tag-symbol-match-p File-name matches and word matches are only useful in specialized searches, and partial matches are just a kind of "fire escape". From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2015 15:48:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143032243631770 (code B ref 19468); Wed, 29 Apr 2015 15:48:03 +0000 Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 15:47:16 +0000 Received: from localhost ([127.0.0.1]:56533 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnUCh-0008GK-WC for submit@debbugs.gnu.org; Wed, 29 Apr 2015 11:47:16 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:37847) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnUCe-0008G4-P3 for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 11:47:13 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NNK00700RDJKK00@mtaout25.012.net.il> for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 18:42:50 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNK005HPRNE8C30@mtaout25.012.net.il>; Wed, 29 Apr 2015 18:42:50 +0300 (IDT) Date: Wed, 29 Apr 2015 18:47:03 +0300 From: Eli Zaretskii In-reply-to: <554003FC.9060007@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <831tj3uebs.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <83lhhdwfft.fsf@gnu.org> <553EB903.9060000@yandex.ru> <83a8xswbeg.fsf@gnu.org> <554003FC.9060007@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 29 Apr 2015 01:04:44 +0300 > From: Dmitry Gutov > CC: 19468@debbugs.gnu.org > > This feature, including the new UI and API, was introduced 4 months > ago, and we still have only 2 back-ends supporting it: ELisp and Ada. > > And etags. Three backends isn't exactly the same as "no backends". etags is what we had before. Presumably, xref was introduced because it was supposed to enable additional functionality, not just wrap and change the UI of the existing functionality. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2015 15:48:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: monnier@iro.umontreal.ca, 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143032246631822 (code B ref 19468); Wed, 29 Apr 2015 15:48:04 +0000 Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 15:47:46 +0000 Received: from localhost ([127.0.0.1]:56536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnUDB-0008HC-Pn for submit@debbugs.gnu.org; Wed, 29 Apr 2015 11:47:46 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:59832) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnUD8-0008Gs-R0 for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 11:47:43 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NNK00K00RNOBJ00@mtaout26.012.net.il> for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 18:49:13 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNK00JAARY1GS20@mtaout26.012.net.il>; Wed, 29 Apr 2015 18:49:13 +0300 (IDT) Date: Wed, 29 Apr 2015 18:47:33 +0300 From: Eli Zaretskii In-reply-to: <554004B5.1080109@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83zj5rszqi.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <553EC300.9030904@yandex.ru> <553EED28.5050902@yandex.ru> <83wq0wuwgd.fsf@gnu.org> <554004B5.1080109@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 29 Apr 2015 01:07:49 +0300 > From: Dmitry Gutov > CC: monnier@iro.umontreal.ca, 19468@debbugs.gnu.org > > What alternatives were there, before xref? > > 1. M-x find-function (some even used M-. as its binding). This is limited to ELisp. > 2. C-h comment-forward RET, then click on the file name. This is limited to ELisp and built-in Emacs functions. I was talking about alternatives that can be used as part of the development environment suitable for many programming languages. If the user needs to switch the "find definition" facility each time she changes her project or programming language, it's not a good situation, and therefore such a facility cannot be considered as an alternative to etags (and ID-utils, if we are talking about finding references). > It's easy to generate TAGS for Lisp files, if one needs them. We > describe all that in the user manual. > > Could you point me to the exact section? "(info (emacs) Create Tags Table)" From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2015 15:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143032251131936 (code B ref 19468); Wed, 29 Apr 2015 15:49:02 +0000 Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 15:48:31 +0000 Received: from localhost ([127.0.0.1]:56543 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnUDv-0008J1-CA for submit@debbugs.gnu.org; Wed, 29 Apr 2015 11:48:31 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:36234) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnUDt-0008Ik-Cl for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 11:48:30 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NNK00F00RT9XC00@mtaout29.012.net.il> for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 18:47:09 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNK00G08RUL4300@mtaout29.012.net.il>; Wed, 29 Apr 2015 18:47:09 +0300 (IDT) Date: Wed, 29 Apr 2015 18:48:20 +0300 From: Eli Zaretskii In-reply-to: <5540068E.4040308@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83y4lbszp7.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB4F4.1090704@yandex.ru> <83d22owblc.fsf@gnu.org> <5540068E.4040308@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 29 Apr 2015 01:15:42 +0300 > From: Dmitry Gutov > CC: 19468@debbugs.gnu.org > > There seems some confusion here: you do now invoke xref-find-function. It's not > a function anyway, it's a variable, which different backends can set to > implement the backend interface. > > Then the confusion is the doc string's fault: it should make this > aspect clear. And if there are no back-ends currently that support > these options, I'd suggest to remove that from the doc string -- we > shouldn't advertise in the docs stuff that no one implemented. > > The doc string is about the interface: as long as a given backend implements the `references' action, `M-x xref-find-references' will display the returned list. An interface that has no known implementation doesn't really exist. I'm asking why do we advertise such a non-existing interface. > Please feel free to suggest better wording for the docstring. I already did. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2015 15:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: monnier@IRO.UMontreal.CA, 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143032253931977 (code B ref 19468); Wed, 29 Apr 2015 15:49:02 +0000 Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 15:48:59 +0000 Received: from localhost ([127.0.0.1]:56546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnUEM-0008Jh-NR for submit@debbugs.gnu.org; Wed, 29 Apr 2015 11:48:58 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:33393) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnUEL-0008JU-Dk for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 11:48:57 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NNK00500RX37G00@a-mtaout20.012.net.il> for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 18:48:51 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNK005EQRXF1470@a-mtaout20.012.net.il>; Wed, 29 Apr 2015 18:48:51 +0300 (IDT) Date: Wed, 29 Apr 2015 18:48:48 +0300 From: Eli Zaretskii In-reply-to: <554009A5.5020001@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83wq0vszof.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 29 Apr 2015 01:28:53 +0300 > From: Dmitry Gutov > CC: monnier@IRO.UMontreal.CA, 19468@debbugs.gnu.org > > M-x xref-find-references, for starters. > > It doesn't seem to work for me: it says "no references found" whatever > symbol I try, even those I know are referenced. What am I missing? > > Do you know how to implement the "all uses" search using only a tags file? I didn't try that in xref-etags-mode, I tried that with the default back-end. > Likewise for Elisp. Using ID-Utils is one possible way, I guess. Using Grep is another (much less efficient one). > So, sorry to say, both currently implemented backends don't support it. Too bad. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2015 15:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143032257732063 (code B ref 19468); Wed, 29 Apr 2015 15:50:02 +0000 Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 15:49:37 +0000 Received: from localhost ([127.0.0.1]:56551 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnUEz-0008L4-4T for submit@debbugs.gnu.org; Wed, 29 Apr 2015 11:49:37 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:51056) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnUEw-0008Kq-7m for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 11:49:35 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NNK00700RIH8Q00@mtaout27.012.net.il> for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 18:44:34 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNK000B1RQAO970@mtaout27.012.net.il>; Wed, 29 Apr 2015 18:44:34 +0300 (IDT) Date: Wed, 29 Apr 2015 18:49:25 +0300 From: Eli Zaretskii In-reply-to: <554016CB.9080202@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83vbgfszne.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <553ECA9D.6090306@yandex.ru> <831tj4wb58.fsf@gnu.org> <554016CB.9080202@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 29 Apr 2015 02:24:59 +0300 > From: Dmitry Gutov > CC: 19468@debbugs.gnu.org > > That's not so easy to wrap in a global minor mode. I'm not even sure a minor > mode would be a good approach here at all. > > Sorry, you lost me. What aspects prevent us from making a global > minor mode that uses xref-etags-mode in all buffers? > > Um, yeah, it would work, if you want xref-etags-mode in *all* buffers at all, including those that might use yet another different backend. Isn't that what a global mode is about? > Where in the documentation would you mention the key bindings? In the manual and in NEWS. > Should those be `n' and `p' instead, by default? I've found myself using these > bindings very rarely anyway, and `n' is still very close. > > Possibly. > > I'll wait for a stronger "yes" on this. Isn't that a rhetorical question, given that 'n' and 'p' are already bound to those movement commands? > There's also "C-x `". Or maybe you should > bring the equivalent of tags-loop-continue back ;-) > > We've already taken up its binding A negative argument to it could call xref-pop-marker-stack, no? > Would you be comfortable with forgetting the current list of errors after > navigating somewhere with xref? > > No, I don't think so. > > But that what happens if you run a compilation (with errors), and then call Grep. Doesn't it? No, because Grep and Compilation use different buffers for their matches. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Vitalie Spinu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2015 16:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Stefan Monnier , 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.1430323287850 (code B ref 19468); Wed, 29 Apr 2015 16:02:02 +0000 Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 16:01:27 +0000 Received: from localhost ([127.0.0.1]:56577 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnUQQ-0000De-DQ for submit@debbugs.gnu.org; Wed, 29 Apr 2015 12:01:26 -0400 Received: from mail-wg0-f53.google.com ([74.125.82.53]:33232) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnUQM-0000DM-QV for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 12:01:23 -0400 Received: by wgin8 with SMTP id n8so33502332wgi.0 for <19468@debbugs.gnu.org>; Wed, 29 Apr 2015 09:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=ZEoejT36QJgJcx5YCdjqe8Q+YzGOy4cqneb+iZuYj4s=; b=fwGnYhBXKdvqsgsCSQVCFjEfHs/jhvi8Vm4d/49ll242PsAnSNH3mFmts7IA0Fb4tk cEE19ytH1R4G7yGjD7SNlIOJkmGYA9Ot2tvDqnBVSo89U6g5zodb8hKXli5cJXc5z6// 4IdnRZELxe+ddO+6dsS4njFwrfDHg2uJssFBiE1K5aIg4snKSRjgh8JSZJzZOgfzqqdb Uady+yFgai70HPKSr7alZKcgWvlvAJ/GGaQKZbWf/WD4OJV71Y1+/tDQhr5YMHEikrlK OU1ZL+JGv9lLddORHFQ3kukFCtJdim+4v1sh1Fxd97VkuYuV0mkFHH23l1x/N/9BlJQy bCjw== X-Received: by 10.180.100.101 with SMTP id ex5mr7290343wib.13.1430323277099; Wed, 29 Apr 2015 09:01:17 -0700 (PDT) Received: from localhost (dhcp-077-251-128-242.chello.nl. [77.251.128.242]) by mx.google.com with ESMTPSA id y7sm25530902wjw.16.2015.04.29.09.01.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 09:01:16 -0700 (PDT) From: Vitalie Spinu References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <87mw1r7zef.fsf@gmail.com> <5540F7ED.6050609@yandex.ru> Date: Wed, 29 Apr 2015 18:01:15 +0200 In-Reply-To: <5540F7ED.6050609@yandex.ru> (Dmitry Gutov's message of "Wed, 29 Apr 2015 18:25:33 +0300") Message-ID: <878uda9b5g.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >>> Dmitry Gutov on Wed, 29 Apr 2015 18:25:33 +0300 wrote: > On 04/29/2015 06:00 PM, Vitalie Spinu wrote: >> Let's say I have two projects A and B. By "linked" tag tables I mean >> that both tag tables are simultaneously accessible from descendant files >> of path/to/A and path/to/B. > The etags format already has a similar feature (etags --help | grep include), > but it's only one-way, AFAIK. And if yo have 3,4,... tag tables? And some of them you need to link only occasionally for a short period of time? I hope you don't insist on building multiple new tag tables each time one needs a new "configuration" of tags. etags.el already supports lists of tag tables. It shouldn't be that difficult to re-factor it into the proposed "root-local" binding. Vitalie From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2015 16:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Vitalie Spinu Cc: 19468@debbugs.gnu.org, monnier@IRO.UMontreal.CA, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14303238991904 (code B ref 19468); Wed, 29 Apr 2015 16:12:01 +0000 Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 16:11:39 +0000 Received: from localhost ([127.0.0.1]:56599 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnUaI-0000UZ-2b for submit@debbugs.gnu.org; Wed, 29 Apr 2015 12:11:38 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:51733) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnUaD-0000Tw-D6 for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 12:11:35 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NNK00200SN0S600@a-mtaout23.012.net.il> for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 19:11:27 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNK002E2SZ2Q250@a-mtaout23.012.net.il>; Wed, 29 Apr 2015 19:11:27 +0300 (IDT) Date: Wed, 29 Apr 2015 19:11:23 +0300 From: Eli Zaretskii In-reply-to: <87mw1r7zef.fsf@gmail.com> X-012-Sender: halo1@inter.net.il Message-id: <83mw1qud78.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <87mw1r7zef.fsf@gmail.com> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Vitalie Spinu > Date: Wed, 29 Apr 2015 17:00:24 +0200 > Cc: Dmitry Gutov , 19468@debbugs.gnu.org > > I would like to be able to "link" tag tables. > > Let's say I have two projects A and B. By "linked" tag tables I mean > that both tag tables are simultaneously accessible from descendant files > of path/to/A and path/to/B. > > The UI is essentially one command - `etag-link-tag-table`. If I call > `etag-link-tag-table` from project A and choose a tag table in B then A > and B tag tables become linked, and vice versa. Simple as that. The "link" command already exists: just invoke visit-tags-table and answer YES to the question it asks. What is missing is the corresponding "unlink" command, which you didn't mention, but which I think is required, because at some point you may wish to have Emacs "forget" about A or B (or both). (Of course, you can emulate "unlink" by reloading all the tags tables you need, and answering NO to the above-mentioned question the first time. But that's sub-optimal and requires you to keep notes about which tags tables you have loaded at all times.) From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2015 17:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: monnier@IRO.UMontreal.CA, 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143032814419502 (code B ref 19468); Wed, 29 Apr 2015 17:23:02 +0000 Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 17:22:24 +0000 Received: from localhost ([127.0.0.1]:56641 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnVgl-00054U-RO for submit@debbugs.gnu.org; Wed, 29 Apr 2015 13:22:24 -0400 Received: from mail-wi0-f179.google.com ([209.85.212.179]:38594) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnVgj-00054H-Ul for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 13:22:22 -0400 Received: by wiun10 with SMTP id n10so74009922wiu.1 for <19468@debbugs.gnu.org>; Wed, 29 Apr 2015 10:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=JcDG3NG36yax6MzQD7YwY+dWt8yDiLte+5n1kLic488=; b=vYBR+vOv7slxHjB9muQUzYhnXasJAsZwg7ABadfcM37PzXphrq7OGygq/nCTHI4Scz FH89PUeuqqiLfXwARqOZbcIpMH0sBHQU2FsCyt5vNU0dE8kUoawX1bq5BVOW0pV+QEKK 9/wCaYjnTqZIgwaBYt9AWBTCNXynYEnbxnT+b+FjHX8mG6IFejaDWuwn+bavsBRgdaOz GkDcZl4yOJq9zKivHk4My9XoXisOoUOBisQLtu4bM9gaLBilDi5aabsAefptna8LRluE zyt7NOhfdYE8ftY5z8GqJIlniDV5zcQy4LgCgKHzVeqEZ4B7dwGjhnU1IPsAIhBuUHst FPOg== X-Received: by 10.194.206.66 with SMTP id lm2mr175989wjc.79.1430328136238; Wed, 29 Apr 2015 10:22:16 -0700 (PDT) Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id gs7sm22083791wib.10.2015.04.29.10.22.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 10:22:16 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <83k2wxwexb.fsf@gnu.org> <83fv7kwbow.fsf@gnu.org> <553FF4EF.4080003@yandex.ru> <838udbueku.fsf@gnu.org> From: Dmitry Gutov message-id: <55411346.5090204@yandex.ru> Date: Wed, 29 Apr 2015 20:22:14 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <838udbueku.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/29/2015 06:41 PM, Eli Zaretskii wrote: > That's a UI inconvenience, IMO. I already explained why: it requires > me to know up front whether the symbol name I'm about to type is > precise or not. And I have already explained that it has advantages as well. Interested users can rebind M-. to xref-find-apropos anyway. > We should not have "non-ideal" implementation that return radically > different results. Each query by default should yield approximately > the same result. I agree this should be improved. > That kind of thing happens every day in Emacs development, IME. > There's no way around it, if you care about some component, and > another one gets in the way, you need to fix that other component. Sure. Or sometimes, you just try to make it work well enough. > I wasn't talking about the elis backend, I was talking about the > design principles. The implementation details of the Elisp backend have nothing to do with the other languages. > No, it's a bug to be fixed. People are welcome to work on that, but I don't see it work sufficiently well and user-friendly in all cases. >> You can't use tags for non-core Elisp code anyway, such as anything in your init directory (installed packages, etc), and any Elisp files installed separately by the operating system's distribution. > > Of course I can use TAGS: I just need to load those additional tags > tables. First you have to collect the list of locations, generate TAGS at each of them, and then load them. While (okay) it is possible, it's not something we can ask the majority of users to perform. >> Actually, if you're not working on a Git checkout, I don't think you can use the tags even for the Elisp code that's part of Emacs. > > Why not? I do it all the time, and tried again just now: it works. Okay, you can, if you find out where your distribution installed the Elisp files, go there, and generate the TAGS table. Again, not something I'd ask the average user to do. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2015 17:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143032933621512 (code B ref 19468); Wed, 29 Apr 2015 17:43:02 +0000 Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 17:42:16 +0000 Received: from localhost ([127.0.0.1]:56658 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnVzz-0005at-II for submit@debbugs.gnu.org; Wed, 29 Apr 2015 13:42:15 -0400 Received: from mail-wg0-f47.google.com ([74.125.82.47]:36586) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnVzx-0005ah-M9 for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 13:42:14 -0400 Received: by wgen6 with SMTP id n6so36414172wge.3 for <19468@debbugs.gnu.org>; Wed, 29 Apr 2015 10:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=lfH6OKGPY2XuVYlfw1ok42Vx/1Hvm4amIEDxeQmGoEU=; b=FiPnvKyHYBWVJCNWuz1nQZZle+thxVTdHHBunzm6gisNsCpWNdSsmWwNja3Fh19AAQ 94BkCRqZ1UU24c2O8ZiyZCdWBZ/mr1mteoLGqK5qVeji/cXAcOBTfJegig6kFU1Ii8Nd lbWHIa84ylYWJJXy57/WjWPxi6cPZRJ27Y9pQi3DT8U6/4V8lN2FEJqu3BlfRExeDPz5 fmPLFGfqoUsjNCt+40e/tzVYo8W6STo42YbxsskkhOVptwK1wSBb0g7tiAP9d3szHUpm qrvKxd5acz9MR7awTtlSmkHZrc7aHT5WAVdSjE9UDzYHdJv7YbrOWtJoX49NKQZ03Pvg AaiA== X-Received: by 10.194.47.231 with SMTP id g7mr408398wjn.140.1430329328095; Wed, 29 Apr 2015 10:42:08 -0700 (PDT) Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id gy8sm147686wib.13.2015.04.29.10.42.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 10:42:08 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB4F4.1090704@yandex.ru> <83d22owblc.fsf@gnu.org> <5540068E.4040308@yandex.ru> <83y4lbszp7.fsf@gnu.org> From: Dmitry Gutov message-id: <554117EE.808@yandex.ru> Date: Wed, 29 Apr 2015 20:42:06 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <83y4lbszp7.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/29/2015 06:48 PM, Eli Zaretskii wrote: > An interface that has no known implementation doesn't really exist. > I'm asking why do we advertise such a non-existing interface. There is a known consumer, so implementing it would do something useful. Thus, it exists. > I already did. Remove? I'm open to other suggestions. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2015 17:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143032942021646 (code B ref 19468); Wed, 29 Apr 2015 17:44:02 +0000 Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 17:43:40 +0000 Received: from localhost ([127.0.0.1]:56662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnW1M-0005d3-4r for submit@debbugs.gnu.org; Wed, 29 Apr 2015 13:43:40 -0400 Received: from mail-wg0-f44.google.com ([74.125.82.44]:36021) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnW1J-0005co-Oq for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 13:43:38 -0400 Received: by wgen6 with SMTP id n6so36452691wge.3 for <19468@debbugs.gnu.org>; Wed, 29 Apr 2015 10:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=xZxl8hjKjmIW0Dj3jiR46KYu3oRf6Rldmvnpnb8kSok=; b=vuV1iM3jrihYegvh2VTKw4ydueXRGD/1ZcEcQSbV1m4sIAtyrXwSVHipJROEqrA9zs 0RNrAeVRvOPG+00wZ8187qwqr0QsykJ7YL/mzys4XKyGsn0Ut5b2GIECBUdFuJb8peHq Q4BEfLsW0XZkmWYlolONVckf1OHBatXBAF23tK5KmXjHTcBjoTjcG0DsVdWMj8L1LX9U okJyQ4bVDRK19c2fDCKcbO6rf/eMDmAoWqqz9xU1uMBya16oNIz0Hs5fxZCMFjggVaRn Ykjq5h7JMvbaatWcxZOdpAhYIwg4D6Bmjatb97UOywbTPkFvgHvLntjkW3zNQVidN+2H iIjQ== X-Received: by 10.194.206.66 with SMTP id lm2mr349909wjc.79.1430329412213; Wed, 29 Apr 2015 10:43:32 -0700 (PDT) Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id v3sm165688wix.8.2015.04.29.10.43.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 10:43:32 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> From: Dmitry Gutov message-id: <55411842.1020102@yandex.ru> Date: Wed, 29 Apr 2015 20:43:30 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <83wq0vszof.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/29/2015 06:48 PM, Eli Zaretskii wrote: > Using ID-Utils is one possible way, I guess. That's an interesting suggestion. Does it work on all platforms we support? Is there some existing Emacs integration? From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2015 18:00:07 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: monnier@IRO.UMontreal.CA, 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143033037023109 (code B ref 19468); Wed, 29 Apr 2015 18:00:07 +0000 Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 17:59:30 +0000 Received: from localhost ([127.0.0.1]:56671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnWGf-00060d-75 for submit@debbugs.gnu.org; Wed, 29 Apr 2015 13:59:29 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:55382) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnWGd-00060N-4I for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 13:59:28 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NNK00600XPZ2F00@a-mtaout20.012.net.il> for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 20:58:43 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNK005DJXXUR3A0@a-mtaout20.012.net.il>; Wed, 29 Apr 2015 20:58:43 +0300 (IDT) Date: Wed, 29 Apr 2015 20:58:40 +0300 From: Eli Zaretskii In-reply-to: <55411346.5090204@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83d22mu88f.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <83k2wxwexb.fsf@gnu.org> <83fv7kwbow.fsf@gnu.org> <553FF4EF.4080003@yandex.ru> <838udbueku.fsf@gnu.org> <55411346.5090204@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: monnier@IRO.UMontreal.CA, 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Wed, 29 Apr 2015 20:22:14 +0300 > > >> Actually, if you're not working on a Git checkout, I don't think you can use the tags even for the Elisp code that's part of Emacs. > > > > Why not? I do it all the time, and tried again just now: it works. > > Okay, you can, if you find out where your distribution installed the > Elisp files, go there, and generate the TAGS table. > > Again, not something I'd ask the average user to do. I don't understand why. It's a simple matter that is clearly described in the Emacs user manual, for this very reason. Quite a few development tools use databases that need to be generated when you start working on a project, and then regenerated from time to time. This is quite routine in any sizable development project, and I think many developers (a.k.a. "Emacs users") are familiar with this and won't be intimidated by the need to generate TAGS. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2015 18:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143033060023566 (code B ref 19468); Wed, 29 Apr 2015 18:04:01 +0000 Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 18:03:20 +0000 Received: from localhost ([127.0.0.1]:56679 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnWKN-000682-Bc for submit@debbugs.gnu.org; Wed, 29 Apr 2015 14:03:19 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:43967) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnWKL-00067l-80 for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 14:03:18 -0400 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NNK00I00XUG5S00@mtaout28.012.net.il> for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 21:02:01 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNK00GWPY3DJ920@mtaout28.012.net.il>; Wed, 29 Apr 2015 21:02:01 +0300 (IDT) Date: Wed, 29 Apr 2015 21:03:08 +0300 From: Eli Zaretskii In-reply-to: <55411842.1020102@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83a8xqu80z.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Wed, 29 Apr 2015 20:43:30 +0300 > > On 04/29/2015 06:48 PM, Eli Zaretskii wrote: > > > Using ID-Utils is one possible way, I guess. > > That's an interesting suggestion. Does it work on all platforms we > support? I'm not aware of a platform where it doesn't. > Is there some existing Emacs integration? Yes. It's called idutils.el, comes with the package, and presents a Grep-like UI (except that searches are much faster than Grep, and smarter, of course). I also see some support in CEDET (judging by file names). From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2015 22:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Vitalie Spinu , 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143034496718902 (code B ref 19468); Wed, 29 Apr 2015 22:03:02 +0000 Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 22:02:47 +0000 Received: from localhost ([127.0.0.1]:56763 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yna46-0004un-EN for submit@debbugs.gnu.org; Wed, 29 Apr 2015 18:02:46 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:34574) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yna44-0004uY-94 for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 18:02:44 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFAGvvdVS4rw4V/2dsb2JhbAA3gVOfQYIugQiBdQEBBAFWIwULCw4mEhQYDSSIE6IRjGQJAQIBAoM+A4NwBKNjhFg X-IPAS-Result: AnEFAGvvdVS4rw4V/2dsb2JhbAA3gVOfQYIugQiBdQEBBAFWIwULCw4mEhQYDSSIE6IRjGQJAQIBAoM+A4NwBKNjhFg X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="117840434" Received: from 184-175-14-21.dsl.teksavvy.com (HELO pastel.home) ([184.175.14.21]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2015 18:02:38 -0400 Received: by pastel.home (Postfix, from userid 20848) id 9D65B4DCE; Wed, 29 Apr 2015 18:02:37 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <87mw1r7zef.fsf@gmail.com> <5540F7ED.6050609@yandex.ru> Date: Wed, 29 Apr 2015 18:02:37 -0400 In-Reply-To: <5540F7ED.6050609@yandex.ru> (Dmitry Gutov's message of "Wed, 29 Apr 2015 18:25:33 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> Let's say I have two projects A and B. By "linked" tag tables I mean >> that both tag tables are simultaneously accessible from descendant files >> of path/to/A and path/to/B. > The etags format already has a similar feature (etags --help | grep > include), but it's only one-way, AFAIK. etags.el also has a feature for this in the `tags-table-list' variable. Stefan From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2015 22:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: monnier@iro.umontreal.ca, 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143034673221574 (code B ref 19468); Wed, 29 Apr 2015 22:33:02 +0000 Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 22:32:12 +0000 Received: from localhost ([127.0.0.1]:56770 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnaWZ-0005bt-O5 for submit@debbugs.gnu.org; Wed, 29 Apr 2015 18:32:12 -0400 Received: from mail-wi0-f181.google.com ([209.85.212.181]:35410) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnaWX-0005bc-2i for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 18:32:09 -0400 Received: by widdi4 with SMTP id di4so197186176wid.0 for <19468@debbugs.gnu.org>; Wed, 29 Apr 2015 15:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=1ukhO0hGvESMgJSh3AdIuoYD5CLycIzLI4Mbo/x2KBc=; b=NEnHTDfYYap1YintGCRM/WjhxL039bfrcRYKWGBbxooDzST5WNpmnWJTBzTugSMUdT JgkLBjV1iMOK53Ku5qMGj40lpSBXguAc13t25RnNME5IT2muC0Qg7w5m5as64tKudSxa b5pR9mI8l/D9jANCt92yeu3Xz3PeHX2XAduxbiysSyFkKPfj1wr1Z6BsOVq7C9cG0A4m t7eu8tpEez1AF+RCO0wDDjJ6M3YgH/E61nJfLr3WsVgfj8afb4nxnlVLgWryWxNhBkqi QIKPVOyOa2dJEW6oiQKtz4VPUGfLqhIN+OzWUH9TPQEq+g9L7KUepbq41vg1D50FuS+B dxRQ== X-Received: by 10.194.158.193 with SMTP id ww1mr2556609wjb.100.1430346723308; Wed, 29 Apr 2015 15:32:03 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id b1sm532980wjs.17.2015.04.29.15.32.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 15:32:03 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EB3A4.9090107@yandex.ru> <83egn4wbn0.fsf@gnu.org> <554002D2.3000203@yandex.ru> <83383jueci.fsf@gnu.org> From: Dmitry Gutov message-id: <55415BE1.8000404@yandex.ru> Date: Thu, 30 Apr 2015 01:32:01 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <83383jueci.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/29/2015 06:46 PM, Eli Zaretskii wrote: > Probably because most tags have implicit names, so you need > tag-implicit-name-match-p. For exact matches, try edit-abbrevs-map or > allout-item-widget. See etc/ETAGS.EBNF for more details about > explicit and implicit tag names. I see, thank you. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2015 22:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: monnier@IRO.UMontreal.CA, 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143034821023792 (code B ref 19468); Wed, 29 Apr 2015 22:57:02 +0000 Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 22:56:50 +0000 Received: from localhost ([127.0.0.1]:56777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnauQ-0006Bf-0x for submit@debbugs.gnu.org; Wed, 29 Apr 2015 18:56:50 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:33484) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnauO-0006BS-0W for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 18:56:48 -0400 Received: by wief7 with SMTP id f7so434353wie.0 for <19468@debbugs.gnu.org>; Wed, 29 Apr 2015 15:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=rkhLn9SfwF5BCyVBn6eYD5pkpkrPElOWBI+VwMOGoO8=; b=JCJFDsElwx/zAGYdVToFV09S0gQkRfSw1mVYH9n4Zwln+t13F3mZXWwOdRvh1tUe3u tcdW3gNYFkIOB9E6BBWP/cwxw92zw6ZfV4IA/fuHoth9h79CsIL6xmlIDpnwvKQ3m8F9 y/VB0hdC6CwJVa2eZGnJUm+jQJjo02yoD1LskZnXZ+KDTWK7sONY3lI/GUer4MGBYJd/ cL5ht6iU/I+wKtSbUbHK67z9/ivr7sOxYdcNxHEkiyHZ3Ls3wqVCA4Vh2XT/HOLNWJsf C8v2fIfPD5R8K5X41v57eEdPwLsKZcrq140IhcMmUDkwwsxpbYTknXOAd2vW9yd9v6dc p/lw== X-Received: by 10.180.7.133 with SMTP id j5mr10161930wia.84.1430348202425; Wed, 29 Apr 2015 15:56:42 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id v3sm1115677wix.8.2015.04.29.15.56.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 15:56:42 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> <838udcwbdc.fsf@gnu.org> <553FFC99.5080701@yandex.ru> <834mnzuedd.fsf@gnu.org> From: Dmitry Gutov message-id: <554161A8.30202@yandex.ru> Date: Thu, 30 Apr 2015 01:56:40 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <834mnzuedd.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/29/2015 06:46 PM, Eli Zaretskii wrote: > I'd suggest first an exact match, followed by any matches that are > exact but for letter-case. I think we've settled on "only exact matches" (to the best of backend's ability) for xref-find-definitions. However, in xref-find-apropos we shouldn't like the exact matches that much, and likely care about all matches. In that command's output we could use the order in which etags returns its results. >> Without using the order, in which matches are returned by the backend, we can't even know what the "best matches" are. > > Of course, we can: see above. The backend can. The UI can't, thus far (unless only the best matches are returned to it). > Moreover, ideally the API to the back-end should allow the UI to > control the matches applied by the back-end, so that the UI gets only > the matches it wants in the first place. Would you like to describe it in more detail? The current main options are: "give me matches for this name" and "give me matches for this regexp". There's nothing that would correspond to find-tag-tag-order. > Not sure what is included in "the rest". For example, I don't think > it makes sense to disregard tag-implicit-name-match-p, since many tags > don't have explicit names. Okay. > In general, I think it would be good to have a user option that > controls which predicates are used by the etags back-end. I think we > should group the predicates into meaningful groups (e.g., it makes no > sense to use tag-exact-match-p without tag-implicit-name-match-p). > The default list of the predicates should IMO include these: > > tag-exact-match-p tag-implicit-name-match-p tag-symbol-match-p See the newly added defvar `etags-xref-find-definitions-tag-order'. The last element seems a bit too lax to me, but it's up to you. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2015 23:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143034864124495 (code B ref 19468); Wed, 29 Apr 2015 23:04:02 +0000 Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 23:04:01 +0000 Received: from localhost ([127.0.0.1]:56782 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ynb1M-0006Mw-O1 for submit@debbugs.gnu.org; Wed, 29 Apr 2015 19:04:01 -0400 Received: from mail-wg0-f48.google.com ([74.125.82.48]:32982) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ynb1K-0006Mj-2d for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 19:03:58 -0400 Received: by wgin8 with SMTP id n8so44166960wgi.0 for <19468@debbugs.gnu.org>; Wed, 29 Apr 2015 16:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Uao7R0fKIwcGT8VLHoNbjwIiy3QZ020yD3Ap8Gx49wM=; b=tnkbEowVc27EJHNcTHFHEDBsdAm49hSvecOguCheBBF368OWQygg0Lup+AhpIzNhFh MWi0He9TEttDNkFzPIdLjnu9ar/bO5ywT6d1AteYj5x2fziZpNE3EBJ1bumNDAHj/iBn wsLZyv1hUhrHmg5dlnAbMyLyWCT8SNxWYdVnutbzrBhU4g9Y8t5ayaX4sl7iZPgRzEGR TIQmbcRVEnNPHPDAW/YRsZvsIv069rA4etF5rSz6/0/ysv3PNUM+0NECnYhLRfnlsWo1 SSWs81bR+9xm3Pj0pVDxQn2piNLPB9M5yBBFr44P77+0a0zYy+bL7YYOD3Vsn6d1jyKn ClEQ== X-Received: by 10.181.11.193 with SMTP id ek1mr10093266wid.15.1430348632404; Wed, 29 Apr 2015 16:03:52 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id em18sm618391wjd.19.2015.04.29.16.03.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 16:03:52 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <553ECA9D.6090306@yandex.ru> <831tj4wb58.fsf@gnu.org> <554016CB.9080202@yandex.ru> <83vbgfszne.fsf@gnu.org> From: Dmitry Gutov message-id: <55416356.7070601@yandex.ru> Date: Thu, 30 Apr 2015 02:03:50 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <83vbgfszne.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/29/2015 06:49 PM, Eli Zaretskii wrote: > Isn't that what a global mode is about? If it's what you want, yes. (Nitpick: a "globalized" minor mode is about that; a global minor mode can do whatever). > In the manual and in NEWS. It would be helpful if you could outline the needed changes in the manual: what sections to edit, where, and whether some sections should be added or removed. > Isn't that a rhetorical question, given that 'n' and 'p' are already > bound to those movement commands? No, just a stupid one; I forgot they're already bound. But doesn't that take care of your concern as well (about `.' and `,' bindings)? > A negative argument to it could call xref-pop-marker-stack, no? Won't work for me: adding an extra step to call `xref-pop-marker-stack' would be counter-productive. > No, because Grep and Compilation use different buffers for their > matches. Right, but you lose the current errors queue, so to speak, if you call Grep in the middle of following Compilation errors. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 30 Apr 2015 13:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: monnier@IRO.UMontreal.CA, 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143040171821908 (code B ref 19468); Thu, 30 Apr 2015 13:49:02 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Apr 2015 13:48:38 +0000 Received: from localhost ([127.0.0.1]:57118 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnopR-0005hH-BK for submit@debbugs.gnu.org; Thu, 30 Apr 2015 09:48:38 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:51988) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnopN-0005gz-VT for 19468@debbugs.gnu.org; Thu, 30 Apr 2015 09:48:35 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NNM00E00GI8QE00@mtaout27.012.net.il> for 19468@debbugs.gnu.org; Thu, 30 Apr 2015 16:43:28 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNM00CY7GSG2130@mtaout27.012.net.il>; Thu, 30 Apr 2015 16:43:28 +0300 (IDT) Date: Thu, 30 Apr 2015 16:48:20 +0300 From: Eli Zaretskii In-reply-to: <554161A8.30202@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83618du3q3.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> <838udcwbdc.fsf@gnu.org> <553FFC99.5080701@yandex.ru> <834mnzuedd.fsf@gnu.org> <554161A8.30202@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: monnier@IRO.UMontreal.CA, 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Thu, 30 Apr 2015 01:56:40 +0300 > > On 04/29/2015 06:46 PM, Eli Zaretskii wrote: > > > I'd suggest first an exact match, followed by any matches that are > > exact but for letter-case. > > I think we've settled on "only exact matches" (to the best of backend's > ability) for xref-find-definitions. I believe the default in Emacs is to use caseless searches in these situations, and leave it to the user to either customize case-fold-search or type the exact letter-case if she wants such exact matches. With languages that customarily use both letter-cases, I see no reason to deviate from that practice. > However, in xref-find-apropos we shouldn't like the exact matches that > much, and likely care about all matches. Yes. > In that command's output we could use the order in which etags > returns its results. I agree. > >> Without using the order, in which matches are returned by the backend, we can't even know what the "best matches" are. > > > > Of course, we can: see above. > > The backend can. The UI can't, thus far (unless only the best matches > are returned to it). If it can't, it's probably because no one coded that. But the rules are not so complex, so it's not inconceivable that such code could exist in the UI. > > Moreover, ideally the API to the back-end should allow the UI to > > control the matches applied by the back-end, so that the UI gets only > > the matches it wants in the first place. > > Would you like to describe it in more detail? The current main options > are: "give me matches for this name" and "give me matches for this > regexp". There's nothing that would correspond to find-tag-tag-order. Why not learn from find-tag-tag-order, and allow the same categories of matches as it uses, sans those that make no sense outside of the TAGS data? > > In general, I think it would be good to have a user option that > > controls which predicates are used by the etags back-end. I think we > > should group the predicates into meaningful groups (e.g., it makes no > > sense to use tag-exact-match-p without tag-implicit-name-match-p). > > The default list of the predicates should IMO include these: > > > > tag-exact-match-p tag-implicit-name-match-p tag-symbol-match-p > > See the newly added defvar `etags-xref-find-definitions-tag-order'. > > The last element seems a bit too lax to me, but it's up to you. Thanks, I will take a look soon. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 30 Apr 2015 13:50:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143040180222056 (code B ref 19468); Thu, 30 Apr 2015 13:50:06 +0000 Received: (at 19468) by debbugs.gnu.org; 30 Apr 2015 13:50:02 +0000 Received: from localhost ([127.0.0.1]:57123 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ynoqm-0005jd-HX for submit@debbugs.gnu.org; Thu, 30 Apr 2015 09:50:00 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:63263) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ynoqk-0005jO-1m for 19468@debbugs.gnu.org; Thu, 30 Apr 2015 09:49:58 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NNM00100GVXTI00@a-mtaout22.012.net.il> for 19468@debbugs.gnu.org; Thu, 30 Apr 2015 16:49:50 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNM001WAH31SU10@a-mtaout22.012.net.il>; Thu, 30 Apr 2015 16:49:50 +0300 (IDT) Date: Thu, 30 Apr 2015 16:49:49 +0300 From: Eli Zaretskii In-reply-to: <55416356.7070601@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <834mnxu3nm.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <553ECA9D.6090306@yandex.ru> <831tj4wb58.fsf@gnu.org> <554016CB.9080202@yandex.ru> <83vbgfszne.fsf@gnu.org> <55416356.7070601@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Thu, 30 Apr 2015 02:03:50 +0300 > > > Isn't that a rhetorical question, given that 'n' and 'p' are already > > bound to those movement commands? > > No, just a stupid one; I forgot they're already bound. But doesn't that > take care of your concern as well (about `.' and `,' bindings)? I hope so, yes. > > No, because Grep and Compilation use different buffers for their > > matches. > > Right, but you lose the current errors queue, so to speak, if you call > Grep in the middle of following Compilation errors. Maybe I didn't try too hard, but it didn't happen to me when I did. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2015 02:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14304472502471 (code B ref 19468); Fri, 01 May 2015 02:28:02 +0000 Received: (at 19468) by debbugs.gnu.org; 1 May 2015 02:27:30 +0000 Received: from localhost ([127.0.0.1]:57971 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yo0fp-0000dm-9Z for submit@debbugs.gnu.org; Thu, 30 Apr 2015 22:27:29 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:33994) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yo0fm-0000dU-4w for 19468@debbugs.gnu.org; Thu, 30 Apr 2015 22:27:27 -0400 Received: by wicmx19 with SMTP id mx19so24975316wic.1 for <19468@debbugs.gnu.org>; Thu, 30 Apr 2015 19:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=8mVfm9XjEndMsmz34RDi7/5cZCK9wxv8TnZgF+qBymw=; b=zP3vffeHKhRnlHz8t2mZGMWqCg7ZQ8W8gN5h+SGr+hxsjRiiK9F/ZXCdmm/xX4xiuP zUpwD1rw6y7lhh6MvmbxNpn+330Zwy+VWuO6EcdD2I1dCVJKDgFH1tI+siaW7gH058V2 XkSqBByalK71PTNQikbogiinjbrW2AOh4VJQX+kI/FGqdYW4g6T7lD0oEZuJxS4Nrzcp L2KlMv/5AHmD/foVMZxu6x5Gezz4jEhY7v+tprj8WszBz8vQNr06eZBtxsrJe5Oktoyb vuBtbC/u1817cVbMnMhSiZkpaPjmiQWE6v0U3yNEXEFyGS1yLyKBE0aBlybe1EGWsHOU WGFQ== X-Received: by 10.194.24.103 with SMTP id t7mr13679073wjf.15.1430447240378; Thu, 30 Apr 2015 19:27:20 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id dg8sm5751285wjc.9.2015.04.30.19.27.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Apr 2015 19:27:20 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> <838udcwbdc.fsf@gnu.org> <553FFC99.5080701@yandex.ru> <834mnzuedd.fsf@gnu.org> <554161A8.30202@yandex.ru> <83618du3q3.fsf@gnu.org> From: Dmitry Gutov message-id: <5542E486.2010107@yandex.ru> Date: Fri, 1 May 2015 05:27:18 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <83618du3q3.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/30/2015 04:48 PM, Eli Zaretskii wrote: > I believe the default in Emacs is to use caseless searches in these > situations, and leave it to the user to either customize > case-fold-search or type the exact letter-case if she wants such exact > matches. With languages that customarily use both letter-cases, I see > no reason to deviate from that practice. Yeah, that still works like that. "Followed by any matches ... but for letter-case" simply means to me to use case-insensitive matching in the first place, since the backend doesn't return matches in groups. However, the kind of matches could be included in the "location group" name. Or we could even allow groups to nest somehow (similarly to semantic-symref output, which nests tags within functions, within files). However, this idea alone won't preserve the ordering of groups. > If it can't, it's probably because no one coded that. But the rules > are not so complex, so it's not inconceivable that such code could > exist in the UI. Still, that doesn't sound like a good idea. Backends know their languages better. > Why not learn from find-tag-tag-order, and allow the same categories > of matches as it uses, sans those that make no sense outside of the > TAGS data? From where I'm standing, that's a customization preference, not a design suggestion. The latter would include a proposal of changes to the xref-find-function interface. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2015 06:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143046276127286 (code B ref 19468); Fri, 01 May 2015 06:46:02 +0000 Received: (at 19468) by debbugs.gnu.org; 1 May 2015 06:46:01 +0000 Received: from localhost ([127.0.0.1]:58060 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yo4i0-00075x-Tu for submit@debbugs.gnu.org; Fri, 01 May 2015 02:46:01 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:51479) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yo4hx-00075i-5T for 19468@debbugs.gnu.org; Fri, 01 May 2015 02:45:58 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NNN00L00RRKC200@mtaout25.012.net.il> for 19468@debbugs.gnu.org; Fri, 01 May 2015 09:41:35 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNN009QBRXBUDA0@mtaout25.012.net.il>; Fri, 01 May 2015 09:41:35 +0300 (IDT) Date: Fri, 01 May 2015 09:45:51 +0300 From: Eli Zaretskii In-reply-to: <5542E486.2010107@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83k2wsssm8.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> <838udcwbdc.fsf@gnu.org> <553FFC99.5080701@yandex.ru> <834mnzuedd.fsf@gnu.org> <554161A8.30202@yandex.ru> <83618du3q3.fsf@gnu.org> <5542E486.2010107@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Fri, 1 May 2015 05:27:18 +0300 > > On 04/30/2015 04:48 PM, Eli Zaretskii wrote: > > > I believe the default in Emacs is to use caseless searches in these > > situations, and leave it to the user to either customize > > case-fold-search or type the exact letter-case if she wants such exact > > matches. With languages that customarily use both letter-cases, I see > > no reason to deviate from that practice. > > Yeah, that still works like that. "Followed by any matches ... but for > letter-case" simply means to me to use case-insensitive matching in the > first place, since the backend doesn't return matches in groups. I'd still suggest to place the exact matches first. The UI could do that. > > If it can't, it's probably because no one coded that. But the rules > > are not so complex, so it's not inconceivable that such code could > > exist in the UI. > > Still, that doesn't sound like a good idea. Backends know their > languages better. I don't see anything language-specific here. Etags.el has no language-specific knowledge, either (it is delegated to etags.c). Like I said elsewhere, I think making the UI too dumb might give us sub-optimal design, wrt how functionality is divided between the UI and the back-ends, and in particular produce more of unhappy user experiences caused by the UI relying on the back-ends too much, and the back-ends differing between them too much. Case sensitivity, partial matches, and other similar stuff employed by etags, and conceptually by any other similar facility, has almost nothing to do with languages. And if (and when) we want to support match rules that do depend on languages, the API should allow specifying such rules to the back-end, and the back-end should DTRT when it receives a spec it cannot support. For example, if the UI requests only exact letter-case match, and the back-end is for a case-insensitive language, that back-end should produce caseless matches nonetheless. > > Why not learn from find-tag-tag-order, and allow the same categories > > of matches as it uses, sans those that make no sense outside of the > > TAGS data? > > From where I'm standing, that's a customization preference, not a > design suggestion. The latter would include a proposal of changes to the > xref-find-function interface. I stopped short of providing a complete proposal. My design suggestion is to generalize and abstract the match types used by etags. Customization preferences might then control which subset of the set of match types are used for each query. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2015 11:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143047967127419 (code B ref 19468); Fri, 01 May 2015 11:28:02 +0000 Received: (at 19468) by debbugs.gnu.org; 1 May 2015 11:27:51 +0000 Received: from localhost ([127.0.0.1]:58163 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yo96l-00078B-0M for submit@debbugs.gnu.org; Fri, 01 May 2015 07:27:51 -0400 Received: from mail-wg0-f53.google.com ([74.125.82.53]:34155) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yo96i-00077t-UP for 19468@debbugs.gnu.org; Fri, 01 May 2015 07:27:49 -0400 Received: by wgso17 with SMTP id o17so88535984wgs.1 for <19468@debbugs.gnu.org>; Fri, 01 May 2015 04:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=JmYUhG6hGJcopQ9Gj63cYsm3HKCYI4I9DbS7j8z1kt0=; b=jyam7/+uWq6pHhmRelmQfw6frj6vTHOrr8la6t/mbM3LE4+rNchUOc/ofDlGWyCeQe t9PVDLsf76r/oH6pZF7fTBnWLPwpcqz7fkab/1F6ttfI61W63iP5PKmZq5uI+3JyUn/d e9OgY5TC9Vmyi1CWlhLt9rq+uZS21MqCoD8sImJ4THZs8Z4knHoY2iSXfF958HHJLoXl 69D+XZ3gtm6+KRiZkPw9bqvQ5lsisAqUFtIhbShHzsqSn89c6i12taqWIMXfSIEDrCck uN4oxXi68gu1cLtXWFzKQfVvpgxj6LoViILRlaRUS5nn7i0RSZxbuhK0WIaL7TokhMVm oUUg== X-Received: by 10.180.77.83 with SMTP id q19mr13472000wiw.89.1430479663206; Fri, 01 May 2015 04:27:43 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id cf12sm7265345wjb.10.2015.05.01.04.27.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 May 2015 04:27:42 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> <838udcwbdc.fsf@gnu.org> <553FFC99.5080701@yandex.ru> <834mnzuedd.fsf@gnu.org> <554161A8.30202@yandex.ru> <83618du3q3.fsf@gnu.org> <5542E486.2010107@yandex.ru> <83k2wsssm8.fsf@gnu.org> From: Dmitry Gutov message-id: <5543632C.6000306@yandex.ru> Date: Fri, 1 May 2015 14:27:40 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <83k2wsssm8.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/01/2015 09:45 AM, Eli Zaretskii wrote: > I don't see anything language-specific here. Etags.el has no > language-specific knowledge, either (it is delegated to etags.c). elis-mode.el does. In this case, it's using find-func.el, which uses the information we have about Elisp environment at runtime. Here's another example: The point is on a foo.bar() call in a Java-like language. Or maybe C++. bar is present in classes A, B and C. If the parser knows the type of foo to be A, the backend employing it can bring us to the one definition. If, however, the backend returns the xrefs for A#foo, B#foo and C#foo, there's no way the UI could distinguish between them. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2015 13:00:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14304851459397 (code B ref 19468); Fri, 01 May 2015 13:00:06 +0000 Received: (at 19468) by debbugs.gnu.org; 1 May 2015 12:59:05 +0000 Received: from localhost ([127.0.0.1]:58197 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoAX2-0002RU-G4 for submit@debbugs.gnu.org; Fri, 01 May 2015 08:59:04 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:33461) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoAWy-0002Qt-AW for 19468@debbugs.gnu.org; Fri, 01 May 2015 08:59:01 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NNO00N008RTMA00@mtaout24.012.net.il> for 19468@debbugs.gnu.org; Fri, 01 May 2015 15:48:34 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNO00G2D8WYC170@mtaout24.012.net.il>; Fri, 01 May 2015 15:48:34 +0300 (IDT) Date: Fri, 01 May 2015 15:57:12 +0300 From: Eli Zaretskii In-reply-to: <5543632C.6000306@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <834mnwsbfb.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> <838udcwbdc.fsf@gnu.org> <553FFC99.5080701@yandex.ru> <834mnzuedd.fsf@gnu.org> <554161A8.30202@yandex.ru> <83618du3q3.fsf@gnu.org> <5542E486.2010107@yandex.ru> <83k2wsssm8.fsf@gnu.org> <5543632C.6000306@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Fri, 1 May 2015 14:27:40 +0300 > > On 05/01/2015 09:45 AM, Eli Zaretskii wrote: > > > I don't see anything language-specific here. Etags.el has no > > language-specific knowledge, either (it is delegated to etags.c). > > elis-mode.el does. In this case, it's using find-func.el, which uses the > information we have about Elisp environment at runtime. Sorry, I don't understand what "Elisp environment at runtime" means in practice, or how it's used to affect what results are returned for a query. > The point is on a foo.bar() call in a Java-like language. Or maybe C++. > > bar is present in classes A, B and C. > > If the parser knows the type of foo to be A, the backend employing it > can bring us to the one definition. If, however, the backend returns the > xrefs for A#foo, B#foo and C#foo, there's no way the UI could > distinguish between them. That's the case where the UI should instruct the back-end what it needs, because the back-end doesn't know which of these alternatives is the right one. If the user wants all bar functions, or maybe those whose parent class matches some regexp, not just the one from the class instance at point, then producing only one match would be wrong, and the UI won't be able to correct that. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2015 14:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143049188520715 (code B ref 19468); Fri, 01 May 2015 14:52:02 +0000 Received: (at 19468) by debbugs.gnu.org; 1 May 2015 14:51:25 +0000 Received: from localhost ([127.0.0.1]:58825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoCHk-0005O2-Ez for submit@debbugs.gnu.org; Fri, 01 May 2015 10:51:24 -0400 Received: from mail-wg0-f43.google.com ([74.125.82.43]:35741) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoCHi-0005No-GM for 19468@debbugs.gnu.org; Fri, 01 May 2015 10:51:23 -0400 Received: by wgyo15 with SMTP id o15so92769453wgy.2 for <19468@debbugs.gnu.org>; Fri, 01 May 2015 07:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=pnIdlg1Ck+pVnZkOMIZDXLzIf2w20cBY60PXLNCnnkA=; b=LcvB8T+dzy6J5lixBOv0giQsMjrtkyrUqapdPu9zTgQsmfwTHe3lV6Q7M0EBShz+3Q w4XTtmKnrCmuWNtcUGBZGdqKflIGBbluUyWD95EpxkPxkG3By5TfLMIVczPKpkCkcVPY 9VrIX2toF3OUS9sSxr0X3S8G+bbaHL4N1RV1D6lM94D6dIhrJXT/RCA963Vb5i1Vgken z7mP11kqgGGEHpAmxXHLpEs72rAWhS/M52+SkkptqhezBvqDw/IO9exVKoZ6Di5JZJsJ /+eNaAcW+VA+JqSMbY1nRb2sPOogjjh5RTYwJ7o7QVzrSjuViFZrm+GCZ9qvw3LS7QlD 16kg== X-Received: by 10.180.78.199 with SMTP id d7mr14910337wix.94.1430491876774; Fri, 01 May 2015 07:51:16 -0700 (PDT) Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id i6sm7876264wjf.29.2015.05.01.07.51.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 May 2015 07:51:16 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> <838udcwbdc.fsf@gnu.org> <553FFC99.5080701@yandex.ru> <834mnzuedd.fsf@gnu.org> <554161A8.30202@yandex.ru> <83618du3q3.fsf@gnu.org> <5542E486.2010107@yandex.ru> <83k2wsssm8.fsf@gnu.org> <5543632C.6000306@yandex.ru> <834mnwsbfb.fsf@gnu.org> From: Dmitry Gutov message-id: <554392E2.7080109@yandex.ru> Date: Fri, 1 May 2015 17:51:14 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <834mnwsbfb.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/01/2015 03:57 PM, Eli Zaretskii wrote: > Sorry, I don't understand what "Elisp environment at runtime" means in > practice, or how it's used to affect what results are returned for a > query. find-func knows about defined functions and defined variables. elisp-mode knows that a function usually goes after a paren, and a variable - after a space (to simplify things). Thus, elisp-xref-find could narrow the search space based on whether there is a paren before the symbol at point (we don't do that, partially because the situation is more complicated; but we should, in the future). A language-agnostic UI won't ever be able to do so. > That's the case where the UI should instruct the back-end what it > needs, because the back-end doesn't know which of these alternatives > is the right one. If the user wants all bar functions, or maybe those > whose parent class matches some regexp, not just the one from the > class instance at point, then producing only one match would be wrong, > and the UI won't be able to correct that. If the user calls xref-find-definitions, we consider that to see the definition of the function called at point (or definitions, if virtual dispatch is unavoidable, such as in case of a Java interface, and there are several options), but not more. For more lax matching options, the user will call xref-find-apropos. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2015 18:15:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org, Dmitry Gutov Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143050405520254 (code B ref 19468); Fri, 01 May 2015 18:15:03 +0000 Received: (at 19468) by debbugs.gnu.org; 1 May 2015 18:14:15 +0000 Received: from localhost ([127.0.0.1]:58929 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoFS2-0005Gb-EX for submit@debbugs.gnu.org; Fri, 01 May 2015 14:14:14 -0400 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:58920) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoFS0-0005GT-UU for 19468@debbugs.gnu.org; Fri, 01 May 2015 14:14:13 -0400 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id CB3529C131; Fri, 1 May 2015 14:14:11 -0400 (EDT) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 31EC31E5838; Fri, 1 May 2015 14:13:47 -0400 (EDT) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 1B6F1B40E9; Fri, 1 May 2015 14:13:47 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83zja6b3tc.fsf@gnu.org> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> <838udcwbdc.fsf@gnu.org> <553FFC99.5080701@yandex.ru> <834mnzuedd.fsf@gnu.org> <554161A8.30202@yandex.ru> <83618du3q3.fsf@gnu.org> <5542E486.2010107@yandex.ru> <83k2wsssm8.fsf@gnu.org> <5543632C.6000306@yandex.ru> <834mnwsbfb.fsf@gnu.org> Date: Fri, 01 May 2015 14:13:47 -0400 In-Reply-To: <834mnwsbfb.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 01 May 2015 15:57:12 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) >> bar is present in classes A, B and C. >> If the parser knows the type of foo to be A, the backend employing it >> can bring us to the one definition. If, however, the backend returns the >> xrefs for A#foo, B#foo and C#foo, there's no way the UI could >> distinguish between them. > That's the case where the UI should instruct the back-end what it > needs, because the back-end doesn't know which of these alternatives > is the right one. You got it backwards: here, only the backend (which knows about the language's rules) can know, by asking the compiler. Remember: when you hit M-., the backend is asked to find the definition of the entity under point (so it has the complete context of occurrence of "bar" and can figure out that it's looking for the "bar" of class "A"), not the definition of a context-deprived "bar" identifier. Stefan From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2015 18:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143050550922651 (code B ref 19468); Fri, 01 May 2015 18:39:02 +0000 Received: (at 19468) by debbugs.gnu.org; 1 May 2015 18:38:29 +0000 Received: from localhost ([127.0.0.1]:58933 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoFpT-0005tG-DS for submit@debbugs.gnu.org; Fri, 01 May 2015 14:38:28 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:44169) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoFpP-0005sw-BM for 19468@debbugs.gnu.org; Fri, 01 May 2015 14:38:24 -0400 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NNO00E00OQDJQ00@mtaout28.012.net.il> for 19468@debbugs.gnu.org; Fri, 01 May 2015 21:37:10 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNO00D2VP1XO220@mtaout28.012.net.il>; Fri, 01 May 2015 21:37:10 +0300 (IDT) Date: Fri, 01 May 2015 21:38:01 +0300 From: Eli Zaretskii In-reply-to: <554392E2.7080109@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83oam4qh2u.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> <838udcwbdc.fsf@gnu.org> <553FFC99.5080701@yandex.ru> <834mnzuedd.fsf@gnu.org> <554161A8.30202@yandex.ru> <83618du3q3.fsf@gnu.org> <5542E486.2010107@yandex.ru> <83k2wsssm8.fsf@gnu.org> <5543632C.6000306@yandex.ru> <834mnwsbfb.fsf@gnu.org> <554392E2.7080109@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Fri, 1 May 2015 17:51:14 +0300 > > On 05/01/2015 03:57 PM, Eli Zaretskii wrote: > > > Sorry, I don't understand what "Elisp environment at runtime" means in > > practice, or how it's used to affect what results are returned for a > > query. > > find-func knows about defined functions and defined variables. > elisp-mode knows that a function usually goes after a paren, and a > variable - after a space (to simplify things). > > Thus, elisp-xref-find could narrow the search space based on whether > there is a paren before the symbol at point (we don't do that, partially > because the situation is more complicated; but we should, in the > future). A language-agnostic UI won't ever be able to do so. A language-agnostic UI could well ask the back-end for variables, or for functions, or for both, or whatever. Like I said: some functionality must reside in the back-end, but the UI must control it, instead of blindly trusting its defaults. When we blindly trust the defaults of each back-end, we get what triggered this discussion, because etags' default is to produce a 140-long list of potential matches, which elisp-mode's xref default is to produce only one. In most of my use cases, neither is TRT. > > That's the case where the UI should instruct the back-end what it > > needs, because the back-end doesn't know which of these alternatives > > is the right one. If the user wants all bar functions, or maybe those > > whose parent class matches some regexp, not just the one from the > > class instance at point, then producing only one match would be wrong, > > and the UI won't be able to correct that. > > If the user calls xref-find-definitions, we consider that to see the > definition of the function called at point (or definitions, if virtual > dispatch is unavoidable, such as in case of a Java interface, and there > are several options), but not more. We shall never second-guess the user. I already described an important class of use cases where this assumption is simply wrong. It shouldn't probably even be the default. > For more lax matching options, the user will call xref-find-apropos. It's an annoyance to have to use more than one command for a single purpose. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2015 18:45:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143050586323209 (code B ref 19468); Fri, 01 May 2015 18:45:03 +0000 Received: (at 19468) by debbugs.gnu.org; 1 May 2015 18:44:23 +0000 Received: from localhost ([127.0.0.1]:58941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoFvD-00062G-BQ for submit@debbugs.gnu.org; Fri, 01 May 2015 14:44:23 -0400 Received: from mail-wg0-f54.google.com ([74.125.82.54]:35356) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoFvA-000620-QT for 19468@debbugs.gnu.org; Fri, 01 May 2015 14:44:21 -0400 Received: by wgyo15 with SMTP id o15so97886689wgy.2 for <19468@debbugs.gnu.org>; Fri, 01 May 2015 11:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=9SMF6c3sdRBJchCt3lViT+1WlrczTVs2VmEykQ7hu+k=; b=Tc5p7t/FvHwa92kIzxcs1EKAHwtmdMBlKsVE+OVrx/+ZpW3WpKGtUBqpEPrK+LmCo6 x6MRuGeYHhM/2f7ulawsnTEUcGP3/NEB1Af1hCDteRZn23JCD4Kj/qteFYlBz3MEQVAc FSj3uikybxLkAfwYCniAcqLXpQYZyGIQuIZfmZz6ikTMm0j8Qo4AEoncalYDmRo3B7pw 9rQyDDvsi626GxSY+bLdGmuA9BtfRhKUHQNVgZYNGfWISf4rOz4bOl0XWG4mRBhrqj5X dT0PQS2MulJ4ooTvKN6B0elbGbUSDIvgjAZrk2Il+ExUEYqfinlgMVMCbdGEG5OiIKko w3qA== X-Received: by 10.180.84.65 with SMTP id w1mr16377093wiy.20.1430505855194; Fri, 01 May 2015 11:44:15 -0700 (PDT) Received: from [192.168.1.54] (cpe-269316.ip.primehome.com. [78.158.159.68]) by mx.google.com with ESMTPSA id ex5sm7789136wib.2.2015.05.01.11.44.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 May 2015 11:44:15 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> <838udcwbdc.fsf@gnu.org> <553FFC99.5080701@yandex.ru> <834mnzuedd.fsf@gnu.org> <554161A8.30202@yandex.ru> <83618du3q3.fsf@gnu.org> <5542E486.2010107@yandex.ru> <83k2wsssm8.fsf@gnu.org> <5543632C.6000306@yandex.ru> <834mnwsbfb.fsf@gnu.org> <554392E2.7080109@yandex.ru> <83oam4qh2u.fsf@gnu.org> From: Dmitry Gutov message-id: <5543C97C.6050000@yandex.ru> Date: Fri, 1 May 2015 21:44:12 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <83oam4qh2u.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/01/2015 09:38 PM, Eli Zaretskii wrote: > A language-agnostic UI could well ask the back-end for variables, or > for functions, or for both, or whatever. Why would it ask about "functions". How would it know about functions, or that we want a function right now? > because etags' default is to produce a 140-long list > of potential matches, which elisp-mode's xref default is to produce > only one. In most of my use cases, neither is TRT. That is no longer true. You should build the current master. > We shall never second-guess the user. I already described an > important class of use cases where this assumption is simply wrong. > It shouldn't probably even be the default. Either I didn't understand it, or wasn't convinced. > It's an annoyance to have to use more than one command for a single > purpose. By default, I don't want to see the list at all, most of the time, just jump to the only match. We won't have that if xref-find-definitions is lax. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2015 19:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143050816526659 (code B ref 19468); Fri, 01 May 2015 19:23:02 +0000 Received: (at 19468) by debbugs.gnu.org; 1 May 2015 19:22:45 +0000 Received: from localhost ([127.0.0.1]:58945 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoGWK-0006vu-Ng for submit@debbugs.gnu.org; Fri, 01 May 2015 15:22:45 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:40924) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoGWH-0006vf-PO for 19468@debbugs.gnu.org; Fri, 01 May 2015 15:22:43 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NNO00M00Q6XYH00@mtaout24.012.net.il> for 19468@debbugs.gnu.org; Fri, 01 May 2015 22:13:48 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNO00KA9QR0DZ40@mtaout24.012.net.il>; Fri, 01 May 2015 22:13:48 +0300 (IDT) Date: Fri, 01 May 2015 22:22:19 +0300 From: Eli Zaretskii In-reply-to: <5543C97C.6050000@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83h9rwqf10.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> <838udcwbdc.fsf@gnu.org> <553FFC99.5080701@yandex.ru> <834mnzuedd.fsf@gnu.org> <554161A8.30202@yandex.ru> <83618du3q3.fsf@gnu.org> <5542E486.2010107@yandex.ru> <83k2wsssm8.fsf@gnu.org> <5543632C.6000306@yandex.ru> <834mnwsbfb.fsf@gnu.org> <554392E2.7080109@yandex.ru> <83oam4qh2u.fsf@gnu.org> <5543C97C.6050000@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Fri, 1 May 2015 21:44:12 +0300 > > On 05/01/2015 09:38 PM, Eli Zaretskii wrote: > > > A language-agnostic UI could well ask the back-end for variables, or > > for functions, or for both, or whatever. > > Why would it ask about "functions". How would it know about functions, > or that we want a function right now? If it doesn't, it should ask the user. > > because etags' default is to produce a 140-long list > > of potential matches, which elisp-mode's xref default is to produce > > only one. In most of my use cases, neither is TRT. > > That is no longer true. You should build the current master. The example is still valid. How do you know another back-end won't do something similar? > > It's an annoyance to have to use more than one command for a single > > purpose. > > By default, I don't want to see the list at all, most of the time, just > jump to the only match. We won't have that if xref-find-definitions is lax. Note the "I" vs the "we". If _you_ want to see only one match most of the time, you should be able to customize the feature to do just that. Others could customize it differently, according to their use cases. It will still be the same command, though. Other IDEs ask the user explicitly to specify how wide she wants the search and how detailed the results. We could do that as well, although I think it's less Emacsy. But having just one level is never right in such cases. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2015 20:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.1430512602826 (code B ref 19468); Fri, 01 May 2015 20:37:02 +0000 Received: (at 19468) by debbugs.gnu.org; 1 May 2015 20:36:42 +0000 Received: from localhost ([127.0.0.1]:58959 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoHfu-0000DG-4x for submit@debbugs.gnu.org; Fri, 01 May 2015 16:36:42 -0400 Received: from mail-wg0-f53.google.com ([74.125.82.53]:35395) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoHfr-0000D2-7f for 19468@debbugs.gnu.org; Fri, 01 May 2015 16:36:40 -0400 Received: by wgyo15 with SMTP id o15so100067030wgy.2 for <19468@debbugs.gnu.org>; Fri, 01 May 2015 13:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=ebjzAng9SiD986u1Nor79jEHZcIE+KgG0kPBnzlESjc=; b=oTC1R3fp+yJgyMY4c0O2HbebbDNqZOQbvr1Xlt2I2bPv/Mt7PH/G0yp+IDNqmXJ8PS kx1u1ILUNVIW6McpzFIglW0jXTVNoLiqsNutGVlBhkt6Uw+IJPzm3H74bo2nbvgr60KG hUv9+j6l5Xq2QYI1EBgL8wG82pOOHwEuckLXiXFDt8Ya2WQuB9qAGrWNqr7Y1xNGTqIb rAXMsMqFK0J7t5xvcwX7ALTLQSH1kEii3xi+LygOrXmTtHDaug/umgdytdgtDyCCfM+7 9pkgYv7zb+rLoITHVQ5RFtxfeTrSd1bs26CkuP1wkiaJAJYPdlWUuiWWz8CLwRYB0rVV ojjw== X-Received: by 10.180.208.42 with SMTP id mb10mr15918011wic.80.1430512593623; Fri, 01 May 2015 13:36:33 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id k9sm8122862wia.6.2015.05.01.13.36.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 May 2015 13:36:33 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> <838udcwbdc.fsf@gnu.org> <553FFC99.5080701@yandex.ru> <834mnzuedd.fsf@gnu.org> <554161A8.30202@yandex.ru> <83618du3q3.fsf@gnu.org> <5542E486.2010107@yandex.ru> <83k2wsssm8.fsf@gnu.org> <5543632C.6000306@yandex.ru> <834mnwsbfb.fsf@gnu.org> <554392E2.7080109@yandex.ru> <83oam4qh2u.fsf@gnu.org> <5543C97C.6050000@yandex.ru> <83h9rwqf10.fsf@gnu.org> From: Dmitry Gutov message-id: <5543E3CF.5010402@yandex.ru> Date: Fri, 1 May 2015 23:36:31 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <83h9rwqf10.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/01/2015 10:22 PM, Eli Zaretskii wrote: > If it doesn't, it should ask the user. That's a speed bump. Not to say that a generic symbol-browsing facility handling different kinds of them won't be useful, but that's not what I see `M-.' doing. > The example is still valid. How do you know another back-end won't do > something similar? How do you know another back-end won't return 140 results for "function named car"? In the end, it's up to the backend's author to write an implementation conforming to what's being asked of it. > Note the "I" vs the "we". If _you_ want to see only one match most of > the time, you should be able to customize the feature to do just that. > Others could customize it differently, according to their use cases. > It will still be the same command, though. There's nothing to note. While *I* can only speak for myself, Stefan expressed a similar preference. IIRC, both Jorgen and Helmut did so as well. Of course, I'd be happy to make it more customizable, if it can still work well enough for me, at least in one configuration. But I'll need more concrete design proposals on that. > Other IDEs ask the user explicitly to specify how wide she wants the > search and how detailed the results. We could do that as well, > although I think it's less Emacsy. That hasn't been my experience. They do have different commands for different searches, but those vary between editors. Yet, there's always a "go to definition" command that tries its best not to ask the user anything else, and jumps to wherever the symbol at point was "defined". It's usually bound to Ctrl-Click. > But having just one level is never right in such cases. I wonder if it's even possible to define a set of levels in a backend-agnostic way. For instance, for etags you have "exact matches", "exact implicit matches", "word matches", "partial file name matches", etc. In the Elisp backend, I'd see the "same kind of entity", "other kinds of entities with that name", "fuzzy matches on the name". Keep in mind though, that if we introduce the notion of levels in the interface, it'll also complicate things for every implementor. Maybe the solution is to define the ability for a backend to return groups, probably nested ones. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 00:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143052532924159 (code B ref 19468); Sat, 02 May 2015 00:09:02 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 00:08:49 +0000 Received: from localhost ([127.0.0.1]:59034 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoKzB-0006HZ-80 for submit@debbugs.gnu.org; Fri, 01 May 2015 20:08:49 -0400 Received: from mail-wi0-f179.google.com ([209.85.212.179]:38171) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoKz9-0006HH-0o for 19468@debbugs.gnu.org; Fri, 01 May 2015 20:08:47 -0400 Received: by wiun10 with SMTP id n10so60922203wiu.1 for <19468@debbugs.gnu.org>; Fri, 01 May 2015 17:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=7R8//iCMq0MBwspmraJ4II6UnUKA19yp+wdn8Zi6HCk=; b=cY/UckUE+2XifszJcyGxF4hJ1UIyUOC4Qkp5f+6OGCktZLfId8WHHLl1i5YSJoUk79 F7swyguYPBAFEPJwr6oBk3CbeP5yjMQbIthLHjTZrP513xZ1BLHxXOQbC7OTBoFb57/A I7+nK2zBtP0ooQPOTFGCr9+PoRDPO9xxkfOsrFc4V46MyrlF2t2Mp7IdMSc6dBR3ZVjA Z9YewWzbwu7wLlXXp9NhVb6WF8JWKYA/b96EWUCc0NKl9M/57yqWf5qeGG1ckTt6QgCw 1b6/GYRFWTlunupR89LrCatKZKtputjTz6uUyrMsCKcITO//ykjSllsz3xtyZOwygOHX xvmQ== X-Received: by 10.194.3.77 with SMTP id a13mr22131894wja.104.1430525321450; Fri, 01 May 2015 17:08:41 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id gj7sm126194wib.4.2015.05.01.17.08.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 May 2015 17:08:41 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> From: Dmitry Gutov message-id: <55441587.6050004@yandex.ru> Date: Sat, 2 May 2015 03:08:39 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <83a8xqu80z.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/29/2015 09:03 PM, Eli Zaretskii wrote: >>> Using ID-Utils is one possible way, I guess. It will be used now, courtesy of semantic/symref, if the ID file is in the same directory as TAGS. Now someone should document that, without forgetting GNU Global and CScope, as well as the fact that their index files tend to get out of date. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 06:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14305490204882 (code B ref 19468); Sat, 02 May 2015 06:44:02 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 06:43:40 +0000 Received: from localhost ([127.0.0.1]:59072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoR9I-0001Gf-1t for submit@debbugs.gnu.org; Sat, 02 May 2015 02:43:40 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:43228) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoR8x-0001G1-KV for 19468@debbugs.gnu.org; Sat, 02 May 2015 02:43:38 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NNP00600M28TA00@mtaout26.012.net.il> for 19468@debbugs.gnu.org; Sat, 02 May 2015 09:44:51 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNP004UAMQRPS30@mtaout26.012.net.il>; Sat, 02 May 2015 09:44:51 +0300 (IDT) Date: Sat, 02 May 2015 09:42:56 +0300 From: Eli Zaretskii In-reply-to: <55441587.6050004@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <838ud7qy33.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Sat, 2 May 2015 03:08:39 +0300 > > On 04/29/2015 09:03 PM, Eli Zaretskii wrote: > > >>> Using ID-Utils is one possible way, I guess. > > It will be used now, courtesy of semantic/symref, if the ID file is in > the same directory as TAGS. Thanks. I think it's a good idea to add an ID target to the top-level Makefile.in. Or does Semantic run that automatically as needed? > Now someone should document that, without forgetting GNU Global and > CScope, as well as the fact that their index files tend to get out of date. Yep. At least mkid is lightning-fast (10 sec on the entire Emacs tree), so updating ID is not an annoyance IME. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 07:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14305506807582 (code B ref 19468); Sat, 02 May 2015 07:12:02 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 07:11:20 +0000 Received: from localhost ([127.0.0.1]:59082 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoRa3-0001yD-A1 for submit@debbugs.gnu.org; Sat, 02 May 2015 03:11:19 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:54142) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoRa1-0001xt-7F for 19468@debbugs.gnu.org; Sat, 02 May 2015 03:11:18 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NNP00300MOZ4P00@mtaout25.012.net.il> for 19468@debbugs.gnu.org; Sat, 02 May 2015 10:06:56 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNP00KA4NRJF890@mtaout25.012.net.il>; Sat, 02 May 2015 10:06:56 +0300 (IDT) Date: Sat, 02 May 2015 10:10:54 +0300 From: Eli Zaretskii In-reply-to: <55441587.6050004@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <837fsrqwsh.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Dmitry Gutov > Date: Sat, 2 May 2015 03:08:39 +0300 > > On 04/29/2015 09:03 PM, Eli Zaretskii wrote: > > >>> Using ID-Utils is one possible way, I guess. > > It will be used now, courtesy of semantic/symref, if the ID file is in > the same directory as TAGS. I cannot seem to make it to work. Here's what I did: ./src/emacs -Q C-x C-f src/xdisp.c RET move to a place that references set_cursor_from_row M-x xref-find-references RET I get "Symbol's function definition is void: mapcan". I then manually load cl, and re-invoke the command. The result now is "No known references for: set_cursor_from_row". But the shell command "gid set_cursor_from_row" returns this list of matches: src/xdisp.c:174: latter, see also set_cursor_from_row). src/xdisp.c:380: cursor; <= 0 if not known. Set by set_cursor_from_row, used for src/xdisp.c:777:static bool set_cursor_from_row (struct window *, struct glyph_row *, src/xdisp.c:1406: set_cursor_from_row conspires with cursor_row_p to src/xdisp.c:4421: text, which confuses `set_cursor_from_row'. src/xdisp.c:13675: set_cursor_from_row (w, row, w->current_matrix, 0, 0, 0, 0); src/xdisp.c:14191:set_cursor_from_row (struct window *w, struct glyph_row *row, src/xdisp.c:15568: set_cursor_from_row (w, row, w->current_matrix, 0, 0, 0, 0); src/xdisp.c:15582: occlude point. We need to let set_cursor_from_row src/xdisp.c:15596: rv |= set_cursor_from_row (w, row, w->current_matrix, src/xdisp.c:15652: if (set_cursor_from_row (w, row, w->current_matrix, 0, 0, 0, 0)) src/xdisp.c:16202: set_cursor_from_row (w, row, w->desired_matrix, 0, 0, 0, 0); src/xdisp.c:16634: set_cursor_from_row (w, row, w->current_matrix, 0, 0, 0, 0); src/xdisp.c:17081: set_cursor_from_row (w, row, w->current_matrix, 0, 0, src/xdisp.c:17317: bidi-reordered glyph rows. Let set_cursor_from_row src/xdisp.c:17322: if (!set_cursor_from_row (w, row, w->current_matrix, src/xdisp.c:17892: set_cursor_from_row (w, row, current_matrix, 0, 0, 0, 0); src/xdisp.c:17932: set_cursor_from_row (w, row, current_matrix, 0, 0, 0, 0); src/xdisp.c:18154: set_cursor_from_row (w, row, w->current_matrix, 0, 0, 0, 0); src/xdisp.c:18163: set_cursor_from_row (w, row, w->current_matrix, delta, src/xdisp.c:20794: set_cursor_from_row (it->w, row, it->w->desired_matrix, 0, 0, 0, 0); In case it matters, the ID file was produced manually with this command in the top-level Emacs directory: mkid -o ID . What am I missing? From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 07:40:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143055237910477 (code B ref 19468); Sat, 02 May 2015 07:40:04 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 07:39:39 +0000 Received: from localhost ([127.0.0.1]:59086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoS1S-0002iu-1E for submit@debbugs.gnu.org; Sat, 02 May 2015 03:39:38 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:53464) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoS1P-0002ig-L4 for 19468@debbugs.gnu.org; Sat, 02 May 2015 03:39:37 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NNP00I00OWOPX00@a-mtaout22.012.net.il> for 19468@debbugs.gnu.org; Sat, 02 May 2015 10:39:28 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNP00ID1P9SEK70@a-mtaout22.012.net.il>; Sat, 02 May 2015 10:39:28 +0300 (IDT) Date: Sat, 02 May 2015 10:39:11 +0300 From: Eli Zaretskii In-reply-to: <5543E3CF.5010402@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <831tizqvhc.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> <838udcwbdc.fsf@gnu.org> <553FFC99.5080701@yandex.ru> <834mnzuedd.fsf@gnu.org> <554161A8.30202@yandex.ru> <83618du3q3.fsf@gnu.org> <5542E486.2010107@yandex.ru> <83k2wsssm8.fsf@gnu.org> <5543632C.6000306@yandex.ru> <834mnwsbfb.fsf@gnu.org> <554392E2.7080109@yandex.ru> <83oam4qh2u.fsf@gnu.org> <5543C97C.6050000@yandex.ru> <83h9rwqf10.fsf@gnu.org> <5543E3CF.5010402@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Fri, 1 May 2015 23:36:31 +0300 > > On 05/01/2015 10:22 PM, Eli Zaretskii wrote: > > > If it doesn't, it should ask the user. > > That's a speed bump. Yes. But the alternative, of producing output that the user deosn't want, or no output at all, is worse, don't you think? > How do you know another back-end won't return 140 results for "function > named car"? In the end, it's up to the backend's author to write an > implementation conforming to what's being asked of it. Yes, but the specification to which it should conform should be more detailed, otherwise some back-end could very well claim conformance and still produce such large lists. The restrictions, such as "only exact matches" or "only functions" etc. should be a necessary part of the API -- then and only then would it be possible to reject a back-end that returns 140 hits for "exact matches only" query. > > Note the "I" vs the "we". If _you_ want to see only one match most of > > the time, you should be able to customize the feature to do just that. > > Others could customize it differently, according to their use cases. > > It will still be the same command, though. > > There's nothing to note. While *I* can only speak for myself, Stefan > expressed a similar preference. IIRC, both Jorgen and Helmut did so as well. So at best you have 80% of users that would want the same as you. What about the other 20%? Shouldn't we provide customizable options for them, even though they might be a minority? > Of course, I'd be happy to make it more customizable, if it can still > work well enough for me, at least in one configuration. But I'll need > more concrete design proposals on that. My proposal was to come up with types of matches (I mentioned them already several times), and then let the users customize the collection of types passed to the back-end by default. Whether this translates immediately to some design, I don't know, although it seemed to me it does. > I wonder if it's even possible to define a set of levels in a > backend-agnostic way. I think it is. > For instance, for etags you have "exact matches", > "exact implicit matches", "word matches", "partial file name matches", etc. Except for "implicit matches" that should actually be part of the same generalized class as "exact matches", the rest are quite general, I think. > In the Elisp backend, I'd see the "same kind of entity", "other kinds of > entities with that name", "fuzzy matches on the name". "Fuzzy" is "substring" in etags, "same/other kinds" should be translated to "functions/variables" etc. > Keep in mind though, that if we introduce the notion of levels in the > interface, it'll also complicate things for every implementor. The goal is to provide a better user experience, not to make life easier for the implementors. But if a certain back-end can do a good job by implementing only one level, into which all the levels will map, then it's an okay solution for that back-end's targets. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 10:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143056152925900 (code B ref 19468); Sat, 02 May 2015 10:13:01 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 10:12:09 +0000 Received: from localhost ([127.0.0.1]:59137 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoUP2-0006jf-Oz for submit@debbugs.gnu.org; Sat, 02 May 2015 06:12:09 -0400 Received: from mail-wg0-f50.google.com ([74.125.82.50]:35214) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoUP0-0006j7-Ht for 19468@debbugs.gnu.org; Sat, 02 May 2015 06:12:07 -0400 Received: by wgyo15 with SMTP id o15so109624143wgy.2 for <19468@debbugs.gnu.org>; Sat, 02 May 2015 03:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Na9tevDDXapgwayBJDjY4YW9ft2BGHGwQ9MLiR1aUWk=; b=pb3qTW6MZHjcCBl5/t+9X4TMejDkTgLaRSOUeRAaHhkf0wBheanVoQ0IlBMGrqytxk psJ8BqQvofHD43xlk+dnGKK082iXe4kh6Vhn4gSzXrzi1ix04VS4iBxrkWzcaQ/IYAXt V0Cy3HOn/PV7UxGaoKVMnwm0jM+lA/o0tNt1WDe5gfXHq1KwTwggsND3Uc8suvkEDn49 9bB1O81BDR7Us2tw50mmGxdD+7Jda+6+W/TnNXVuRun8HPtaORWUQJF86CMxdu/1IDrg r64xkORUSsWaX0jB3ac2FZEYnDiAbJiwNJUxuxhuknJ1KRC8h3SPr/PSMEanRdIkdmGL n+YQ== X-Received: by 10.194.104.71 with SMTP id gc7mr24229664wjb.114.1430561520856; Sat, 02 May 2015 03:12:00 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id hu1sm1765705wib.6.2015.05.02.03.12.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 May 2015 03:12:00 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <837fsrqwsh.fsf@gnu.org> From: Dmitry Gutov message-id: <5544A2EE.1010507@yandex.ru> Date: Sat, 2 May 2015 13:11:58 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <837fsrqwsh.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/02/2015 10:10 AM, Eli Zaretskii wrote: > I get "Symbol's function definition is void: mapcan". Sorry, fixed now. > I then manually load cl, and re-invoke the command. The result now is > "No known references for: set_cursor_from_row". It expected you to load the tags tables first, in order to know which directories to search in. Now it'll prompt for one otherwise. > In case it matters, the ID file was produced manually with this > command in the top-level Emacs directory: > > mkid -o ID . If you want to see it used, then like I said, it needs to be in the same directory as TAGS (not one level above). But without it, we default to using Grep. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 10:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143056222627039 (code B ref 19468); Sat, 02 May 2015 10:24:02 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 10:23:46 +0000 Received: from localhost ([127.0.0.1]:59141 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoUaH-000721-GU for submit@debbugs.gnu.org; Sat, 02 May 2015 06:23:45 -0400 Received: from mail-wi0-f179.google.com ([209.85.212.179]:37989) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoUaE-00071j-QJ for 19468@debbugs.gnu.org; Sat, 02 May 2015 06:23:43 -0400 Received: by wiun10 with SMTP id n10so67930399wiu.1 for <19468@debbugs.gnu.org>; Sat, 02 May 2015 03:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=K38v08p3Qv0BSMlLu7b4RiVFyMtEZHB6FvuYyKnJHJk=; b=DU+HtRHWZ1Sz0ZMzztzpvMNs5xoQ3Z8DI8o4u3skdh6Hb8CyRM+CJlOTgWl2BQ4gv9 j46gImJqOPToN++sd8lV/cmGUPmI3F1+ZSSH37Dnw5aIDh4ESGjVFXMyOjVtACCzHVPp YJX2SpKvcxQCiQ/nf/YSLTIMG8l+cFpSXVVpMULngClki4ZCxohqfVyG3R5ruNvX7UcE wRsnio04LYt1/TfG+v3bnWP+Zj+2agPc1ZRMxPnxe42X+F/nUVXgEmct4hiOm5NvJN2d pFOpKn8WOZqI4CAxhrhfdYtJE8siTEkqx/dyYI0YTVocdH8K+1CWDDW1u/zCaNbC71o0 c1bg== X-Received: by 10.180.84.8 with SMTP id u8mr3965969wiy.39.1430562217175; Sat, 02 May 2015 03:23:37 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id gs7sm1793112wib.10.2015.05.02.03.23.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 May 2015 03:23:37 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <838ud7qy33.fsf@gnu.org> From: Dmitry Gutov message-id: <5544A5A6.4010005@yandex.ru> Date: Sat, 2 May 2015 13:23:34 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <838ud7qy33.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/02/2015 09:42 AM, Eli Zaretskii wrote: > I think it's a good idea to add an ID target to the top-level > Makefile.in. If you like. But in the Emacs tree, using Grep seems to be fast enough already, and its results don't get out of date. Speaking of ID generation, by default it includes .elc files, so the command would need to be something like mkid --prune=$(find . -name "*.elc") > Or does Semantic run that automatically as needed? I don't think so. In any case, you don't need to enable semantic-mode, or EDE, to make the search for references work. > Yep. At least mkid is lightning-fast (10 sec on the entire Emacs > tree), so updating ID is not an annoyance IME. You still need to remember to do that. And automating it to update before each search wouldn't be a good idea (searches take less than a second). From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 11:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143056540832347 (code B ref 19468); Sat, 02 May 2015 11:17:02 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 11:16:48 +0000 Received: from localhost ([127.0.0.1]:59148 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoVPc-0008Pe-5S for submit@debbugs.gnu.org; Sat, 02 May 2015 07:16:48 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:43700) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoVPZ-0008PN-Sg for 19468@debbugs.gnu.org; Sat, 02 May 2015 07:16:47 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NNP00700Z4CN500@a-mtaout20.012.net.il> for 19468@debbugs.gnu.org; Sat, 02 May 2015 14:16:39 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNP007KFZBQMR10@a-mtaout20.012.net.il>; Sat, 02 May 2015 14:16:39 +0300 (IDT) Date: Sat, 02 May 2015 14:16:22 +0300 From: Eli Zaretskii In-reply-to: <5544A2EE.1010507@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83oam3p6ux.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <837fsrqwsh.fsf@gnu.org> <5544A2EE.1010507@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Sat, 2 May 2015 13:11:58 +0300 > > On 05/02/2015 10:10 AM, Eli Zaretskii wrote: > > > I get "Symbol's function definition is void: mapcan". > > Sorry, fixed now. Thanks. > > I then manually load cl, and re-invoke the command. The result now is > > "No known references for: set_cursor_from_row". > > It expected you to load the tags tables first It did, so that's not the problem. > Now it'll prompt for one otherwise. I don't understand this new prompt, it says: In directory: /patch/to/emacs/trunk/src/ What does it ask about? (I just pressed RET, since the directory sounds correct.) > > In case it matters, the ID file was produced manually with this > > command in the top-level Emacs directory: > > > > mkid -o ID . > > If you want to see it used, then like I said, it needs to be in the same > directory as TAGS (not one level above). I tried both, and got the same results. So this is not the reason; there's something else at work here. > But without it, we default to using Grep. So why didn't it do that? Why did I get "no known references"? [Time passes] Ah, I see the reason: Some code that uses ID Utils expects the file names in the ID database to be absolute. So if I create the ID database like this: mkid -o ID /path/to/emacs/src then the feature starts working. I think it should support relative names as well, by expanding them relative to the directory in which the ID database was found. And in any case, claiming it found no references instead of saying something about finding no files whose names were returned by ID Utils is a less than useful error message, IMO. Now to the Grep alternative: if I rename the ID database, I get an error message: Searching for program: No such file or directory, sh (This is on MS-Windows.) The patch for that is below. But that doesn't end the saga, because after fixing this, I get "No known references for: set_cursor_from_row" again, when there's no ID database. The reason is that the find/grep command uses the wrong quoting style; the patch below fixes that as well. And the saga is not yet over, but now I need help. The method semantic-symref-parse-tool-output-one-line returns nil, but I cannot seem to figure out why. The buffer which contains Grep hits look fine to me (except that it includes SGR escape sequences, due to "--color=always" switch to Grep -- why is that a good idea?), but where's the code of this method? I couldn't step into it with Edebug, for some reason. Help?.... Here's that patch I promised. I will push it if no one objects. diff --git a/lisp/cedet/semantic/symref/grep.el b/lisp/cedet/semantic/symref/grep.el index 981dab8..ecb3279 100644 --- a/lisp/cedet/semantic/symref/grep.el +++ b/lisp/cedet/semantic/symref/grep.el @@ -115,7 +115,7 @@ (defun semantic-symref-grep-use-template (rootdir filepattern grepflags greppatt ;;(message "New command: %s" cmd) cmd)) -(defcustom semantic-symref-grep-shell "sh" +(defcustom semantic-symref-grep-shell shell-file-name "The shell command to use for executing find/grep. This shell should support pipe redirect syntax." :group 'semantic @@ -140,7 +140,8 @@ (cl-defmethod semantic-symref-perform-search ((tool semantic-symref-tool-grep)) (greppat (cond ((eq (oref tool :searchtype) 'regexp) (oref tool searchfor)) (t - (concat "'\\<" (oref tool searchfor) "\\>'")))) + (shell-quote-argument + (concat "\\<" (oref tool searchfor) "\\>"))))) ;; Misc (b (get-buffer-create "*Semantic SymRef*")) (ans nil) @@ -158,10 +159,12 @@ (cl-defmethod semantic-symref-perform-search ((tool semantic-symref-tool-grep)) (let ((cmd (concat "find " default-directory " -type f " filepattern " -print0 " "| xargs -0 grep -H " grepflags "-e " greppat))) ;;(message "Old command: %s" cmd) - (call-process semantic-symref-grep-shell nil b nil "-c" cmd) + (call-process semantic-symref-grep-shell nil b nil + shell-command-switch cmd) ) (let ((cmd (semantic-symref-grep-use-template rootdir filepattern grepflags greppat))) - (call-process semantic-symref-grep-shell nil b nil "-c" cmd)) + (call-process semantic-symref-grep-shell nil b nil + shell-command-switch cmd)) )) (setq ans (semantic-symref-parse-tool-output tool b)) ;; Return the answer From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 11:25:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.1430565886644 (code B ref 19468); Sat, 02 May 2015 11:25:04 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 11:24:46 +0000 Received: from localhost ([127.0.0.1]:59152 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoVXJ-0000AJ-MP for submit@debbugs.gnu.org; Sat, 02 May 2015 07:24:46 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:56577) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoVXG-0000A4-79 for 19468@debbugs.gnu.org; Sat, 02 May 2015 07:24:43 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NNP00C00ZKC0V00@mtaout26.012.net.il> for 19468@debbugs.gnu.org; Sat, 02 May 2015 14:26:13 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNP003D0ZRPXJ70@mtaout26.012.net.il>; Sat, 02 May 2015 14:26:13 +0300 (IDT) Date: Sat, 02 May 2015 14:24:19 +0300 From: Eli Zaretskii In-reply-to: <5544A5A6.4010005@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83mw1np6ho.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <838ud7qy33.fsf@gnu.org> <5544A5A6.4010005@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Sat, 2 May 2015 13:23:34 +0300 > > On 05/02/2015 09:42 AM, Eli Zaretskii wrote: > > I think it's a good idea to add an ID target to the top-level > > Makefile.in. > > If you like. But in the Emacs tree, using Grep seems to be fast enough > already, and its results don't get out of date. Did you try in src/ or did you try in lisp/? gid is much faster in large directories, especially if they are accessed over NFS or some such. So it scales better. > Speaking of ID generation, by default it includes .elc files, so the > command would need to be something like > > mkid --prune=$(find . -name "*.elc") Yes. > > Yep. At least mkid is lightning-fast (10 sec on the entire Emacs > > tree), so updating ID is not an annoyance IME. > > You still need to remember to do that. If you forget, you will be reminded when you find no matches. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 11:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: dgutov@yandex.ru Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14305671278382 (code B ref 19468); Sat, 02 May 2015 11:46:02 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 11:45:27 +0000 Received: from localhost ([127.0.0.1]:59158 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoVrK-0002B7-Lp for submit@debbugs.gnu.org; Sat, 02 May 2015 07:45:27 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:41292) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoVrH-0002Aj-IU for 19468@debbugs.gnu.org; Sat, 02 May 2015 07:45:25 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NNQ00D000K37M00@a-mtaout23.012.net.il> for 19468@debbugs.gnu.org; Sat, 02 May 2015 14:45:17 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNQ00DZU0NG4P30@a-mtaout23.012.net.il>; Sat, 02 May 2015 14:45:17 +0300 (IDT) Date: Sat, 02 May 2015 14:45:00 +0300 From: Eli Zaretskii In-reply-to: <83oam3p6ux.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83lhh7p5j7.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <837fsrqwsh.fsf@gnu.org> <5544A2EE.1010507@yandex.ru> <83oam3p6ux.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 02 May 2015 14:16:22 +0300 > From: Eli Zaretskii > Cc: 19468@debbugs.gnu.org > > And the saga is not yet over, but now I need help. The method > semantic-symref-parse-tool-output-one-line returns nil, but I cannot > seem to figure out why. The buffer which contains Grep hits look fine > to me (except that it includes SGR escape sequences, due to > "--color=always" switch to Grep -- why is that a good idea?), but > where's the code of this method? I couldn't step into it with Edebug, > for some reason. Found it: that --color=always _is_ the problem, since the SGR escapes interfere with the search. How does this work on Posix platforms? Should we filter out that switch unconditionally? The patch below incorporates the additional fix for this problem, and now, finally, I have my references using Grep as well: diff --git a/lisp/cedet/semantic/symref/grep.el b/lisp/cedet/semantic/symref/grep.el index 981dab8..da1803f 100644 --- a/lisp/cedet/semantic/symref/grep.el +++ b/lisp/cedet/semantic/symref/grep.el @@ -105,7 +105,11 @@ (defun semantic-symref-grep-use-template (rootdir filepattern grepflags greppatt ;; We have grep-compute-defaults. Let's use it. (grep-compute-defaults) (let* ((grep-expand-keywords semantic-symref-grep-expand-keywords) - (cmd (grep-expand-template grep-find-template + (cmd (grep-expand-template (if (memq system-type '(windows-nt ms-dos)) + (replace-regexp-in-string + "--color=always" "--color=auto" + grep-find-template t t) + grep-find-template) greppattern filepattern rootdir))) @@ -115,7 +119,7 @@ (defun semantic-symref-grep-use-template (rootdir filepattern grepflags greppatt ;;(message "New command: %s" cmd) cmd)) -(defcustom semantic-symref-grep-shell "sh" +(defcustom semantic-symref-grep-shell shell-file-name "The shell command to use for executing find/grep. This shell should support pipe redirect syntax." :group 'semantic @@ -140,7 +144,8 @@ (cl-defmethod semantic-symref-perform-search ((tool semantic-symref-tool-grep)) (greppat (cond ((eq (oref tool :searchtype) 'regexp) (oref tool searchfor)) (t - (concat "'\\<" (oref tool searchfor) "\\>'")))) + (shell-quote-argument + (concat "\\<" (oref tool searchfor) "\\>"))))) ;; Misc (b (get-buffer-create "*Semantic SymRef*")) (ans nil) @@ -158,10 +163,12 @@ (cl-defmethod semantic-symref-perform-search ((tool semantic-symref-tool-grep)) (let ((cmd (concat "find " default-directory " -type f " filepattern " -print0 " "| xargs -0 grep -H " grepflags "-e " greppat))) ;;(message "Old command: %s" cmd) - (call-process semantic-symref-grep-shell nil b nil "-c" cmd) + (call-process semantic-symref-grep-shell nil b nil + shell-command-switch cmd) ) (let ((cmd (semantic-symref-grep-use-template rootdir filepattern grepflags greppat))) - (call-process semantic-symref-grep-shell nil b nil "-c" cmd)) + (call-process semantic-symref-grep-shell nil b nil + shell-command-switch cmd)) )) (setq ans (semantic-symref-parse-tool-output tool b)) ;; Return the answer From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 12:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143056813010143 (code B ref 19468); Sat, 02 May 2015 12:03:02 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 12:02:10 +0000 Received: from localhost ([127.0.0.1]:59162 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoW7V-0002dW-UY for submit@debbugs.gnu.org; Sat, 02 May 2015 08:02:10 -0400 Received: from mail-wg0-f44.google.com ([74.125.82.44]:36820) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoW7T-0002d9-FE for 19468@debbugs.gnu.org; Sat, 02 May 2015 08:02:08 -0400 Received: by wgen6 with SMTP id n6so111015509wge.3 for <19468@debbugs.gnu.org>; Sat, 02 May 2015 05:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Vh0VLLGoK6VZD+A0xFsAp7HppFSQl61uT3E0xYyBtOU=; b=VrJXR/2RxLeASscMA56L5YZNyxKe/gxAfNs0t53+t/x6Io0g3Cn/Lmombdy8ehIxxN 7mkj/kNRvy/ixE6b59t6J8kz75ZYrzJbupuuoTTVCG9I3dMDxcnJCUpsnULM9ratx1Oq HqqJISp69vo1fsYyeeq9n8eUhzqy+xm3H3tTKKtkdJQLJHWaifzF/tVQF2I3N8bMrbJ7 GR++eywQK+7FDQyZ3YEzxzmqIwfJzCz/k2No+UuEqX6wpWpwq+paZaH8BwSO0j1C0Keg 7adsQZGv1GQ8C+intDH5xuX0Q5kSwJVmEC9/0QnAFAAKXZlLD177V3RN9RNWvDnNX/NZ +qDQ== X-Received: by 10.194.97.196 with SMTP id ec4mr23015685wjb.3.1430568121824; Sat, 02 May 2015 05:02:01 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id k2sm2128160wif.3.2015.05.02.05.02.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 May 2015 05:02:01 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <837fsrqwsh.fsf@gnu.org> <5544A2EE.1010507@yandex.ru> <83oam3p6ux.fsf@gnu.org> From: Dmitry Gutov message-id: <5544BCB7.8010702@yandex.ru> Date: Sat, 2 May 2015 15:01:59 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <83oam3p6ux.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/02/2015 02:16 PM, Eli Zaretskii wrote: > It did, so that's not the problem. Hmm, it worked for me after that. > I don't understand this new prompt, it says: > > In directory: /patch/to/emacs/trunk/src/ > > What does it ask about? (I just pressed RET, since the directory > sounds correct.) "[Search for references] in directory". Should the first three words be spelled out as well? > I tried both, and got the same results. So this is not the reason; > there's something else at work here. I simply run mkid, without arguments, in ~/vc/emacs/src. > [Time passes] Ah, I see the reason: Some code that uses ID Utils > expects the file names in the ID database to be absolute. So if I > create the ID database like this: > > mkid -o ID /path/to/emacs/src > > then the feature starts working. It works fine for me either way (whether called on /path/..., or .), using mkid 4.6, on GNU/Linux. Could it be a misfeature of the Windows port? > I think it should support relative names as well, by expanding them > relative to the directory in which the ID database was found. And in > any case, claiming it found no references instead of saying something > about finding no files whose names were returned by ID Utils is a less > than useful error message, IMO. ID Utils is used through several levels of indirection. xref can't be aware of it. I guess we could output some additional message in xref-collect-references though (patch welcome). From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 12:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143056844010655 (code B ref 19468); Sat, 02 May 2015 12:08:02 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 12:07:20 +0000 Received: from localhost ([127.0.0.1]:59166 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoWCV-0002lm-G8 for submit@debbugs.gnu.org; Sat, 02 May 2015 08:07:20 -0400 Received: from mail-wi0-f181.google.com ([209.85.212.181]:33389) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoWCT-0002lU-1b for 19468@debbugs.gnu.org; Sat, 02 May 2015 08:07:17 -0400 Received: by wief7 with SMTP id f7so46628461wie.0 for <19468@debbugs.gnu.org>; Sat, 02 May 2015 05:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=5wucKeFNRB5pGNpRIv7SSChswi4CU1HxvJSLV+gq1KE=; b=fEvV643gnK+injW5XK+xBF3kOVNV6E9fsMyQkVNRGU/OoM7lF9z+hWF4fhTI1mRjkf CKYEAntqvyKIT+rYsuxC7nbQagNDycAINuoTGXo1/nY+KRM3f3up5Qw7xbTUc52OHtQY GoJNS54xXm5LY5fx803oAEiHUcH0RLhYuv58JwCVzmrIGVFSdcebp2WtOjIku6wfHqLG 4aSfEqFByq/xH8S3WaQ1Z0MOuLJMkqg6JldMV9fHKX1fmm2JZhoVaq01/1dLLEGgftUT Zat3O0bOsna+XQRMkwOa1iy73iCLn/X1ffwZPmwO06MiJ0giXsvLaBgSRVR0UXaxydA7 vp1w== X-Received: by 10.194.77.7 with SMTP id o7mr25272189wjw.95.1430568431381; Sat, 02 May 2015 05:07:11 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id xb3sm11516273wjc.38.2015.05.02.05.07.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 May 2015 05:07:11 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <838ud7qy33.fsf@gnu.org> <5544A5A6.4010005@yandex.ru> <83mw1np6ho.fsf@gnu.org> From: Dmitry Gutov message-id: <5544BDED.3030100@yandex.ru> Date: Sat, 2 May 2015 15:07:09 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <83mw1np6ho.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/02/2015 02:24 PM, Eli Zaretskii wrote: > Did you try in src/ or did you try in lisp/? Both. Grep is pretty fast on my machine (1.5 year old laptop, with Intel Core i7 and an SSD drive). > gid is much faster in large directories, especially if they are > accessed over NFS or some such. So it scales better. I'm sure it is, for large codebases. Just not sure if it has any tangible advantages for Emacs (and it has a disadvantage: has to be updated manually). > If you forget, you will be reminded when you find no matches. I might find 1-2 fewer matches than I should, instead of no matches. And I'm actually aware of how it works. That won't be true for a random user. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 12:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143056899511523 (code B ref 19468); Sat, 02 May 2015 12:17:01 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 12:16:35 +0000 Received: from localhost ([127.0.0.1]:59170 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoWLT-0002zn-Ao for submit@debbugs.gnu.org; Sat, 02 May 2015 08:16:35 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:37803) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoWLQ-0002zZ-EX for 19468@debbugs.gnu.org; Sat, 02 May 2015 08:16:33 -0400 Received: by widdi4 with SMTP id di4so69534600wid.0 for <19468@debbugs.gnu.org>; Sat, 02 May 2015 05:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=/Z17Lh9feHx9L52XSu6g2JZ8nIpHr5jceo7I5kr8+ro=; b=K53NMFtNkuv+dEM8L9qicp9Rs9pvkJB+gPjXFC5qKoTXgG4S8PM4PsFJwTNWk6GhCh cxqhBSNC+FzDmt675EEhadKjUoUG480N6wY1hGZpsf1Fkm6kTr9PZmn34Ihm+zgEwhZ0 08dsYDwATNj41khPNEGpVqjcHmYMn0fJgBvsmHjhdzNI51ySJE7iOuvNxa4hkMp2SuAA 7WrrMbJCA+MoKHlbC2rJjng/sg0LiBpPRt8OoLXa+enyEkbJdUnet9BLjKQTTlqMh/X8 FSGzZK2yHwG8/ciFkHCj8OK5hMs01qhdOFYeuzZ92AQim3QLHroHY9u+hmwEI8bwPVg0 Gamw== X-Received: by 10.180.109.136 with SMTP id hs8mr4479331wib.73.1430568986930; Sat, 02 May 2015 05:16:26 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id k2sm2174664wix.4.2015.05.02.05.16.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 May 2015 05:16:26 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <837fsrqwsh.fsf@gnu.org> <5544A2EE.1010507@yandex.ru> <83oam3p6ux.fsf@gnu.org> <83lhh7p5j7.fsf@gnu.org> From: Dmitry Gutov message-id: <5544C018.5090306@yandex.ru> Date: Sat, 2 May 2015 15:16:24 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <83lhh7p5j7.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/02/2015 02:45 PM, Eli Zaretskii wrote: > Found it: that --color=always _is_ the problem, since the SGR escapes > interfere with the search. How does this work on Posix platforms? > Should we filter out that switch unconditionally? It works okay either way here. But if "--color=always" in grep-find-template is a problem on Windows, why is it there in the first place? Does grep-find work okay over there? > The patch below incorporates the additional fix for this problem, and > now, finally, I have my references using Grep as well: Nice. I guess that's one way to encourage contributions to CEDET. :) From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 12:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143057074614263 (code B ref 19468); Sat, 02 May 2015 12:46:02 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 12:45:46 +0000 Received: from localhost ([127.0.0.1]:59174 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoWnh-0003hy-1e for submit@debbugs.gnu.org; Sat, 02 May 2015 08:45:45 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:55528) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoWnc-0003hf-AA for 19468@debbugs.gnu.org; Sat, 02 May 2015 08:45:42 -0400 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NNQ00E002SF5X00@mtaout28.012.net.il> for 19468@debbugs.gnu.org; Sat, 02 May 2015 15:44:28 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNQ00DJG3E3KZ20@mtaout28.012.net.il>; Sat, 02 May 2015 15:44:27 +0300 (IDT) Date: Sat, 02 May 2015 15:45:17 +0300 From: Eli Zaretskii In-reply-to: <5544BCB7.8010702@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83k2wrp2qq.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <837fsrqwsh.fsf@gnu.org> <5544A2EE.1010507@yandex.ru> <83oam3p6ux.fsf@gnu.org> <5544BCB7.8010702@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Sat, 2 May 2015 15:01:59 +0300 > > > I don't understand this new prompt, it says: > > > > In directory: /patch/to/emacs/trunk/src/ > > > > What does it ask about? (I just pressed RET, since the directory > > sounds correct.) > > "[Search for references] in directory". Do you mean it will only return matches in files in that directory, even if ID says the file is elsewhere? > Should the first three words be spelled out as well? I cannot answer that without understanding the meaning of the prompt. > > [Time passes] Ah, I see the reason: Some code that uses ID Utils > > expects the file names in the ID database to be absolute. So if I > > create the ID database like this: > > > > mkid -o ID /path/to/emacs/src > > > > then the feature starts working. > > It works fine for me either way (whether called on /path/..., or .), > using mkid 4.6, on GNU/Linux. If you type "lid", do you see absolute file names in both cases, or do you see relative ones when ID was created by "mkid ." (note the dot)? > Could it be a misfeature of the Windows port? If you tell me that "lid" returns relative file names, and xref-find-references still work, I will see if this is something specific to Windows. > > I think it should support relative names as well, by expanding them > > relative to the directory in which the ID database was found. And in > > any case, claiming it found no references instead of saying something > > about finding no files whose names were returned by ID Utils is a less > > than useful error message, IMO. > > ID Utils is used through several levels of indirection. xref can't be > aware of it. I didn't say xref should fix this. Is there no information xref gets from symref apart of the (empty) list of references? From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 12:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143057081714377 (code B ref 19468); Sat, 02 May 2015 12:47:01 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 12:46:57 +0000 Received: from localhost ([127.0.0.1]:59178 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoWor-0003jp-B9 for submit@debbugs.gnu.org; Sat, 02 May 2015 08:46:57 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:57130) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoWop-0003jb-55 for 19468@debbugs.gnu.org; Sat, 02 May 2015 08:46:55 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NNQ008002QB0700@mtaout27.012.net.il> for 19468@debbugs.gnu.org; Sat, 02 May 2015 15:41:55 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNQ0071939VJ020@mtaout27.012.net.il>; Sat, 02 May 2015 15:41:55 +0300 (IDT) Date: Sat, 02 May 2015 15:46:31 +0300 From: Eli Zaretskii In-reply-to: <5544BDED.3030100@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83iocbp2oo.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <838ud7qy33.fsf@gnu.org> <5544A5A6.4010005@yandex.ru> <83mw1np6ho.fsf@gnu.org> <5544BDED.3030100@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Sat, 2 May 2015 15:07:09 +0300 > > On 05/02/2015 02:24 PM, Eli Zaretskii wrote: > > > Did you try in src/ or did you try in lisp/? > > Both. Grep is pretty fast on my machine (1.5 year old laptop, with Intel > Core i7 and an SSD drive). Well, with SSD drive, what do you want?. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 12:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143057102414706 (code B ref 19468); Sat, 02 May 2015 12:51:02 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 12:50:24 +0000 Received: from localhost ([127.0.0.1]:59182 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoWsB-0003p7-4w for submit@debbugs.gnu.org; Sat, 02 May 2015 08:50:23 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:58102) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoWs8-0003ou-GL for 19468@debbugs.gnu.org; Sat, 02 May 2015 08:50:21 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NNQ0080037A7Z00@a-mtaout20.012.net.il> for 19468@debbugs.gnu.org; Sat, 02 May 2015 15:50:14 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNQ0075Z3NPVPA0@a-mtaout20.012.net.il>; Sat, 02 May 2015 15:50:13 +0300 (IDT) Date: Sat, 02 May 2015 15:49:57 +0300 From: Eli Zaretskii In-reply-to: <5544C018.5090306@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83h9rvp2iy.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <837fsrqwsh.fsf@gnu.org> <5544A2EE.1010507@yandex.ru> <83oam3p6ux.fsf@gnu.org> <83lhh7p5j7.fsf@gnu.org> <5544C018.5090306@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Sat, 2 May 2015 15:16:24 +0300 > > On 05/02/2015 02:45 PM, Eli Zaretskii wrote: > > > Found it: that --color=always _is_ the problem, since the SGR escapes > > interfere with the search. How does this work on Posix platforms? > > Should we filter out that switch unconditionally? > > It works okay either way here. So how do you feel about filtering it out it on all platforms, not just on Windows? > But if "--color=always" in grep-find-template is a problem on > Windows, why is it there in the first place? I guess because grep-find converts it into colored display using ansi-color or some such. > Does grep-find work okay over there? Yes, of course. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 13:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143057189516042 (code B ref 19468); Sat, 02 May 2015 13:05:02 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 13:04:55 +0000 Received: from localhost ([127.0.0.1]:59186 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoX6E-0004Ag-Tt for submit@debbugs.gnu.org; Sat, 02 May 2015 09:04:55 -0400 Received: from mail-wg0-f42.google.com ([74.125.82.42]:34174) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoX6B-0004AP-Vz for 19468@debbugs.gnu.org; Sat, 02 May 2015 09:04:52 -0400 Received: by wgso17 with SMTP id o17so111935153wgs.1 for <19468@debbugs.gnu.org>; Sat, 02 May 2015 06:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=BNperxsP4mlGw0xxIIZHzgRb6thmj2OMXdhVj8x5mDQ=; b=VKsrp+So2Va33+wRbVnCP9ej48Ecb9nxpY8D423XMnntWES/ZYe1o01JG2nrj25w9/ qpLpGHYUqdtq2mwEwv3N/uqqe9oAkLGMgD55JiJrBaMqFEEUA2kyrfBUNxwAS6s4qw2b rKEJ1IoWrQZNY+0F37KEYWaleSXnB4kpVYZbJ4zdHSDxXSMfXwYYV2TlWThqa5Mq+two 2ZLnlq+xwBsqUNfpEqlCCymVAi0ooxFlhag6IozHiACv5KecsTFcVxnqorZOEx09IEUa p5iH088dPy+3VV/tfE7/AMjcb+vmALGwTkFndFT74JWCiT0bL45XCqsRxGZd/VDptL2W S9UQ== X-Received: by 10.194.2.47 with SMTP id 15mr26315511wjr.101.1430571886400; Sat, 02 May 2015 06:04:46 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id u6sm11738782wjy.13.2015.05.02.06.04.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 May 2015 06:04:46 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <837fsrqwsh.fsf@gnu.org> <5544A2EE.1010507@yandex.ru> <83oam3p6ux.fsf@gnu.org> <83lhh7p5j7.fsf@gnu.org> <5544C018.5090306@yandex.ru> <83h9rvp2iy.fsf@gnu.org> From: Dmitry Gutov message-id: <5544CB6B.1090308@yandex.ru> Date: Sat, 2 May 2015 16:04:43 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <83h9rvp2iy.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/02/2015 03:49 PM, Eli Zaretskii wrote: > So how do you feel about filtering it out it on all platforms, not > just on Windows? I don't see a downside, so far. If any bug reports arise from it, I know who to forward them to. :) From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 13:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143057413819443 (code B ref 19468); Sat, 02 May 2015 13:43:02 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 13:42:18 +0000 Received: from localhost ([127.0.0.1]:59207 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoXgP-00053W-L9 for submit@debbugs.gnu.org; Sat, 02 May 2015 09:42:18 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:44061) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoXgL-00053E-PL for 19468@debbugs.gnu.org; Sat, 02 May 2015 09:42:14 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NNQ00L00601GZ00@a-mtaout22.012.net.il> for 19468@debbugs.gnu.org; Sat, 02 May 2015 16:42:07 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNQ00KMH626TDA0@a-mtaout22.012.net.il>; Sat, 02 May 2015 16:42:06 +0300 (IDT) Date: Sat, 02 May 2015 16:41:50 +0300 From: Eli Zaretskii In-reply-to: <5544BCB7.8010702@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83egmzp04h.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <837fsrqwsh.fsf@gnu.org> <5544A2EE.1010507@yandex.ru> <83oam3p6ux.fsf@gnu.org> <5544BCB7.8010702@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Sat, 2 May 2015 15:01:59 +0300 > > > I tried both, and got the same results. So this is not the reason; > > there's something else at work here. > > I simply run mkid, without arguments, in ~/vc/emacs/src. > > > [Time passes] Ah, I see the reason: Some code that uses ID Utils > > expects the file names in the ID database to be absolute. So if I > > create the ID database like this: > > > > mkid -o ID /path/to/emacs/src > > > > then the feature starts working. > > It works fine for me either way (whether called on /path/..., or .), > using mkid 4.6, on GNU/Linux. > > Could it be a misfeature of the Windows port? Found the reason, the patch is below. There's some tricky logic in ID Utils wrt when to report relative file names and when not, and I guess CEDET doesn't expect absolute file names, especially not on Windows. With the patch below, it works for me both ways. diff --git a/lisp/cedet/semantic/symref/idutils.el b/lisp/cedet/semantic/symref/idutils.el index c22a6a3..655b000 100644 --- a/lisp/cedet/semantic/symref/idutils.el +++ b/lisp/cedet/semantic/symref/idutils.el @@ -60,7 +60,7 @@ (cl-defmethod semantic-symref-parse-tool-output-one-line ((tool semantic-symref- (when (re-search-forward "^\\([^ ]+\\) " nil t) (match-string 1))) (t - (when (re-search-forward "^\\([^ :]+\\):+\\([0-9]+\\):" nil t) + (when (re-search-forward "^\\(\\(?:[a-zA-Z]:\\)?[^:\n]+\\):\\([0-9]+\\):" nil t) (cons (string-to-number (match-string 2)) (expand-file-name (match-string 1) default-directory)) )))) From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 13:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143057415819477 (code B ref 19468); Sat, 02 May 2015 13:43:02 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 13:42:38 +0000 Received: from localhost ([127.0.0.1]:59210 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoXgk-000545-CW for submit@debbugs.gnu.org; Sat, 02 May 2015 09:42:38 -0400 Received: from mail-wi0-f169.google.com ([209.85.212.169]:38632) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoXgi-00053q-IS for 19468@debbugs.gnu.org; Sat, 02 May 2015 09:42:37 -0400 Received: by wiun10 with SMTP id n10so70732486wiu.1 for <19468@debbugs.gnu.org>; Sat, 02 May 2015 06:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=QFmW5sRwfcykwd16eCgKU7PBqnXmWv2dzS/dHUAaQGA=; b=y8ZkA6rPiQyObWnfdPSGFufH1aQl3mjT3NrjrmMhV9J2ORMM0uLIadzP3ocIZYo4v8 9EmtGpqrPyqrmcDhbe9OhI1M3AavuZwlAmkLGXRKdu1qN7F4vtnUe1Iyg/R5NjyW1N1S QtTiWItyi3uPlVzAUxKWgAUZRfur1X0L7OAuu2WfXWhPqXIB9VW1k82mZuhzeAWDQ8n9 kQqoRA9MdWYjY3Csztds6MmfbfcSYL8+rJoovJEoWW4RWgwcPOedp4OJd1OtE2HlxB3c yo/VFq5oktDhycJHvut7G82utMBWt2oPWOGiq1kTjv6Wi9DI1jQwH1QKun/iM8Z8Bp2J SWWQ== X-Received: by 10.180.7.169 with SMTP id k9mr5078252wia.70.1430574150856; Sat, 02 May 2015 06:42:30 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id js3sm11865034wjc.5.2015.05.02.06.42.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 May 2015 06:42:30 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <837fsrqwsh.fsf@gnu.org> <5544A2EE.1010507@yandex.ru> <83oam3p6ux.fsf@gnu.org> <5544BCB7.8010702@yandex.ru> <83k2wrp2qq.fsf@gnu.org> From: Dmitry Gutov message-id: <5544D444.4060106@yandex.ru> Date: Sat, 2 May 2015 16:42:28 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <83k2wrp2qq.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/02/2015 03:45 PM, Eli Zaretskii wrote: > Do you mean it will only return matches in files in that directory, > even if ID says the file is elsewhere? I don't know. Can ID file reference files outside of its subtree? One would also need to study GNU Global and CScope in that context. > I cannot answer that without understanding the meaning of the prompt. But you asked a good question. > If you type "lid", do you see absolute file names in both cases, or do > you see relative ones when ID was created by "mkid ." (note the dot)? Relative ones, in both cases. You might want to look at `cedet-idutils-expand-filename'. > I didn't say xref should fix this. Is there no information xref gets > from symref apart of the (empty) list of references? Not currently, no. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 14:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143057604222829 (code B ref 19468); Sat, 02 May 2015 14:15:02 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 14:14:02 +0000 Received: from localhost ([127.0.0.1]:59878 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoYB8-0005w9-Da for submit@debbugs.gnu.org; Sat, 02 May 2015 10:14:02 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:51876) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoYB5-0005vU-GG for 19468@debbugs.gnu.org; Sat, 02 May 2015 10:14:00 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NNQ008006K65900@mtaout24.012.net.il> for 19468@debbugs.gnu.org; Sat, 02 May 2015 17:05:06 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNQ000WC74IME70@mtaout24.012.net.il>; Sat, 02 May 2015 17:05:06 +0300 (IDT) Date: Sat, 02 May 2015 17:13:37 +0300 From: Eli Zaretskii In-reply-to: <5544D444.4060106@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83a8xnoyni.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <837fsrqwsh.fsf@gnu.org> <5544A2EE.1010507@yandex.ru> <83oam3p6ux.fsf@gnu.org> <5544BCB7.8010702@yandex.ru> <83k2wrp2qq.fsf@gnu.org> <5544D444.4060106@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Sat, 2 May 2015 16:42:28 +0300 > > On 05/02/2015 03:45 PM, Eli Zaretskii wrote: > > > Do you mean it will only return matches in files in that directory, > > even if ID says the file is elsewhere? > > I don't know. Can ID file reference files outside of its subtree? It can. But if the subdirectories of the directory it asks about will also be included, that's good enough. Perhaps the prompt should say Search in and below directory: ... > > If you type "lid", do you see absolute file names in both cases, or do > > you see relative ones when ID was created by "mkid ." (note the dot)? > > Relative ones, in both cases. You might want to look at > `cedet-idutils-expand-filename'. I don't think it's relevant, see my other message. > > I didn't say xref should fix this. Is there no information xref gets > > from symref apart of the (empty) list of references? > > Not currently, no. Maybe the interface could be expanded to provide more in case of an error. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 17:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14305881678784 (code B ref 19468); Sat, 02 May 2015 17:37:02 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 17:36:07 +0000 Received: from localhost ([127.0.0.1]:59965 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YobKh-0002Hc-1e for submit@debbugs.gnu.org; Sat, 02 May 2015 13:36:07 -0400 Received: from mail-wg0-f44.google.com ([74.125.82.44]:36282) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YobKf-0002H7-37 for 19468@debbugs.gnu.org; Sat, 02 May 2015 13:36:05 -0400 Received: by wgen6 with SMTP id n6so115403502wge.3 for <19468@debbugs.gnu.org>; Sat, 02 May 2015 10:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=fRGWvkM+Kum8UfSvydEGboGUkIXkwvwv1EwGlOyoW1M=; b=UpBTt+yRi8IXBSm2kc93wdojl2CCW0xAfrFVKWa3p3/WzTEqJDezLzXN59jKRCzPSz G49LK4LNF1A+4zntrHVm1/WeLC2qqWza4SfVWqpDnOxgpC/NrU+Ml/8VjAiKJb6k/XqF Tj40k+p3oQLaBGVEzS6hgmbksZE/m5TKz011B1jdH9W0KuGHlmHTt5f/gIi0xnkI0YoT okxrCRsBwv3iDRwLSvwvT/gm8l4Lo8ReCPQy2rYsI6zWOc4VYMj0hLzzlV0jGXQa+nCz ZaNO636QmPn1+J81WzbXr+XqZHGaKdTfEiBAufSNpLPZq0ebrwyCi4Rc2USiUQjwIy62 nMrw== X-Received: by 10.194.208.229 with SMTP id mh5mr27690334wjc.108.1430588159444; Sat, 02 May 2015 10:35:59 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id mc20sm3197679wic.15.2015.05.02.10.35.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 May 2015 10:35:59 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <837fsrqwsh.fsf@gnu.org> <5544A2EE.1010507@yandex.ru> <83oam3p6ux.fsf@gnu.org> <5544BCB7.8010702@yandex.ru> <83egmzp04h.fsf@gnu.org> From: Dmitry Gutov message-id: <55450AFC.8040403@yandex.ru> Date: Sat, 2 May 2015 20:35:56 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <83egmzp04h.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/02/2015 04:41 PM, Eli Zaretskii wrote: > There's some tricky logic in ID Utils wrt when to report relative file > names and when not, and I guess CEDET doesn't expect absolute file > names, especially not on Windows. With the patch below, it works for > me both ways. It doesn't break anything here, please go ahead. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 17:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14305885309316 (code B ref 19468); Sat, 02 May 2015 17:43:01 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 17:42:10 +0000 Received: from localhost ([127.0.0.1]:59969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YobQY-0002QB-9k for submit@debbugs.gnu.org; Sat, 02 May 2015 13:42:10 -0400 Received: from mail-wg0-f46.google.com ([74.125.82.46]:33587) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YobQV-0002Py-Ph for 19468@debbugs.gnu.org; Sat, 02 May 2015 13:42:08 -0400 Received: by wgin8 with SMTP id n8so115331487wgi.0 for <19468@debbugs.gnu.org>; Sat, 02 May 2015 10:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=4AjRhmJq5d6b3tt+TheVE7FAOc+fIQmuX1QaAvP8Ym0=; b=vQ9g9CIiK7SonVxAM4WDQ4W1b4Y9Wf6xGbpLFu07tt3YycTwpx75Qxfw3I7CT74PG5 jqA7oKM3sQZr9sj0Q4/ZRRo2eWuxQZCJBsaXuiLUQKgStv/6PSzy9B/X3UfDKFU/FEVL a/VuMUKmNX/FqYW//pA5+x+K0Ef8UG2EGbT/6FqfS2G8XWoAuOPFV7LydJwktkj/nHdD OohxvrQRKCo6jpABExtOkxPg2nX3gxI5Y6zdKjZTfM7ro9xJYvPeio4NyqTdlbU6ruln oeqXAyKp4cfE7vf/C7drYDE8UQ9mQkNC9X7aZxaV9RKmFT2n7LYaAZB7bz0jXG0ahXOf jC2A== X-Received: by 10.180.9.5 with SMTP id v5mr6163896wia.93.1430588522152; Sat, 02 May 2015 10:42:02 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id ex5sm3244725wib.2.2015.05.02.10.42.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 May 2015 10:42:02 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <837fsrqwsh.fsf@gnu.org> <5544A2EE.1010507@yandex.ru> <83oam3p6ux.fsf@gnu.org> <5544BCB7.8010702@yandex.ru> <83k2wrp2qq.fsf@gnu.org> <5544D444.4060106@yandex.ru> <83a8xnoyni.fsf@gnu.org> From: Dmitry Gutov message-id: <55450C67.9040303@yandex.ru> Date: Sat, 2 May 2015 20:41:59 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <83a8xnoyni.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/02/2015 05:13 PM, Eli Zaretskii wrote: > It can. But if the subdirectories of the directory it asks about will > also be included, that's good enough. Perhaps the prompt should say "If". Continuing that line of thought, wouldn't it be possible that the ID file contains only files from outside of its subtree in its index? Then the prompt will be entirely wrong. > Search in and below directory: ... When I say (or read) "search in directory", I understand it to mean the subdirectories, too. > Maybe the interface could be expanded to provide more in case of an > error. But why would that be an error? "Nothing found" is an entirely legitimate result. Since we've encountered a bug in the code, maybe some extra assertions in `semantic-symref-parse-tool-output-one-line' (or in its caller?) would take care of that. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 18:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143059235615209 (code B ref 19468); Sat, 02 May 2015 18:46:02 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 18:45:56 +0000 Received: from localhost ([127.0.0.1]:59975 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YocQF-0003xE-BX for submit@debbugs.gnu.org; Sat, 02 May 2015 14:45:55 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:61373) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YocQB-0003wz-RR for 19468@debbugs.gnu.org; Sat, 02 May 2015 14:45:53 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NNQ00J00JWC5000@a-mtaout21.012.net.il> for 19468@debbugs.gnu.org; Sat, 02 May 2015 21:45:44 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNQ00JDMK484J20@a-mtaout21.012.net.il>; Sat, 02 May 2015 21:45:44 +0300 (IDT) Date: Sat, 02 May 2015 21:45:29 +0300 From: Eli Zaretskii In-reply-to: <55450C67.9040303@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <837fsqq0mu.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <837fsrqwsh.fsf@gnu.org> <5544A2EE.1010507@yandex.ru> <83oam3p6ux.fsf@gnu.org> <5544BCB7.8010702@yandex.ru> <83k2wrp2qq.fsf@gnu.org> <5544D444.4060106@yandex.ru> <83a8xnoyni.fsf@gnu.org> <55450C67.9040303@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Sat, 2 May 2015 20:41:59 +0300 > > On 05/02/2015 05:13 PM, Eli Zaretskii wrote: > > > It can. But if the subdirectories of the directory it asks about will > > also be included, that's good enough. Perhaps the prompt should say > > "If". Continuing that line of thought, wouldn't it be possible that the > ID file contains only files from outside of its subtree in its index? > Then the prompt will be entirely wrong. We could always ask about the ID file itself, you know... > > Search in and below directory: ... > > When I say (or read) "search in directory", I understand it to mean the > subdirectories, too. Well, it wasn't entirely clear, perhaps because I know too much about ID Utils. > > Maybe the interface could be expanded to provide more in case of an > > error. > > But why would that be an error? "Nothing found" is an entirely > legitimate result. That's not what happened here: the invocation of 'lid' yields a non-empty buffer, but then the result is an empty list. That's a clear sign of some problem somewhere. > Since we've encountered a bug in the code, maybe some extra assertions > in `semantic-symref-parse-tool-output-one-line' (or in its caller?) > would take care of that. Could be. In general, if the buffer is non-empty, there should be results. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 19:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143059425417959 (code B ref 19468); Sat, 02 May 2015 19:18:02 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 19:17:34 +0000 Received: from localhost ([127.0.0.1]:59979 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yocur-0004fb-OG for submit@debbugs.gnu.org; Sat, 02 May 2015 15:17:34 -0400 Received: from mail-wg0-f42.google.com ([74.125.82.42]:34923) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yocuo-0004fM-Df for 19468@debbugs.gnu.org; Sat, 02 May 2015 15:17:31 -0400 Received: by wgyo15 with SMTP id o15so116629230wgy.2 for <19468@debbugs.gnu.org>; Sat, 02 May 2015 12:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=TbPxE7SiCDaePLBSlOamuJX9F0plfUJlAXLghNf22Lk=; b=lxpWVOD4gvJiE9qh57fZ4V1bVy6AUTKhmg3hfsOme3b44McGuVaIgvUAqOiMUh37Vw ywKtoKLArk1juXZGo6vKMsojL8C7AX7HqKi5P/UejV83CIlnFD6hm4zajfV9fRaPrU6k iz4TpwibNG2nTpKNUVY5/ovwncSaY6QrunxfXxCCB6Gjla5aZrTg/Te0pnN7TrQ/gK8h cziDvEZfRz4pgrsRR5INX5DZYJK4hoxDZ/5s0Hb0aiAQIogb0nxU0rLsMidnAM3IAWqu 7LInxLystbCZBMUBbGesoKTXR5vbmJCA6dP4Dfmwx+OBdRjhAzUb8rHYSV+ZOXhDBU2f tCmA== X-Received: by 10.194.90.15 with SMTP id bs15mr28162677wjb.22.1430594244814; Sat, 02 May 2015 12:17:24 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id y7sm12945071wjw.16.2015.05.02.12.17.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 May 2015 12:17:24 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <837fsrqwsh.fsf@gnu.org> <5544A2EE.1010507@yandex.ru> <83oam3p6ux.fsf@gnu.org> <5544BCB7.8010702@yandex.ru> <83k2wrp2qq.fsf@gnu.org> <5544D444.4060106@yandex.ru> <83a8xnoyni.fsf@gnu.org> <55450C67.9040303@yandex.ru> <837fsqq0mu.fsf@gnu.org> From: Dmitry Gutov message-id: <554522C2.2040108@yandex.ru> Date: Sat, 2 May 2015 22:17:22 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <837fsqq0mu.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/02/2015 09:45 PM, Eli Zaretskii wrote: > We could always ask about the ID file itself, you know... At that point, we don't yet know if ID Utils will be used, or GNU Global, or something else. Maybe we should forget this complication and simply ask the user to visit the tags file first (it's the etags backend, after all). That just seemed awkward to me, because the contents of that file aren't used at all in this scenario (only its location). >> When I say (or read) "search in directory", I understand it to mean the >> subdirectories, too. > > Well, it wasn't entirely clear, perhaps because I know too much about > ID Utils. How come that's a factor? 'mkid' scans the subdirectories. > That's not what happened here: the invocation of 'lid' yields a > non-empty buffer, but then the result is an empty list. That's a > clear sign of some problem somewhere. Yup. > Could be. In general, if the buffer is non-empty, there should be > results. Not a bad heuristic. The buffer said "No 'ID' file found" when I was dealing with a bug in my code. But that wass an error as well. I think we can add that non-empty assertion to `semantic-symref-parse-tool-output'. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 19:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143059597820594 (code B ref 19468); Sat, 02 May 2015 19:47:02 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 19:46:18 +0000 Received: from localhost ([127.0.0.1]:59987 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YodMg-0005M5-4t for submit@debbugs.gnu.org; Sat, 02 May 2015 15:46:18 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:41590) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YodMd-0005Lm-10 for 19468@debbugs.gnu.org; Sat, 02 May 2015 15:46:16 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NNQ00000MOKPL00@a-mtaout22.012.net.il> for 19468@debbugs.gnu.org; Sat, 02 May 2015 22:46:08 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNQ000KXMWVHM90@a-mtaout22.012.net.il>; Sat, 02 May 2015 22:46:08 +0300 (IDT) Date: Sat, 02 May 2015 22:45:52 +0300 From: Eli Zaretskii In-reply-to: <554522C2.2040108@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <834mnupxu7.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <837fsrqwsh.fsf@gnu.org> <5544A2EE.1010507@yandex.ru> <83oam3p6ux.fsf@gnu.org> <5544BCB7.8010702@yandex.ru> <83k2wrp2qq.fsf@gnu.org> <5544D444.4060106@yandex.ru> <83a8xnoyni.fsf@gnu.org> <55450C67.9040303@yandex.ru> <837fsqq0mu.fsf@gnu.org> <554522C2.2040108@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Sat, 2 May 2015 22:17:22 +0300 > > >> When I say (or read) "search in directory", I understand it to mean the > >> subdirectories, too. > > > > Well, it wasn't entirely clear, perhaps because I know too much about > > ID Utils. > > How come that's a factor? 'mkid' scans the subdirectories. Exactly. So it was weird to be asked about a directory. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 20:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143059717322334 (code B ref 19468); Sat, 02 May 2015 20:07:02 +0000 Received: (at 19468) by debbugs.gnu.org; 2 May 2015 20:06:13 +0000 Received: from localhost ([127.0.0.1]:59991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yodfw-0005oA-HV for submit@debbugs.gnu.org; Sat, 02 May 2015 16:06:12 -0400 Received: from mail-wg0-f44.google.com ([74.125.82.44]:34493) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yodfv-0005nw-6o for 19468@debbugs.gnu.org; Sat, 02 May 2015 16:06:11 -0400 Received: by wgso17 with SMTP id o17so117265110wgs.1 for <19468@debbugs.gnu.org>; Sat, 02 May 2015 13:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=mw3rPHlCgWltGiuaREFgauH1GDUfVn4XZtNwdYQDITk=; b=vGGwhGK/EpQNRajNWy2EmTnge56sPJFYnERGjuXWkLmPt3Ho9QPmQvB0nHUMmcl58u 4sEwqHvWR3JQHy0+PHnmqjboxjvuhp/sOaCCRymQXtbAvOg89CsyrJik9aN12Dtx9J9W XV9oV6SmWXCgssF78M7npiAcvAWn0YKudRJtAlQK7fb8fFCEpIOVeH0FuAjxnK1cHQ9+ PFKWB9hYWxCxL4KtZ8GvJYpjf7f28pKGCsxgHT205wlTaM54nZxi1lmig+/oClTiurDU NsN1SIFcXwKOOOxyi5GLwD8yblXFnhLfRF8wgB7xs4LVCoSJg0gx4KnYalCuQhEPyn+d 1CJA== X-Received: by 10.194.47.165 with SMTP id e5mr27864564wjn.128.1430597165757; Sat, 02 May 2015 13:06:05 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id fo7sm3703201wic.1.2015.05.02.13.06.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 May 2015 13:06:05 -0700 (PDT) references: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <837fsrqwsh.fsf@gnu.org> <5544A2EE.1010507@yandex.ru> <83oam3p6ux.fsf@gnu.org> <5544BCB7.8010702@yandex.ru> <83k2wrp2qq.fsf@gnu.org> <5544D444.4060106@yandex.ru> <83a8xnoyni.fsf@gnu.org> <55450C67.9040303@yandex.ru> <837fsqq0mu.fsf@gnu.org> <554522C2.2040108@yandex.ru> <834mnupxu7.fsf@gnu.org> From: Dmitry Gutov message-id: <55452E29.3060601@yandex.ru> Date: Sat, 2 May 2015 23:06:01 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <834mnupxu7.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/02/2015 10:45 PM, Eli Zaretskii wrote: > Exactly. So it was weird to be asked about a directory. It's the directory we expect the ID file to be in. Or GPATH, or cscope.out. Or none of them (then we use Grep). Maybe you expect the default directory to be used automatically, but I wouldn't like to optimize for "flat" code bases. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 May 2015 14:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143066427412815 (code B ref 19468); Sun, 03 May 2015 14:45:02 +0000 Received: (at 19468) by debbugs.gnu.org; 3 May 2015 14:44:34 +0000 Received: from localhost ([127.0.0.1]:60831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yov8D-0003Kc-6S for submit@debbugs.gnu.org; Sun, 03 May 2015 10:44:33 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:46565) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yov89-0003KL-SN for 19468@debbugs.gnu.org; Sun, 03 May 2015 10:44:30 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NNS0030039RNR00@mtaout27.012.net.il> for 19468@debbugs.gnu.org; Sun, 03 May 2015 17:39:32 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNS00K7Y3DW9680@mtaout27.012.net.il>; Sun, 03 May 2015 17:39:32 +0300 (IDT) Date: Sun, 03 May 2015 17:44:24 +0300 From: Eli Zaretskii In-reply-to: <5544C018.5090306@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83egmxu3ef.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <837fsrqwsh.fsf@gnu.org> <5544A2EE.1010507@yandex.ru> <83oam3p6ux.fsf@gnu.org> <83lhh7p5j7.fsf@gnu.org> <5544C018.5090306@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Sat, 2 May 2015 15:16:24 +0300 > > On 05/02/2015 02:45 PM, Eli Zaretskii wrote: > > > Found it: that --color=always _is_ the problem, since the SGR escapes > > interfere with the search. How does this work on Posix platforms? > > Should we filter out that switch unconditionally? > > It works okay either way here. But if "--color=always" in > grep-find-template is a problem on Windows, why is it there in the first > place? I recalled the reason: grep-find wants to display the colorification, by converting SGR escapes into Emacs faces, so it needs those escapes. However, since on Windows subprocesses are run via pipes, which fail the isatty test, Grep will not produce colors under "auto", so we use "always" instead. CEDET shouldn't have blindly copied the template, because its needs are different, and in particular it doesn't need or want the colors anyway. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 May 2015 14:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14307508924339 (code B ref 19468); Mon, 04 May 2015 14:49:02 +0000 Received: (at 19468) by debbugs.gnu.org; 4 May 2015 14:48:12 +0000 Received: from localhost ([127.0.0.1]:33861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YpHfH-00017u-DI for submit@debbugs.gnu.org; Mon, 04 May 2015 10:48:11 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:65103) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YpHfF-00017e-QT for 19468@debbugs.gnu.org; Mon, 04 May 2015 10:48:10 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NNT00500YFLYZ00@a-mtaout20.012.net.il> for 19468@debbugs.gnu.org; Mon, 04 May 2015 17:48:03 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNT005IZYG2MX80@a-mtaout20.012.net.il>; Mon, 04 May 2015 17:48:03 +0300 (IDT) Date: Mon, 04 May 2015 17:48:06 +0300 From: Eli Zaretskii In-reply-to: <55450AFC.8040403@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83383ctn4p.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83bni8wbin.fsf@gnu.org> <554009A5.5020001@yandex.ru> <83wq0vszof.fsf@gnu.org> <55411842.1020102@yandex.ru> <83a8xqu80z.fsf@gnu.org> <55441587.6050004@yandex.ru> <837fsrqwsh.fsf@gnu.org> <5544A2EE.1010507@yandex.ru> <83oam3p6ux.fsf@gnu.org> <5544BCB7.8010702@yandex.ru> <83egmzp04h.fsf@gnu.org> <55450AFC.8040403@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Sat, 2 May 2015 20:35:56 +0300 > > On 05/02/2015 04:41 PM, Eli Zaretskii wrote: > > There's some tricky logic in ID Utils wrt when to report relative file > > names and when not, and I guess CEDET doesn't expect absolute file > > names, especially not on Windows. With the patch below, it works for > > me both ways. > > It doesn't break anything here, please go ahead. Done, with a couple more such blunders. My favorite is this (from cedet/semantic/bovine/gcc.el): (when (file-accessible-directory-p path) (when (if (memq system-type '(windows-nt)) (/= ?/ (nth 1 chars)) <<<<<<<<<<<<<<<< (= ?/ (nth 1 chars))) <<<<<<<<<<<<<<<< (add-to-list 'inc-path (expand-file-name (substring line 1)) which evidently wants to make sure the file name is in absolute form. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 21 Feb 2016 23:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , 19468@debbugs.gnu.org Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.145609561532578 (code B ref 19468); Sun, 21 Feb 2016 23:01:02 +0000 Received: (at 19468) by debbugs.gnu.org; 21 Feb 2016 23:00:15 +0000 Received: from localhost ([127.0.0.1]:36673 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aXcz9-0008TO-4t for submit@debbugs.gnu.org; Sun, 21 Feb 2016 18:00:15 -0500 Received: from mail-wm0-f48.google.com ([74.125.82.48]:33018) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aXcz7-0008TC-Ug for 19468@debbugs.gnu.org; Sun, 21 Feb 2016 18:00:14 -0500 Received: by mail-wm0-f48.google.com with SMTP id g62so135006700wme.0 for <19468@debbugs.gnu.org>; Sun, 21 Feb 2016 15:00:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=UTLyh8KwvIAZqDzGV8+S0LNtUId45wznl/n/tIGojq4=; b=aGYbZnxtTros3bXpvT0SoPRCEDsxtjGyou6tU/5i7pFc2MWcFEkUyO/WjV5hjfIyq6 wIt0A5ZqPGdur32Xz0MbbO13UNpHkkaCNBePISZO0kt5y5eBMWBCfFA6Rz67O64zb143 9GoqCuqff4yBo9pBeRrLY8Cdenfvex6oYYVc8o7qWAGH/LRIZwDmE2wy3zDuH7FNH9+I UUGGzCcJsqUbYGTujh7SACst4zSnr3XE6XEGLZ7WDqLBD2q5IFaaHR9SPj5w9U3iGDk3 jp5RytU9VeiSAD3yhqdriAo/aIIcJ0hDo4hIoj31oce7FpQ34WIYdRr1FdojKQmF8D1y g1PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=UTLyh8KwvIAZqDzGV8+S0LNtUId45wznl/n/tIGojq4=; b=OYDfLQFxT6iGjzWxcQuSEsKrJ7R2A91bsCBYF3AHrv1BXYN16BBGML7D4QHDPyYS7I XiLfYJspPjk1c8O7xhAPDutwT+hvIoMfo7en66mzcdPJgbS0QY/g6iRYsbi3g6XYAvu/ V9mAtaHtZRYBSR1+Lhy1fXfUoHmkX3hOedmwJuvWHA6Nx6hsZ5zL8jzefC9i/y32dqsZ zw9kxte1KaUDclVtYz2YOFvnNpdwBBEx4hookZTAAKQ1oagUk4oj/13lq2CYwPM7E77r lZJc6WpRTWCCJ4NFDJ4c00yOojDpkrNkS/3rfFEvMFN3ERAnjQu+Av2snLKps4Uo9h6G xtJA== X-Gm-Message-State: AG10YOSETgIx/Fz2dPUai2lyTt7tTseqOKtQuINglNgi0MQJKIamM81amT2DuGahiNjKTQ== X-Received: by 10.194.113.38 with SMTP id iv6mr24420913wjb.126.1456095608405; Sun, 21 Feb 2016 15:00:08 -0800 (PST) Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id ka7sm21844723wjb.8.2016.02.21.15.00.06 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Feb 2016 15:00:07 -0800 (PST) References: <83zja6b3tc.fsf@gnu.org> From: Dmitry Gutov Message-ID: <56CA4176.5070900@yandex.ru> Date: Mon, 22 Feb 2016 01:00:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <83zja6b3tc.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli, Would you say there's something left to fix here? Otherwise, it's probably time to close it. From unknown Sat Aug 16 21:19:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19468: 25.0.50; UI inconveniences with M-. Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 22 Feb 2016 17:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 19468@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.145616150829912 (code B ref 19468); Mon, 22 Feb 2016 17:19:02 +0000 Received: (at 19468) by debbugs.gnu.org; 22 Feb 2016 17:18:28 +0000 Received: from localhost ([127.0.0.1]:38297 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aXu7w-0007mO-Gd for submit@debbugs.gnu.org; Mon, 22 Feb 2016 12:18:28 -0500 Received: from eggs.gnu.org ([208.118.235.92]:58955) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aXu7u-0007mB-KF for 19468@debbugs.gnu.org; Mon, 22 Feb 2016 12:18:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aXu7m-0002BI-CI for 19468@debbugs.gnu.org; Mon, 22 Feb 2016 12:18:21 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40558) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXu7m-0002BD-9C; Mon, 22 Feb 2016 12:18:18 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1304 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aXu7k-0006JV-I8; Mon, 22 Feb 2016 12:18:17 -0500 Date: Mon, 22 Feb 2016 19:18:07 +0200 Message-Id: <83h9h0ll4g.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <56CA4176.5070900@yandex.ru> (message from Dmitry Gutov on Mon, 22 Feb 2016 01:00:06 +0200) References: <83zja6b3tc.fsf@gnu.org> <56CA4176.5070900@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Dmitry Gutov > Date: Mon, 22 Feb 2016 01:00:06 +0200 > > Eli, > > Would you say there's something left to fix here? Otherwise, it's > probably time to close it. Feel free to close. I use the feature all the time since the pretest started, and I think it looks good, thanks. From unknown Sat Aug 16 21:19:43 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Eli Zaretskii Subject: bug#19468: closed (Re: bug#19468: 25.0.50; UI inconveniences with M-.) Message-ID: References: <56CB7A77.6070306@yandex.ru> <83zja6b3tc.fsf@gnu.org> X-Gnu-PR-Message: they-closed 19468 X-Gnu-PR-Package: emacs Reply-To: 19468@debbugs.gnu.org Date: Mon, 22 Feb 2016 21:16:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1456175762-26682-1" This is a multi-part message in MIME format... ------------=_1456175762-26682-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #19468: 25.0.50; UI inconveniences with M-. which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 19468@debbugs.gnu.org. --=20 19468: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D19468 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1456175762-26682-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 19468-done) by debbugs.gnu.org; 22 Feb 2016 21:15:45 +0000 Received: from localhost ([127.0.0.1]:38550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aXxpZ-0006vt-ME for submit@debbugs.gnu.org; Mon, 22 Feb 2016 16:15:45 -0500 Received: from mail-wm0-f54.google.com ([74.125.82.54]:37657) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aXxpX-0006vd-Mj for 19468-done@debbugs.gnu.org; Mon, 22 Feb 2016 16:15:43 -0500 Received: by mail-wm0-f54.google.com with SMTP id g62so182708525wme.0 for <19468-done@debbugs.gnu.org>; Mon, 22 Feb 2016 13:15:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=6UBXRX8i4ZwxFDafivQlR78Z4CviJXVAOwd8K3rNc1c=; b=pN1BpHAVqZPoQB0S1/nYN2LeQP3aW7stzYy+wlI5tXQvN4SRwWkpcbiJzfEVg+KzGQ YkVXTxnNMCt2aSY9GgZ6cIwpu3t8JMBs/p9SJW+71ZNNRNsgcly/N4C03VBM9qxIRstB AInxSBSQTUYmmo3q1elwceQswjht7uXAgZNJvltexrxgnGxIvjSb1VQtXZY6jAng951O mDP+g56RBseQi9nEaAw9zSSbbilZCw9lKZgeIhXCt1vzTvrmBzNEriOq354DGjv8m661 W9nzHEYMNZjnnQ7D/p6Q3Q0x43pV1B5ioaojvaATsJbm+yOlKf7POL/8QAi8MzrTsWXH bngQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=6UBXRX8i4ZwxFDafivQlR78Z4CviJXVAOwd8K3rNc1c=; b=hu6Wtg9/hxkK1e16mtxv3Tzypp3y5bpwkR4Wk+I+EoNKGaHIv2ZhCz7mnE1unqUQax Ta5URqnK766+qBhA/zE6h1iGsbX+3yyo/AXZ57RZJ3SXCMrrtkAgxH5jclkPHqPiQA2J DlEx1U4C361sa/XtIIJvK/ZQjBBOJP20Tx+dcO4Zg7E9pDrgmTbEbceP5aRtObUpsSls pCXXk+vr2jrFKwBoHohpp6excxP15VUUrsxOtAE0GsgveBNN/5XBgO8LleuJCNAwMFtE AlckJoDUyt33B4OXUhvYyR19WWdZv2a+kaC3quOTxLhF84U70V6n1M1MNn1hNZ073EXY L2Rg== X-Gm-Message-State: AG10YOQiS8ZnCW820xxGLJjawyI/Nhh60+VOwV/c9sUXIWiWujjlFqA3mqaa/oAkD0e9TQ== X-Received: by 10.194.185.108 with SMTP id fb12mr31599492wjc.89.1456175737969; Mon, 22 Feb 2016 13:15:37 -0800 (PST) Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id p125sm22871410wmd.16.2016.02.22.13.15.36 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Feb 2016 13:15:36 -0800 (PST) Subject: Re: bug#19468: 25.0.50; UI inconveniences with M-. To: Eli Zaretskii References: <83zja6b3tc.fsf@gnu.org> <56CA4176.5070900@yandex.ru> <83h9h0ll4g.fsf@gnu.org> From: Dmitry Gutov Message-ID: <56CB7A77.6070306@yandex.ru> Date: Mon, 22 Feb 2016 23:15:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <83h9h0ll4g.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 19468-done Cc: 19468-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 02/22/2016 07:18 PM, Eli Zaretskii wrote: > Feel free to close. I use the feature all the time since the pretest > started, and I think it looks good, thanks. That's great to hear. Closing. ------------=_1456175762-26682-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 29 Dec 2014 20:26:49 +0000 Received: from localhost ([127.0.0.1]:60564 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5gts-0001lv-DV for submit@debbugs.gnu.org; Mon, 29 Dec 2014 15:26:48 -0500 Received: from eggs.gnu.org ([208.118.235.92]:39842) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5gtq-0001ln-B4 for submit@debbugs.gnu.org; Mon, 29 Dec 2014 15:26:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y5gto-00015M-R6 for submit@debbugs.gnu.org; Mon, 29 Dec 2014 15:26:46 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:50057) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5gto-00015I-Oj for submit@debbugs.gnu.org; Mon, 29 Dec 2014 15:26:44 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41554) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5gtn-0002sp-6x for bug-gnu-emacs@gnu.org; Mon, 29 Dec 2014 15:26:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y5gti-00014b-60 for bug-gnu-emacs@gnu.org; Mon, 29 Dec 2014 15:26:43 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:51604) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5gth-00014R-Q9 for bug-gnu-emacs@gnu.org; Mon, 29 Dec 2014 15:26:38 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NHD00D002326Q00@a-mtaout20.012.net.il> for bug-gnu-emacs@gnu.org; Mon, 29 Dec 2014 22:26:36 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHD00DJR24B6C00@a-mtaout20.012.net.il> for bug-gnu-emacs@gnu.org; Mon, 29 Dec 2014 22:26:36 +0200 (IST) Date: Mon, 29 Dec 2014 22:26:23 +0200 From: Eli Zaretskii Subject: 25.0.50; UI inconveniences with M-. X-012-Sender: halo1@inter.net.il To: bug-gnu-emacs@gnu.org Message-id: <83zja6b3tc.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Make sure you generated src/TAGS, and then: emacs -Q C-x C-f src/buffer.c RET M-x visit-tags-table RET RET M-. display_line RET This pops up a *xref* buffer which looks like this: d:/gnu/git/emacs/trunk/src/xdisp.c display_line move_it_in_display_line_to move_it_in_display_line with point at the beginning of the first line. Why doesn't it put me on "display_line"s line, and display its definition at the same time? This is a regression from the old tags feature, where just "M-. RET" will already show the first matching definition. Further, this buffer's name, *xref*, has no mnemonic significance, and there are no clues as to what it wants to tell me or what is expected of me. The candidates are not mouse-sensitive, either, which is un-Emacsy. It functions like *Completions*, but it ain't one. By trial and error I found out that I'm expected to move to the candidate I want with cursor movement keys, and press RET to exit the buffer. Moving up an down is slow, probably because it visits files without waiting for RET or some other gesture to select a candidate (why was that design decision made?). Hitting RET on the first line, the one that shows the file name, results in "No reference at point", which is not really useful. Another peculiarity is that once I press arrow once, I can no longer get back to the first line, the one that shows the source file: pressing on the 2nd line doesn't move point, but it does return the original buffer to the window above *xref*. Weird. Finally, invoking the same command from the menu bar ought to present a dialog box with the candidates, according to the general rule: if a command was invoked by a mouse gesture, selection of candidates is via a GUI dialog, not a special-purpose buffer. But that doesn't happen. In sum: please make the new feature at least as good as the old one it replaces. And when introducing new exhibits, like the *xref* window, please make them self-explanatory and convenient/natural to use for newbies and veterans alike. TIA In GNU Emacs 25.0.50.110 (i686-pc-mingw32) of 2014-12-29 on HOME-C4E4A596F7 Repository revision: ce1ebdf1ba8acc75e8f959f414652cdc87e76401 Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --prefix=/d/usr --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'' Configured features: XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB Important settings: value of $LANG: ENU locale-coding-system: cp1255 Major mode: XREF Minor modes in effect: diff-auto-refine-mode: t tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: t line-number-mode: t Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Starting a new list of tags tables M-. runs the command xref-find-definitions M-, runs the command xref-pop-marker-stack Making tags completion table for d:/gnu/git/emacs/trunk/src/TAGS...80% Making tags completion table for d:/gnu/git/emacs/trunk/lisp/TAGS...94% Making tags completion table for d:/gnu/git/emacs/trunk/lwlib/TAGS... Making tags completion table for d:/gnu/git/emacs/trunk/src/TAGS...done Making completion list... xref--location-at-point: No reference at point Load-path shadows: None found. Features: (shadow sort gnus-util mail-extr emacsbug message dired format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils cl-macs gv thingatpt etags xref eieio byte-opt bytecomp byte-compile cl-extra cconv eieio-core cl-loaddefs cl-lib ring vc-git diff-mode easy-mmode cc-mode cc-fonts easymenu cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs time-date tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table w32-win w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer 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 make-network-process w32notify w32 multi-tty emacs) Memory information: ((conses 8 123285 11708) (symbols 32 104663 1) (miscs 32 77 302) (strings 16 108087 9345) (string-bytes 1 2510300) (vectors 8 15137) (vector-slots 4 446128 6934) (floats 8 75 209) (intervals 28 2628 236) (buffers 516 18)) ------------=_1456175762-26682-1--