From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 29 14:27:57 2014 Received: (at submit) by debbugs.gnu.org; 29 Dec 2014 19:27:57 +0000 Received: from localhost ([127.0.0.1]:60540 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5fyv-00007A-7h for submit@debbugs.gnu.org; Mon, 29 Dec 2014 14:27:57 -0500 Received: from eggs.gnu.org ([208.118.235.92]:59939) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5fyt-000072-KW for submit@debbugs.gnu.org; Mon, 29 Dec 2014 14:27:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y5fys-0002Mc-8c for submit@debbugs.gnu.org; Mon, 29 Dec 2014 14:27:55 -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 ([2001:4830:134:3::11]:47497) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5fys-0002MY-6e for submit@debbugs.gnu.org; Mon, 29 Dec 2014 14:27:54 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33418) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5fyq-0004JC-Oe for bug-gnu-emacs@gnu.org; Mon, 29 Dec 2014 14:27:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y5fyn-0002Ll-8E for bug-gnu-emacs@gnu.org; Mon, 29 Dec 2014 14:27:52 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:34000) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5fym-0002Lf-Vg for bug-gnu-emacs@gnu.org; Mon, 29 Dec 2014 14:27:49 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NHC00J00Z2EF400@a-mtaout22.012.net.il> for bug-gnu-emacs@gnu.org; Mon, 29 Dec 2014 21:27:46 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHC00JP0ZEAHC00@a-mtaout22.012.net.il> for bug-gnu-emacs@gnu.org; Mon, 29 Dec 2014 21:27:46 +0200 (IST) Date: Mon, 29 Dec 2014 21:27:33 +0200 From: Eli Zaretskii Subject: 25.0.50; xref-find-def doesn't find C functions X-012-Sender: halo1@inter.net.il To: bug-gnu-emacs@gnu.org Message-id: <8361cucl3u.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 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 (-----) Run "make TAGS" in the top-level directory, then: emacs -Q Click menu-bar->Edit->Go To->Set Tags File Name Navigate to src/TAGS and select it in the file selection dialog Click menu-bar->Edit->Go To->Find Definition Type "display_line RET" at the prompt => [No match] But of course this function does exists and lives in xdisp.c. The above does work if I invoke the same sequence from a buffer visiting xdisp.c (or any other file from src/), but that sounds like an inconvenience. The old tags feature didn't require that. 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: Lisp Interaction 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 line-number-mode: t Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Quit Starting a new list of tags tables Quit 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 thingatpt vc-git diff-mode easymenu easy-mmode etags xref eieio byte-opt bytecomp byte-compile cl-extra cconv eieio-core cl-loaddefs cl-lib ring 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 91533 8774) (symbols 32 19742 0) (miscs 32 43 119) (strings 16 17923 4127) (string-bytes 1 497284) (vectors 8 12420) (vector-slots 4 417644 3202) (floats 8 71 100) (intervals 28 247 31) (buffers 516 12)) From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 29 23:57:55 2014 Received: (at 19466) by debbugs.gnu.org; 30 Dec 2014 04:57:55 +0000 Received: from localhost ([127.0.0.1]:60636 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5osU-0006de-O5 for submit@debbugs.gnu.org; Mon, 29 Dec 2014 23:57:55 -0500 Received: from mail-we0-f178.google.com ([74.125.82.178]:38245) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5osS-0006dU-3R for 19466@debbugs.gnu.org; Mon, 29 Dec 2014 23:57:52 -0500 Received: by mail-we0-f178.google.com with SMTP id p10so472537wes.23 for <19466@debbugs.gnu.org>; Mon, 29 Dec 2014 20:57:51 -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:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/AoRES7daqAGtrlt36O+iPXTGPVpdcePqSGlzkR7h9I=; b=ZQKesE1k7VLTDlRktmEGOksygby/ppFgJnbOelEV/qCkSrZvZ+bhiMogFleqb9PGIq d3HLjR+IAykmGkaNYX8fdd5NdNmWRkh1WjJV3SdRzialONIqtL1HqgfdHoaWpMXxijNm 3bQh5Y5BXerzc5H3v4osRe94w9EFozvQT7agEyiAw9rJHfK4XWfO2TwBkpUEl1Cr/1cs mkNMmkfKJPMHD2UHyPvtUxlzLSzIHjBUYgjN4k9aeJUp3xsb4sYHxXIHC0vQuMzPTX0k SF1YG69iHMpBxkB2b1glh2bDoz9Cx1QtQx5lRzNXz9NwTGmo+IdFv3CaVIU4Llbg1N4f z7aw== X-Received: by 10.194.234.40 with SMTP id ub8mr120360315wjc.100.1419915471395; Mon, 29 Dec 2014 20:57:51 -0800 (PST) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id r3sm41948143wic.10.2014.12.29.20.57.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Dec 2014 20:57:50 -0800 (PST) Message-ID: <54A230CD.3040309@yandex.ru> Date: Tue, 30 Dec 2014 06:57:49 +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 To: Eli Zaretskii , 19466@debbugs.gnu.org Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> In-Reply-To: <8361cucl3u.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 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 09:27 PM, Eli Zaretskii wrote: > Run "make TAGS" in the top-level directory, then: > > emacs -Q > Click menu-bar->Edit->Go To->Set Tags File Name > Navigate to src/TAGS and select it in the file selection dialog > Click menu-bar->Edit->Go To->Find Definition > Type "display_line RET" at the prompt > => [No match] Are you doing that in e.g. emacs-lisp-mode buffer? Naturally, it wouldn't work, because that major mode defines its own identifier completion table and find-definition function. I understand what you're trying to do, but don't see a way to achieve that while keeping the uniform interface for the user in different major modes (which can use different navigation logic). > The above does work if I invoke the same sequence from a buffer > visiting xdisp.c (or any other file from src/), Or buffer in any major mode that doesn't define its own navigation function. > but that sounds like > an inconvenience. The old tags feature didn't require that. Suggestions welcome, but maybe you should just keep using `find-tag'. The generic navigation commands are more useful to have as the menu items, though. Alternatively, you could reset `xref-find-function' and `xref-identifier-completion-table-function' to their default values in `emacs-lisp-mode-hook'. That could be a decent choice if your TAGS file includes the lisp files as well. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 30 10:32:01 2014 Received: (at 19466) by debbugs.gnu.org; 30 Dec 2014 15:32:01 +0000 Received: from localhost ([127.0.0.1]:32941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5ym8-00009Z-Rt for submit@debbugs.gnu.org; Tue, 30 Dec 2014 10:32:01 -0500 Received: from mtaout28.012.net.il ([80.179.55.184]:54851) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5ym6-00009O-0q for 19466@debbugs.gnu.org; Tue, 30 Dec 2014 10:31:59 -0500 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NHE00J00J0O2200@mtaout28.012.net.il> for 19466@debbugs.gnu.org; Tue, 30 Dec 2014 17:29:47 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHE008G4J1N4WA0@mtaout28.012.net.il>; Tue, 30 Dec 2014 17:29:47 +0200 (IST) Date: Tue, 30 Dec 2014 17:31:46 +0200 From: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions In-reply-to: <54A230CD.3040309@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Gutov Message-id: <83vbktb1ct.fsf@gnu.org> References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org 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: 1.0 (+) > Date: Tue, 30 Dec 2014 06:57:49 +0200 > From: Dmitry Gutov > > On 12/29/2014 09:27 PM, Eli Zaretskii wrote: > > Run "make TAGS" in the top-level directory, then: > > emacs -Q > Click menu-bar->Edit->Go To->Set Tags File Name > Navigate to src/TAGS and select it in the file selection dialog > Click menu-bar->Edit->Go To->Find Definition > Type "display_line RET" at the prompt > => [No match] > > Are you doing that in e.g. emacs-lisp-mode buffer? I did it in *scratch*. But *scratch*'s major mode is not emacs-lisp-mode, it's lisp-interaction-mode. I think the difference is significant for the purposes of this discussion. > Naturally, it wouldn't work, because that major mode defines its own identifier completion table and find-definition function. > > I understand what you're trying to do, but don't see a way to achieve that while keeping the uniform interface for the user in different major modes (which can use different navigation logic). Isn't it possible to _prefer_ the symbols that are consistent with the major mode, but not entirely discard the other possible candidates? In a mixed-language project such as Emacs, these subtle conditions that completely conceal symbols depending on the current mode, make very little sense to me. (And there are other mixed-language projects out there, like Guile, GDB, etc.) The Emacs TAGS tables traditionally included tags from lisp/ files in src/TAGS, and for a very good reason. > Suggestions welcome, but maybe you should just keep using `find-tag'. The generic navigation commands are more useful to have as the menu items, though. I assume that this new facility is an improvement, so I _want_ to use it. Especially since NEWS says: ** etags As a result of the above, these commands are now obsolete: `find-tag-other-window', `find-tag-other-frame', `find-tag-regexp', `tags-apropos' and `tags-loop-continue'. Considering something obsolete means that a replacement is available that is as good or better than the replaced feature. I don't want to go back to obsolete commands, unless I really have to, i.e. unless I find the situation with xref unbearable. I hope we are not there yet. > Alternatively, you could reset `xref-find-function' and `xref-identifier-completion-table-function' to their default values in `emacs-lisp-mode-hook'. That could be a decent choice if your TAGS file includes the lisp files as well. See above: out src/TAGS includes lisp/TAGS. We do this for a long time, and it's a tremendously useful thing when working on Emacs development. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 30 13:05:47 2014 Received: (at 19466) by debbugs.gnu.org; 30 Dec 2014 18:05:47 +0000 Received: from localhost ([127.0.0.1]:33075 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61Ax-0004lJ-1D for submit@debbugs.gnu.org; Tue, 30 Dec 2014 13:05:47 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:51763) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61Av-0004l4-3Z for 19466@debbugs.gnu.org; Tue, 30 Dec 2014 13:05:45 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8PAOwQflRFpY0B/2dsb2JhbABbgweDYIVawjuCYgQCAoEkFwEBAQEBAXyEAwEBAwFWIwULCzQSFBgNJIhKCdZZAQEBAQEBBAEBAQEekG8HhEgFiwGkLoF4hBkhgncBAQE X-IPAS-Result: Aj8PAOwQflRFpY0B/2dsb2JhbABbgweDYIVawjuCYgQCAoEkFwEBAQEBAXyEAwEBAwFWIwULCzQSFBgNJIhKCdZZAQEBAQEBBAEBAQEekG8HhEgFiwGkLoF4hBkhgncBAQE X-IronPort-AV: E=Sophos;i="5.07,502,1413259200"; d="scan'208";a="104190512" 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:05:43 -0500 Received: by pastel.home (Postfix, from userid 20848) id 8DDCDDE3; Tue, 30 Dec 2014 13:05:43 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions Message-ID: References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> Date: Tue, 30 Dec 2014 13:05:43 -0500 In-Reply-To: <83vbktb1ct.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 30 Dec 2014 17:31:46 +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-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Dmitry Gutov 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 (/) > Isn't it possible to _prefer_ the symbols that are consistent with the > major mode, but not entirely discard the other possible candidates? Indeed there should be a way to use the tags.el backend (or other similar whole-project systems like GNU global, ...) instead of the major mode's backend. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 30 13:25:33 2014 Received: (at 19466) by debbugs.gnu.org; 30 Dec 2014 18:25:33 +0000 Received: from localhost ([127.0.0.1]:33095 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61U4-0005Gp-DQ for submit@debbugs.gnu.org; Tue, 30 Dec 2014 13:25:32 -0500 Received: from mail-wi0-f179.google.com ([209.85.212.179]:59775) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61U0-0005GX-3P for 19466@debbugs.gnu.org; Tue, 30 Dec 2014 13:25:28 -0500 Received: by mail-wi0-f179.google.com with SMTP id ex7so24513917wid.6 for <19466@debbugs.gnu.org>; Tue, 30 Dec 2014 10:25:27 -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=6xWQbn9+l27Z4GBAKMdPdkoc7dSu3+oEWBgVdSejdig=; b=KXK0J4nB9ZkPFpqgNZQ2rEa7t4gy63i0yyRwEvzbg6WfXC3Egg1yX6zRqrM/tazQ9+ ijz5RrtRYBHXa6qDjUDXuOiGYNmevMJSd3P3ymmGIjOc/bWQMES0k8V6sMTXqLFS0gq2 bz3J5s6gzqxqltQeSzisPwu/DoDCETu6HO7aPAWD7aWjww4tDy7zHuJ1Pbi7K1MO1W1J t5kaQ1KRMQV5dum+KF5/4zsV4ELG2I5o/QvWUhnfglborhYdZ2MsO1hIWDTRXuzvBqVo tW13otT5yBgSMnEY0J3T6mOubpKVYr62SUUXN/hlUO+sNv9z/C6HOT/DKwkRzHqC5tD7 ue5g== X-Received: by 10.180.88.165 with SMTP id bh5mr109190154wib.77.1419963927638; Tue, 30 Dec 2014 10:25:27 -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 n4sm42113272wia.7.2014.12.30.10.25.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Dec 2014 10:25:27 -0800 (PST) Message-ID: <54A2EE15.3020406@yandex.ru> Date: Tue, 30 Dec 2014 20:25:25 +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 To: Stefan Monnier , Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.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-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org 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:05 PM, Stefan Monnier wrote: >> Isn't it possible to _prefer_ the symbols that are consistent with the >> major mode, but not entirely discard the other possible candidates? > > Indeed there should be a way to use the tags.el backend (or other > similar whole-project systems like GNU global, ...) instead of the > major mode's backend. In general, a minor mode would do that (set project-specific xref-find-function and friends, etc), probably using a system like projectile to determine the current project kind. We could do something specific for Emacs sources, but if using lisp/TAGS is preferred over find-func by the same developers who work on C sources, maybe emacs-lisp-mode shouldn't make any changes in xref-* variables for them. An boolean option would be the simplest solution. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 30 13:34:18 2014 Received: (at 19466) by debbugs.gnu.org; 30 Dec 2014 18:34:18 +0000 Received: from localhost ([127.0.0.1]:33111 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61cX-0005WZ-LE for submit@debbugs.gnu.org; Tue, 30 Dec 2014 13:34:18 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:42320) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61cU-0005WQ-Kz for 19466@debbugs.gnu.org; Tue, 30 Dec 2014 13:34:15 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NHE00A00RJD1900@a-mtaout22.012.net.il> for 19466@debbugs.gnu.org; Tue, 30 Dec 2014 20:34:13 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHE0099DRL0V730@a-mtaout22.012.net.il>; Tue, 30 Dec 2014 20:34:13 +0200 (IST) Date: Tue, 30 Dec 2014 20:34:03 +0200 From: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions In-reply-to: <54A2EE15.3020406@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Gutov Message-id: <831tnhasx0.fsf@gnu.org> References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, monnier@iro.umontreal.ca 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: 1.0 (+) > Date: Tue, 30 Dec 2014 20:25:25 +0200 > From: Dmitry Gutov > CC: 19466@debbugs.gnu.org > > On 12/30/2014 08:05 PM, Stefan Monnier wrote: > >> Isn't it possible to _prefer_ the symbols that are consistent with the > >> major mode, but not entirely discard the other possible candidates? > > > > Indeed there should be a way to use the tags.el backend (or other > > similar whole-project systems like GNU global, ...) instead of the > > major mode's backend. > > In general, a minor mode would do that (set project-specific > xref-find-function and friends, etc), probably using a system like > projectile to determine the current project kind. > > We could do something specific for Emacs sources, but if using lisp/TAGS > is preferred over find-func by the same developers who work on C > sources, maybe emacs-lisp-mode shouldn't make any changes in xref-* > variables for them. An boolean option would be the simplest solution. I probably don't understand exactly what you are suggesting, but can we look at this from another angle: how can xref support looking up symbols for projects that use more than one major mode? E.g., could the back-end be a list of functions, rather than just one? From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 30 13:38:13 2014 Received: (at 19466) by debbugs.gnu.org; 30 Dec 2014 18:38:13 +0000 Received: from localhost ([127.0.0.1]:33115 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61gL-0005cV-G4 for submit@debbugs.gnu.org; Tue, 30 Dec 2014 13:38:13 -0500 Received: from mail-wg0-f45.google.com ([74.125.82.45]:58615) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y61gD-0005cE-8b for 19466@debbugs.gnu.org; Tue, 30 Dec 2014 13:38:11 -0500 Received: by mail-wg0-f45.google.com with SMTP id b13so21270685wgh.18 for <19466@debbugs.gnu.org>; Tue, 30 Dec 2014 10:38:04 -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=hRPJ3G66iv0rXawlSTaMkuKZSMMsY6VvB5Qhb4vw26s=; b=aI7ktPS0F3dWTrrWxuCCQPtfU//IsuYbCXXfzF2IhEJfjhC4vXST17S3ifuQ8NI+yY sDmYevvt6E+u49casdsglHEWwEkhGKEURnAWUv2a+Hwl2XPsVsri3BTMmsSiT15r1QVy 7GKX9ntCfPztjZZ+PS4XHoqNtXIiUR98SpkYL88LDzchnkTnpHorN4auYxPadqAxNgAT kMGzhgJStiXwiYeiUuhBLd6YGLwVi3ExensxX2Kk2UuIumQc8pxKxvOybZWP75h0+K88 x4G/25SMwmZGlYliSVaw/j0HghIfGUvq+py92moW7CJEXQ81qNeb9fiTgZekBvzwNW+d 1PZg== X-Received: by 10.181.13.42 with SMTP id ev10mr106745355wid.78.1419964684741; Tue, 30 Dec 2014 10:38:04 -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 ei5sm44353233wid.2.2014.12.30.10.38.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Dec 2014 10:38:04 -0800 (PST) Message-ID: <54A2F10A.3010501@yandex.ru> Date: Tue, 30 Dec 2014 20:38:02 +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 To: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> In-Reply-To: <831tnhasx0.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org 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:34 PM, Eli Zaretskii wrote: > I probably don't understand exactly what you are suggesting, but can > we look at this from another angle: how can xref support looking up > symbols for projects that use more than one major mode? E.g., could > the back-end be a list of functions, rather than just one? Like Stefan explained in the older discussion about this new feature (but in the context of `next-error-function'), `add-function' is probably the way to go for minor modes. But that's not what I'm suggesting to do here. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 30 15:44:00 2014 Received: (at 19466) by debbugs.gnu.org; 30 Dec 2014 20:44:00 +0000 Received: from localhost ([127.0.0.1]:33177 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y63e4-0001r7-Av for submit@debbugs.gnu.org; Tue, 30 Dec 2014 15:44:00 -0500 Received: from mail-wg0-f54.google.com ([74.125.82.54]:54479) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y63e1-0001qw-Th for 19466@debbugs.gnu.org; Tue, 30 Dec 2014 15:43:58 -0500 Received: by mail-wg0-f54.google.com with SMTP id z12so3377139wgg.13 for <19466@debbugs.gnu.org>; Tue, 30 Dec 2014 12:43:57 -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=oDZXE8zq3IpGi+SV8zdyMAk5JYv4pE7w2h/AtfngTls=; b=hb/WywsEk3ltbmzm3d6gya0UyiJ/VcUVNyFQyp4vWJ6BQrxvEOfDrR8jsr7+xT9RkI ZeiQnod/GjjVuaBLDyS/JT2g5TlzJS0GGrk8RcSv+B0mjDvX0jWrzPM1a6vdfGD+jx11 3cyMwDmdbEnwyRWkUT2AZ2BBhLPVKkFNGaVzrXGw8WOZ0rLvOpyeYQs0zHz+Ujj9DAB6 SbYjUojl9XlqT51PE7okgLuXS1C9VjVvUO0WkNGsOl9vIEKYun/y7quUvfeA3xwOvFPs +GwAFi9zaczIVEycIJyAHQJIysKFYDxg1UYACZa6lFtPB1tBoRhAJCwU6PJbjVg2Tidu xw8w== X-Received: by 10.180.210.195 with SMTP id mw3mr106911657wic.79.1419972237330; Tue, 30 Dec 2014 12:43:57 -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 r3sm44682785wic.10.2014.12.30.12.43.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Dec 2014 12:43:56 -0800 (PST) Message-ID: <54A30E8B.1020207@yandex.ru> Date: Tue, 30 Dec 2014 22:43:55 +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 To: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> In-Reply-To: <83vbktb1ct.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org 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:31 PM, Eli Zaretskii wrote: > I did it in *scratch*. But *scratch*'s major mode is not > emacs-lisp-mode, it's lisp-interaction-mode. I think the difference > is significant for the purposes of this discussion. I wouldn't say it is (lisp-interaction-mode inherits from emacs-lisp-mode). And if we consider the scratch vs any .el file in the Emacs sources, it's less natural to use tags in scratch because it's conceptually farther from emacs/src/TAGS. >> Naturally, it wouldn't work, because that major mode defines its own identifier completion table and find-definition function. >> >> I understand what you're trying to do, but don't see a way to achieve that while keeping the uniform interface for the user in different major modes (which can use different navigation logic). > > Isn't it possible to _prefer_ the symbols that are consistent with the > major mode, but not entirely discard the other possible candidates? Sure, but that has to be written in a sensible manner, too. Emacs core still has no notion of projects (or even moreso, project types), so it's harder to say "also use etags when in the Emacs sources". Not all projects use etags, and this is almost never true in third-party Lisp projects, such as ELPA packages. > In a mixed-language project such as Emacs, these subtle conditions > that completely conceal symbols depending on the current mode, make > very little sense to me. (And there are other mixed-language projects > out there, like Guile, GDB, etc.) The Emacs TAGS tables traditionally > included tags from lisp/ files in src/TAGS, and for a very good > reason. So if you're fine with tags, do you at all need the specialized navigation provided by emacs-lisp-mode? Like suggested, you could undo the changes made by emacs-lisp-mode to xref-* variables in emacs-lisp-mode-hook. A couple of `kill-local-variable' would suffice. But personally, I'd never choose tags over find-func, and it's not a good default for the many users and third-party developers out there. > Considering something obsolete means that a replacement is available > that is as good or better than the replaced feature. I don't want to > go back to obsolete commands, unless I really have to, i.e. unless I > find the situation with xref unbearable. I hope we are not there yet. Let's hope so. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 30 17:44:23 2014 Received: (at 19466) by debbugs.gnu.org; 30 Dec 2014 22:44:23 +0000 Received: from localhost ([127.0.0.1]:33208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y65WZ-0004qw-EZ for submit@debbugs.gnu.org; Tue, 30 Dec 2014 17:44:23 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:21186) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y65WX-0004qn-RG for 19466@debbugs.gnu.org; Tue, 30 Dec 2014 17:44:22 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8PAOwQflRFpY0B/2dsb2JhbABbgweDYIVawjuCYgQCAoEkFwEBAQEBAXyEAwEBAwFWIwULCzQSFBgNJIhKCdZZAQEBAQEBBAEBAQEekG8HhEgFiwGkLoF4hBkhgncBAQE X-IPAS-Result: Aj8PAOwQflRFpY0B/2dsb2JhbABbgweDYIVawjuCYgQCAoEkFwEBAQEBAXyEAwEBAwFWIwULCzQSFBgNJIhKCdZZAQEBAQEBBAEBAQEekG8HhEgFiwGkLoF4hBkhgncBAQE X-IronPort-AV: E=Sophos;i="5.07,502,1413259200"; d="scan'208";a="104254325" 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 17:44:20 -0500 Received: by pastel.home (Postfix, from userid 20848) id A4592D96; Tue, 30 Dec 2014 17:44:20 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions Message-ID: References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> Date: Tue, 30 Dec 2014 17:44:20 -0500 In-Reply-To: <831tnhasx0.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 30 Dec 2014 20:34:03 +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-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Dmitry Gutov 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 probably don't understand exactly what you are suggesting, but can > we look at this from another angle: how can xref support looking up > symbols for projects that use more than one major mode? E.g., could > the back-end be a list of functions, rather than just one? I think it's not just a matter of combining several major modes: you need to know where the various files are and how they relate. IOW there needs to be some other logic on top of it and different systems will require different such logic. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 02 12:53:03 2015 Received: (at 19466) by debbugs.gnu.org; 2 Jan 2015 17:53:04 +0000 Received: from localhost ([127.0.0.1]:35271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y76PH-0002TY-8j for submit@debbugs.gnu.org; Fri, 02 Jan 2015 12:53:03 -0500 Received: from mail-wi0-f169.google.com ([209.85.212.169]:55351) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y76PE-0002T7-6h for 19466@debbugs.gnu.org; Fri, 02 Jan 2015 12:53:00 -0500 Received: by mail-wi0-f169.google.com with SMTP id r20so930186wiv.0 for <19466@debbugs.gnu.org>; Fri, 02 Jan 2015 09:52: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=G9D03l2z/DU1ah5vCEeyXdJFt6IbEzq9r7f65vUfGog=; b=QWk7aP7Il56J0/4imi6g9XZEBO28NOKyfOPOhQzNpxZ01PfePvwRNm8RkZr0y3fAQw OwgL0P/Cl5vMK9HS76EmL9lZGP3bEJpTX7wcP5C5LN0uPi1PFmBw5zN9CHSgOLWLZFtA N0L0KWIhSEjJcumGdkmBBQnaiDZc4pyImWnPNr0NJZmVkVgcdZKgMBQ0lfpFWYnoHudC yITwLIDWgpjNmw9w8BLbNpEpHapfKUAc2cgGADiZP2yS2pw3HpE+nHOnbsaC46aZTrWA 0JAa0taQZIIbWoGgEU6Q/e+LeM0uN5bZIq76Vk8RjzJcgETq3BcldZBsXhWGAa6F3jJR cAxQ== X-Received: by 10.181.29.198 with SMTP id jy6mr7550557wid.0.1420221179525; Fri, 02 Jan 2015 09:52:59 -0800 (PST) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id et4sm65360866wjd.15.2015.01.02.09.52.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jan 2015 09:52:58 -0800 (PST) Message-ID: <54A6DAF6.5070605@yandex.ru> Date: Fri, 02 Jan 2015 19:52:54 +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 To: Stefan Monnier , Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.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-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org 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:44 AM, Stefan Monnier wrote: > I think it's not just a matter of combining several major modes: you > need to know where the various files are and how they relate. IOW there > needs to be some other logic on top of it and different systems will > require different such logic. Or, to put it another way: if someone is editing ELPA code in its own repo and presses `C-u M-.', I'm not sure it's reasonable to include all C functions and macros in the list of suggested identifiers. After all, they are writing Elisp, not C. One way to deal with this would be to add a minor mode, one that people could enable on by-file or by-project basis (say, in Emacs's .dir-locals.el). This xref-emacs-sources-mode would merge identifiers from both the Elisp and Etags backends, and try to merge the search results for different search actions as well. It will return duplicate results, though. And filtering them out will be non-trivial. For instance, if find-func and src/TAGS are merge, jumping to `car' would yield one xref-elisp-location, and one xref-file-location. How do you compare them, if one has fields with values "car" and "src/data.c", and the other "DEFUN ("car", Fcar," and "/full/p/t/emacs/src/data.c"? Do we really want to include lisp/TAGS? It has both pros and cons. Pros: we can jump to all functions, even non-autoloaded ones in all packages. Cons: we do see all the functions, even ones we don't care about (their packages aren't loaded). Based on my positive experience with find-func, maybe 98% of the time the user won't really need them. And duplicates, a lot more than with src/TAGS. So someone should really consider if we ever need find-func and lisp/TAGS used together. Because if Eli only wants to use tag files when working on Emacs, the respective minor mode looks a lot simpler: (defvar xref-etags-mode--save nil) (define-minor-mode xref-etags-mode "Toggle using only the tag files for navigation." :lighter "" (if xref-etags-mode (progn (setq xref-etags-mode--save (cons xref-find-function xref-identifier-completion-table-function)) (kill-local-variable 'xref-find-function) (kill-local-variable 'xref-identifier-completion-table-function)) (setq-local xref-find-function (car xref-etags-mode--save)) (setq-local xref-identifier-completion-table-function (cdr xref-etags-mode--save)))) Add it to find-file-hook, maybe predicated on buffer-file-name. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 04 15:10:15 2015 Received: (at 19466) by debbugs.gnu.org; 4 Jan 2015 20:10:15 +0000 Received: from localhost ([127.0.0.1]:36616 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y7rV8-00077C-Tg for submit@debbugs.gnu.org; Sun, 04 Jan 2015 15:10:15 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:43136) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y7rV7-000774-I2 for 19466@debbugs.gnu.org; Sun, 04 Jan 2015 15:10:13 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8PAOwQflRFpY0B/2dsb2JhbABbgweDYIVawjuCYgQCAoEkFwEBAQEBAXyEAwEBAwFWIwULCw4mEhQYDSSISgnWWQEBAQEBAQQBAQEBHpBvB4RIBYsBpC6BeIQZIYJ3AQEB X-IPAS-Result: Aj8PAOwQflRFpY0B/2dsb2JhbABbgweDYIVawjuCYgQCAoEkFwEBAQEBAXyEAwEBAwFWIwULCw4mEhQYDSSISgnWWQEBAQEBAQQBAQEBHpBvB4RIBYsBpC6BeIQZIYJ3AQEB X-IronPort-AV: E=Sophos;i="5.07,502,1413259200"; d="scan'208";a="106532954" 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; 04 Jan 2015 15:10:13 -0500 Received: by ceviche.home (Postfix, from userid 20848) id DC68666100; Sun, 4 Jan 2015 15:10:12 -0500 (EST) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions Message-ID: References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> Date: Sun, 04 Jan 2015 15:10:12 -0500 In-Reply-To: <54A6DAF6.5070605@yandex.ru> (Dmitry Gutov's message of "Fri, 02 Jan 2015 19:52:54 +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-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Eli Zaretskii 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 (/) > So someone should really consider if we ever need find-func and lisp/TAGS > used together. Because if Eli only wants to use tag files when working on > Emacs, the respective minor mode looks a lot simpler: Right, I think we should definitely start with just a way to use TAGS *instead* of the major mode's own system. We can consider later on adding some other system to merge TAGS info with other info, but ... one step at a time, since we may end up not needing the next step. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 04 15:29:50 2015 Received: (at 19466) by debbugs.gnu.org; 4 Jan 2015 20:29:50 +0000 Received: from localhost ([127.0.0.1]:36630 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y7ro5-0007ae-SC for submit@debbugs.gnu.org; Sun, 04 Jan 2015 15:29:50 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:55397) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y7ro3-0007aU-93 for 19466@debbugs.gnu.org; Sun, 04 Jan 2015 15:29:48 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NHO00E006197I00@a-mtaout21.012.net.il> for 19466@debbugs.gnu.org; Sun, 04 Jan 2015 22:29:45 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHO00E2O69K7V00@a-mtaout21.012.net.il>; Sun, 04 Jan 2015 22:29:45 +0200 (IST) Date: Sun, 04 Jan 2015 22:29:48 +0200 From: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <831tna9tmr.fsf@gnu.org> References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, dgutov@yandex.ru 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: 1.0 (+) > From: Stefan Monnier > Cc: Eli Zaretskii , 19466@debbugs.gnu.org > Date: Sun, 04 Jan 2015 15:10:12 -0500 > > Right, I think we should definitely start with just a way to use TAGS > *instead* of the major mode's own system. > > We can consider later on adding some other system to merge TAGS info > with other info, but ... one step at a time, since we may end up not > needing the next step. Btw, I think I've found another "issue" with xref-find-def: it uses the TAGS table information without any tolerance. So if you have a TAGS file that is slightly outdated, you are put on the wrong line. By contrast, etags.el had special code that would look around the position specified by TAGS, see etags-goto-tag-location. And one more thing: after invoking M-. and typing the function name, then typing '.' to get the first candidate displayed, if I switch to the window where that candidate is displayed, the window switches buffers on me, so that the function I wanted to look at disappears. What am I doing wrong this time? From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 04 17:14:36 2015 Received: (at 19466) by debbugs.gnu.org; 4 Jan 2015 22:14:36 +0000 Received: from localhost ([127.0.0.1]:36720 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y7tRT-0001oK-Ix for submit@debbugs.gnu.org; Sun, 04 Jan 2015 17:14:35 -0500 Received: from mail-la0-f42.google.com ([209.85.215.42]:57412) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y7tRR-0001oC-Mp for 19466@debbugs.gnu.org; Sun, 04 Jan 2015 17:14:34 -0500 Received: by mail-la0-f42.google.com with SMTP id gd6so17691641lab.1 for <19466@debbugs.gnu.org>; Sun, 04 Jan 2015 14:14:33 -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=PS8bBOBi0O/z2ctYUcMQYsWLB8rQW8+mNZmiLvnO8Wg=; b=WBiyTTvN+EkCHgD4yQb1YdkqYGtKiDCEOi7caClUFnUYHLa6V58BxwmaIOtIyDJSVT wGJXr4ykVsSvQdjqRE2kLfVKi0Xk9Q7RXUSntq9UCW+dWVw68hYGN4YZy3S2UHs2oQ9a YGfGaUqmcbHgCiuGZs5DeMwt+JK+6yEh0cVrvXjiFDhTtBKtLZ1xvfyjd4+G259o08Yn fMBis9yau0N0VkQZQIiiT/L6fVry7rG0vGBadaru1TW84+HWYBGI/w8YPdho3XxoIRMv dO4inTcubxDCpd52sSz8rSAr6s3DYgMBQjGBoGhD1wfk+65aWgS37QTmfoezLFnEcMnS wEJQ== X-Received: by 10.112.205.231 with SMTP id lj7mr11379933lbc.86.1420409672986; Sun, 04 Jan 2015 14:14:32 -0800 (PST) Received: from [192.168.1.3] ([178.252.98.87]) by mx.google.com with ESMTPSA id q9sm13573231lbo.29.2015.01.04.14.14.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jan 2015 14:14:32 -0800 (PST) Message-ID: <54A9BB45.5020407@yandex.ru> Date: Mon, 05 Jan 2015 01:14:29 +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 To: Stefan Monnier Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Eli Zaretskii 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:10 PM, Stefan Monnier wrote: > Right, I think we should definitely start with just a way to use TAGS > *instead* of the major mode's own system. I've posted a tiny minor mode in the previous message that does this. Does it work well for everyone? We probably don't even need a minor mode. A function might suffice: (defun xref-reset-backend () (kill-local-variable 'xref-find-function) (kill-local-variable 'xref-identifier-completion-table-function)) (defun elisp-maybe-reset-xref () (when (and buffer-file-name (string-prefix-p source-directory buffer-file-name)) (xref-reset-backend))) (add-hook 'emacs-lisp-mode-hook 'elisp-maybe-reset-xref) But please, someone else should make the choice: I rarely ever use tag files, and never with Emacs Lisp. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 04 18:14:29 2015 Received: (at 19466) by debbugs.gnu.org; 4 Jan 2015 23:14:29 +0000 Received: from localhost ([127.0.0.1]:36760 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y7uNR-0003Iv-3T for submit@debbugs.gnu.org; Sun, 04 Jan 2015 18:14:29 -0500 Received: from mail-la0-f44.google.com ([209.85.215.44]:37862) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y7uNO-0003In-VF for 19466@debbugs.gnu.org; Sun, 04 Jan 2015 18:14:27 -0500 Received: by mail-la0-f44.google.com with SMTP id gd6so17535111lab.31 for <19466@debbugs.gnu.org>; Sun, 04 Jan 2015 15:14:26 -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=Urx8iY7tr2vjvbVwc+c4eC6dKJ2X87kPy9oYyzo9xh4=; b=cGQKznI2ze7boNzOHcVj+7efAt3eEHniFTlAEIULNwjY3rKmwZLqhev/YlfIGa01vQ tfae0JbbqSgHZ1BCUnCfwziYbsBZTDOFlWZt3JRDfFgeEpea9pzQdEoZJqd5lU01Xo3b 5n0NC9+MW0yoxyoXtzfzT9G3BrR1CDttzgLzEINB8QMrnw3ypbxSieMOILFl5oemKYDc f4rKHlefx2LDVI0/Oh/YL94P+NJ50gdLz+Z2AJIJQSe0JkGtvLjXh15bLfSINyiAK7K3 4kQ38GvYQ/NCF+B8hZmvEIbLG6HLQPLnvaqcQNhp67frRtuM5ENWAkVpbDmBZpeA65Rr s3Dw== X-Received: by 10.152.36.37 with SMTP id n5mr86564665laj.27.1420413266146; Sun, 04 Jan 2015 15:14:26 -0800 (PST) Received: from [192.168.1.3] ([178.252.98.87]) by mx.google.com with ESMTPSA id zs7sm14282172lbb.18.2015.01.04.15.14.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jan 2015 15:14:25 -0800 (PST) Message-ID: <54A9C94F.8040701@yandex.ru> Date: Mon, 05 Jan 2015 02:14:23 +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 To: Eli Zaretskii , Stefan Monnier Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> In-Reply-To: <831tna9tmr.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Helmut Eller 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:29 PM, Eli Zaretskii wrote: > Btw, I think I've found another "issue" with xref-find-def: it uses > the TAGS table information without any tolerance. So if you have a > TAGS file that is slightly outdated, you are put on the wrong line. > By contrast, etags.el had special code that would look around the > position specified by TAGS, see etags-goto-tag-location. I see. Sounds like a good reason to add a yet-another xref-location subclass. > And one more thing: after invoking M-. and typing the function name, > then typing '.' to get the first candidate displayed, if I switch to > the window where that candidate is displayed, the window switches > buffers on me, so that the function I wanted to look at disappears. > What am I doing wrong this time? You didn't press RET after `.'? :) Currently, pre-command-hook always restores window configuration to the one before the buffer with the definitions of the current line's xref was displayed. I can see how this can be surprising for a new user, though. In that respect, a `quit-window' approach is better. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 04 22:36:30 2015 Received: (at 19466) by debbugs.gnu.org; 5 Jan 2015 03:36:30 +0000 Received: from localhost ([127.0.0.1]:36835 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y7ySz-0002XR-Sn for submit@debbugs.gnu.org; Sun, 04 Jan 2015 22:36:30 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:63541) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y7ySw-0002XF-Nv for 19466@debbugs.gnu.org; Sun, 04 Jan 2015 22:36:27 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NHO00500PQNZA00@a-mtaout23.012.net.il> for 19466@debbugs.gnu.org; Mon, 05 Jan 2015 05:36:25 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHO005E0Q0OTU80@a-mtaout23.012.net.il>; Mon, 05 Jan 2015 05:36:25 +0200 (IST) Date: Mon, 05 Jan 2015 05:36:29 +0200 From: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions In-reply-to: <54A9C94F.8040701@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Gutov Message-id: <83vbkl99vm.fsf@gnu.org> References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, eller.helmut@gmail.com, monnier@iro.umontreal.ca 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: 1.0 (+) > Date: Mon, 05 Jan 2015 02:14:23 +0300 > From: Dmitry Gutov > CC: 19466@debbugs.gnu.org, Helmut Eller > > > And one more thing: after invoking M-. and typing the function name, > > then typing '.' to get the first candidate displayed, if I switch to > > the window where that candidate is displayed, the window switches > > buffers on me, so that the function I wanted to look at disappears. > > What am I doing wrong this time? > > You didn't press RET after `.'? :) So there's no way of browsing the definition and keeping the list of candidates available, except by scrolling the definition from another window? That's indeed surprising. > Currently, pre-command-hook always restores window configuration to the > one before the buffer with the definitions of the current line's xref > was displayed. Why is that insistence on restoring the window configuration useful? Emacs users should be already used to the fact that Emacs pops buffers in windows all the time, so IMO there's nothing terribly wrong in leaving the window configuration changed. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 05 01:11:47 2015 Received: (at 19466) by debbugs.gnu.org; 5 Jan 2015 06:11:47 +0000 Received: from localhost ([127.0.0.1]:36890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y80tG-0006P5-S4 for submit@debbugs.gnu.org; Mon, 05 Jan 2015 01:11:47 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:36910) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y80tF-0006Ot-7e for 19466@debbugs.gnu.org; Mon, 05 Jan 2015 01:11:45 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8PAOwQflRFpY0B/2dsb2JhbABbgweDYIVawjuCYgQCAoEkFwEBAQEBAXyEAwEBAwFWIwULCzQSFBgNJIhKCdZZAQEBAQEBBAEBAQEekChHB4RIBYsBpC6BeIQZIYJ3AQEB X-IPAS-Result: Aj8PAOwQflRFpY0B/2dsb2JhbABbgweDYIVawjuCYgQCAoEkFwEBAQEBAXyEAwEBAwFWIwULCzQSFBgNJIhKCdZZAQEBAQEBBAEBAQEekChHB4RIBYsBpC6BeIQZIYJ3AQEB X-IronPort-AV: E=Sophos;i="5.07,502,1413259200"; d="scan'208";a="106608585" 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; 05 Jan 2015 01:11:42 -0500 Received: by pastel.home (Postfix, from userid 20848) id 843A42517; Mon, 5 Jan 2015 01:11:37 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions Message-ID: References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> Date: Mon, 05 Jan 2015 01:11:37 -0500 In-Reply-To: <83vbkl99vm.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 05 Jan 2015 05:36:29 +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-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, eller.helmut@gmail.com, Dmitry Gutov 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 (/) >> Currently, pre-command-hook always restores window configuration to the >> one before the buffer with the definitions of the current line's xref >> was displayed. > Why is that insistence on restoring the window configuration useful? > Emacs users should be already used to the fact that Emacs pops buffers > in windows all the time, so IMO there's nothing terribly wrong in > leaving the window configuration changed. Agreed. In my book, any use of window-configuration restoration is suspicious (too often used to hide an ugly "switch-to-buffer instead of set-buffer", I guess). Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 15 22:38:04 2015 Received: (at 19466) by debbugs.gnu.org; 16 Jan 2015 03:38:04 +0000 Received: from localhost ([127.0.0.1]:58330 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YBxjX-0004WE-Dw for submit@debbugs.gnu.org; Thu, 15 Jan 2015 22:38:03 -0500 Received: from mail-lb0-f180.google.com ([209.85.217.180]:34199) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YBxjS-0004Vj-PN for 19466@debbugs.gnu.org; Thu, 15 Jan 2015 22:37:59 -0500 Received: by mail-lb0-f180.google.com with SMTP id f15so7008580lbj.11 for <19466@debbugs.gnu.org>; Thu, 15 Jan 2015 19:37:53 -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=eQFUMwCw5BIDjDXJEwSZVMEKlqLInFDj2q/OhrhGY4k=; b=FxgrOmF5DuCTruj2YN1F74rll6Utgy9660ewdNCM7LqTTclPAIzs14VZuRjEvir0Mw IsJUbuSaKoPGL0/ZBpN5I76TWFS2//C+C9H9SF0IPeoVpp/kgVMZe0zy/NSzD3v4sZSP AptFk9F9xl5XMIB8Tpa/RVigOutnNQXf2Ht5yjaeAoUE8bjs+EyrIk7VGKynXft/i/kM zTgud0GiqW6mzQbgonID6PhaRspCSOfZHO7xgVJfPIS2iYB/nun2COu8NaOOX2rPM6Jh ykPssN2LZqRCi80tefvdt2SkZ/IEV83v0gGbO3xBW4pUOxtqnm9rzJdKV29Bg8Giw1k2 Pocw== X-Received: by 10.112.183.197 with SMTP id eo5mr13189291lbc.81.1421379472951; Thu, 15 Jan 2015 19:37:52 -0800 (PST) Received: from [192.168.1.3] ([178.252.98.87]) by mx.google.com with ESMTPSA id lh6sm1084543lab.49.2015.01.15.19.37.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Jan 2015 19:37:52 -0800 (PST) Message-ID: <54B8878A.4050506@yandex.ru> Date: Fri, 16 Jan 2015 06:37:46 +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 To: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> In-Reply-To: <83vbkl99vm.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Helmut Eller , monnier@iro.umontreal.ca, martin rudalics 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 06:36 AM, Eli Zaretskii wrote: > So there's no way of browsing the definition and keeping the list of > candidates available, except by scrolling the definition from another > window? That's indeed surprising. Right, maybe the quit-window approach would be less surprising overall. The alternative implementation was pushed to scratch/xref, and it's waiting for Martin's comments (bug#19468). > Why is that insistence on restoring the window configuration useful? > Emacs users should be already used to the fact that Emacs pops buffers > in windows all the time, so IMO there's nothing terribly wrong in > leaving the window configuration changed. Basically, I want the user to be able to easily return to the window configuration that was before xref-find-definitions was called. Or, if they picked a definition, make the process of selecting not leave its traces on the window configuration. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 16 02:48:25 2015 Received: (at 19466) by debbugs.gnu.org; 16 Jan 2015 07:48:25 +0000 Received: from localhost ([127.0.0.1]:58386 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YC1do-00024q-N7 for submit@debbugs.gnu.org; Fri, 16 Jan 2015 02:48:25 -0500 Received: from mout.gmx.net ([212.227.15.19]:54589) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YC1dm-00024a-Ql for 19466@debbugs.gnu.org; Fri, 16 Jan 2015 02:48:23 -0500 Received: from [91.113.6.66] ([91.113.6.66]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LzskF-1Xhtgb08Jv-014zQU; Fri, 16 Jan 2015 08:48:06 +0100 Message-ID: <54B8C22B.3080200@gmx.at> Date: Fri, 16 Jan 2015 08:47:55 +0100 From: martin rudalics MIME-Version: 1.0 To: Dmitry Gutov , Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> In-Reply-To: <54B8878A.4050506@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:4bHeP7QPrUUcvFPuZp+Np1+D30K62bw63pf+3isxiX/DvoKbgAV yaWvwlzkf8gzJfRcufj829PDpoHBhsPmA4dHnWvgAherVTIfEbC47UfTexTZri04zwqfJgk sLzhsE6C4cZCcnO5yJItNsskbeAAB9LRvdtbkjBGnesaNy1yntWPiwTtSUqpDPW9aE12CvZ UW7eHomxBRFQiRGLs2XJw== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Helmut Eller , monnier@iro.umontreal.ca 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 (/) > The alternative implementation was pushed to scratch/xref, and it's waiting for Martin's comments (bug#19468). Sorry, I didn't have time yet to give it a through testing. Anyway, Eli's concern "... if I switch to the window where that candidate is displayed, the window switches buffers on me ..." is IMHO more serious than your "I want the user to be able to easily return to the window configuration that was before xref-find-definitions was called." so I think you should push the `quit-window' based solution to trunk (which, from the few testing I gave it, seems to handle this case well). One thing that has annoyed me ever since is the buffers that pile up while browsing tags. I always dreamt of a good heuristic to get rid of them. Maybe you could try making provisions like (1) this buffer is killable because it has been probably visited exclusively by and only accidentally during xrefing, and (2) have the command that quits the *xref* buffer optionally kill the buffers marked in (1). A heuristic for (1) could go as follows: The buffer was created during xrefing, the window was never selected while it showed that buffer and either its buffer was "immediately" replaced by another xrefed one or `xref--quit' was invoked. You might also consider setting `other-window-scroll-buffer' to the window used by `xref-show-location-at-point'. martin, who'd prefer (user-error "No reference at point") From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 16 04:00:49 2015 Received: (at 19466) by debbugs.gnu.org; 16 Jan 2015 09:00:50 +0000 Received: from localhost ([127.0.0.1]:58435 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YC2lt-0003oV-H1 for submit@debbugs.gnu.org; Fri, 16 Jan 2015 04:00:49 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:49210) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YC2lq-0003oE-Sy for 19466@debbugs.gnu.org; Fri, 16 Jan 2015 04:00:48 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NI900F00I2ARP00@a-mtaout20.012.net.il> for 19466@debbugs.gnu.org; Fri, 16 Jan 2015 11:00:40 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NI900FHKID3MD70@a-mtaout20.012.net.il>; Fri, 16 Jan 2015 11:00:40 +0200 (IST) Date: Fri, 16 Jan 2015 11:00:56 +0200 From: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions In-reply-to: <54B8878A.4050506@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Gutov Message-id: <83bnlz2j7b.fsf@gnu.org> References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, eller.helmut@gmail.com, monnier@iro.umontreal.ca, rudalics@gmx.at 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: 1.0 (+) > Date: Fri, 16 Jan 2015 06:37:46 +0300 > From: Dmitry Gutov > CC: monnier@iro.umontreal.ca, 19466@debbugs.gnu.org, > Helmut Eller , > martin rudalics > > On 01/05/2015 06:36 AM, Eli Zaretskii wrote: > > > So there's no way of browsing the definition and keeping the list of > > candidates available, except by scrolling the definition from another > > window? That's indeed surprising. > > Right, maybe the quit-window approach would be less surprising overall. > > The alternative implementation was pushed to scratch/xref, and it's > waiting for Martin's comments (bug#19468). Thanks. > > Why is that insistence on restoring the window configuration useful? > > Emacs users should be already used to the fact that Emacs pops buffers > > in windows all the time, so IMO there's nothing terribly wrong in > > leaving the window configuration changed. > > Basically, I want the user to be able to easily return to the window > configuration that was before xref-find-definitions was called. Or, if > they picked a definition, make the process of selecting not leave its > traces on the window configuration. I understand your desire. I just think you are fighting a losing battle, and in the process surprise the users with less than friendly behavior. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 16 04:04:46 2015 Received: (at 19466) by debbugs.gnu.org; 16 Jan 2015 09:04:46 +0000 Received: from localhost ([127.0.0.1]:58439 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YC2pi-0003uh-7A for submit@debbugs.gnu.org; Fri, 16 Jan 2015 04:04:46 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:34049) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YC2pg-0003uW-Bd for 19466@debbugs.gnu.org; Fri, 16 Jan 2015 04:04:45 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NI900100HZ7VP00@a-mtaout21.012.net.il> for 19466@debbugs.gnu.org; Fri, 16 Jan 2015 11:04:37 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NI9001A5IJOQQ70@a-mtaout21.012.net.il>; Fri, 16 Jan 2015 11:04:37 +0200 (IST) Date: Fri, 16 Jan 2015 11:04:53 +0200 From: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions In-reply-to: <54B8C22B.3080200@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83a91j2j0q.fsf@gnu.org> References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, eller.helmut@gmail.com, monnier@iro.umontreal.ca, dgutov@yandex.ru 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: 1.0 (+) > Date: Fri, 16 Jan 2015 08:47:55 +0100 > From: martin rudalics > CC: monnier@iro.umontreal.ca, 19466@debbugs.gnu.org, > Helmut Eller > > One thing that has annoyed me ever since is the buffers that pile up > while browsing tags. I always dreamt of a good heuristic to get rid of > them. This happens to me all the time, but I don't recommend losing any sleep over it. It's very easy to delete the unwanted buffers (e.g., via "C-x C-b"). One does such cleanup anyway, when one finishes working on some issue, right? Emacs copes with many buffers just fine, so I wouldn't invest any significant energy in getting rid of some of them using some heuristics that will certainly misfire at some point. Emacs should only automatically kill buffers that it creates for its temporary jobs, not buffers created by user commands. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 16 04:28:32 2015 Received: (at 19466) by debbugs.gnu.org; 16 Jan 2015 09:28:32 +0000 Received: from localhost ([127.0.0.1]:58476 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YC3Ci-0004Vi-2z for submit@debbugs.gnu.org; Fri, 16 Jan 2015 04:28:32 -0500 Received: from mout.gmx.net ([212.227.15.15]:51489) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YC3Cf-0004VO-16 for 19466@debbugs.gnu.org; Fri, 16 Jan 2015 04:28:29 -0500 Received: from [91.113.6.66] ([91.113.6.66]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MOfcU-1Y9I2e0igw-0069z9; Fri, 16 Jan 2015 10:28:18 +0100 Message-ID: <54B8D9A9.5060407@gmx.at> Date: Fri, 16 Jan 2015 10:28:09 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <83a91j2j0q.fsf@gnu.org> In-Reply-To: <83a91j2j0q.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:jy3mOuzicn5U/77DjlgOkFHKufbZxM9VT1GwO99w8MjUiEIVSSt EcqKcqu9w3d4BxEfBvablr+tLTeGivvO1KIT0oiCtvtu2xciMjutEflh7mvgXwD+e1qcbem zUqT8Nnlv4OZduII1X/8iOlO1gNJoPdeuB46M0fnUBUCEoOdEtlMB5Z6PRkU4fwxTLffwY2 8NTsLYxOY3ih+/n0vrHKg== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, eller.helmut@gmail.com, monnier@iro.umontreal.ca, dgutov@yandex.ru 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 (/) > This happens to me all the time, but I don't recommend losing any > sleep over it. It's very easy to delete the unwanted buffers (e.g., > via "C-x C-b"). One does such cleanup anyway, when one finishes > working on some issue, right? Till then they will show up, for example, via `previous-buffer'. > Emacs copes with many buffers just fine, so I wouldn't invest any > significant energy in getting rid of some of them using some > heuristics that will certainly misfire at some point. Emacs should > only automatically kill buffers that it creates for its temporary > jobs, not buffers created by user commands. It wouldn't kill them automatically but only optionally, via a special command or a prefix. Less heuristic than `clean-buffer-list' at least. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 18 22:31:14 2015 Received: (at 19466) by debbugs.gnu.org; 19 Jan 2015 03:31:15 +0000 Received: from localhost ([127.0.0.1]:60903 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YD33a-0004CT-Am for submit@debbugs.gnu.org; Sun, 18 Jan 2015 22:31:14 -0500 Received: from mail-wi0-f181.google.com ([209.85.212.181]:41562) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YD33X-0004CF-KO for 19466@debbugs.gnu.org; Sun, 18 Jan 2015 22:31:12 -0500 Received: by mail-wi0-f181.google.com with SMTP id fb4so1146763wid.2 for <19466@debbugs.gnu.org>; Sun, 18 Jan 2015 19:31:06 -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=NQthY9QspfDDptAvSx8eoRRC20fduBidBUSVZX/JoV0=; b=K3V00BvUryu7squFryUGPs4xQLMBjUy++jMQTeVvKuIBPssBuVqBz7oclZ/kiVGv6e Ljvb1pO3o4Mc7a+3SrPsnyscMrxqyHxH+OZlpfafmAjrMoy62IYQSVrs2c0N4Ren7s20 cPTPWqOtiJRwG4MfUFmJO6Xo99djkXxHexTPptWogWE8sDEFogLtVlznZ1krsRFZoc26 nroKFxl4wdEJO+gFQ0YAmYZjA7F30nTnqLYHG6wb/OH48OhGTmn8/JOhnoPDJdlOnGMw T9GN8XfD9I7WrNlJSGr/tmRfOfRF4o0yLoO5Oyuhit+k8NYIpoGZSEFqcaj0IYYJ0DJu +AYQ== X-Received: by 10.194.19.73 with SMTP id c9mr38110094wje.124.1421638266025; Sun, 18 Jan 2015 19:31:06 -0800 (PST) Received: from [192.168.1.3] ([82.102.93.54]) by mx.google.com with ESMTPSA id o2sm12536549wiy.11.2015.01.18.19.31.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Jan 2015 19:31:05 -0800 (PST) Message-ID: <54BC7A77.5020307@yandex.ru> Date: Mon, 19 Jan 2015 05:31:03 +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 To: martin rudalics , Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> In-Reply-To: <54B8C22B.3080200@gmx.at> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Helmut Eller 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/16/2015 09:47 AM, martin rudalics wrote: > so I think you should push the `quit-window' based solution to trunk > (which, from the few testing I gave it, seems to handle this case well). Pushed. I'd really like you to look at the implementation, though. > One thing that has annoyed me ever since is the buffers that pile up > while browsing tags. I always dreamt of a good heuristic to get rid of I thought of that problem too, but it seems less important than willy-nilly changing the window configuration, hence the currently discussed attempt to alleviate it. > them. Maybe you could try making provisions like > > (1) this buffer is killable because it has been probably visited > exclusively by and only accidentally during xrefing, and > > (2) have the command that quits the *xref* buffer optionally kill the > buffers marked in (1). `xref--quit' could definitely be used for it. > A heuristic for (1) could go as follows: > > The buffer was created during xrefing, the window was never selected > while it showed that buffer and either its buffer was "immediately" > replaced by another xrefed one or `xref--quit' was invoked. One question is, how will we know that if was never selected? Use a window-configuration-change-hook? Do we keep the newly added value there indefinitely, or when will `remove-hook' be called if the user never presses `q' in the xref buffer? Overall, solving both problems would be easier if xref used a more restricting interface which would never allow to switch to the temporarily displayed buffers until the user made their choice (but sure, they could scroll the other window). Maybe with `Electric-command-loop'. > You might also consider setting `other-window-scroll-buffer' to the > window used by `xref-show-location-at-point'. > > martin, who'd prefer (user-error "No reference at point") Done. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 19 03:28:57 2015 Received: (at 19466) by debbugs.gnu.org; 19 Jan 2015 08:28:57 +0000 Received: from localhost ([127.0.0.1]:60957 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YD7hh-0003Sv-5l for submit@debbugs.gnu.org; Mon, 19 Jan 2015 03:28:57 -0500 Received: from mout.gmx.net ([212.227.15.15]:52557) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YD7he-0003Se-90 for 19466@debbugs.gnu.org; Mon, 19 Jan 2015 03:28:55 -0500 Received: from [88.117.118.57] ([88.117.118.57]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Ldq9D-1XVqqx3RUB-00j2vV; Mon, 19 Jan 2015 09:28:40 +0100 Message-ID: <54BCC033.2010104@gmx.at> Date: Mon, 19 Jan 2015 09:28:35 +0100 From: martin rudalics MIME-Version: 1.0 To: Dmitry Gutov , Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> In-Reply-To: <54BC7A77.5020307@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:aNIZ5fj7/MOl9SNzKiGoUIy8USZHTOYjkgGHz3WLf24wQlLDBUk klqmKDiCmNAddaTZMOs64gBnVF2lYXEhyS7gzrhRX0eeUxloNjIzm5gqscMqqSuhdUwiR09 iFuwt+h6hNwd/VWASZ/CcPIXMO6kh08s4ivbB4CdZLVVnMp2Qhxhez++mdSYfjbJRlAVP/J 5jkoHNvsMLXV3J3LHOFQg== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Helmut Eller 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 (/) > Pushed. I'd really like you to look at the implementation, though. I didn't see any flaws in it. In any case we'll find out pretty soon if there are. >> (2) have the command that quits the *xref* buffer optionally kill the >> buffers marked in (1). > > `xref--quit' could definitely be used for it. That's what I thought. Note in this context that some people might have globally bound `quit-window' to some key other than 'q' and might want to quit *xref* with that. It's obviously up to them whether `quit-window' does something additional in that context but it certainly should do something "intuitively useful". For example, with a prefix argument it will kill the *xref* buffer and any hooks set up by xrefing should get removed. > One question is, how will we know that if was never selected? Via `buffer-list-update-hook'? That is, if a buffer (1) was created by xref but (2) never got "promoted" by `buffer-list-update-hook', then such a buffer is eligible for being killed quietly. > Use a window-configuration-change-hook? Do we keep the newly added > value there indefinitely, or when will `remove-hook' be called if the > user never presses `q' in the xref buffer? I'd say as soon as the *xref* buffer stops being displayed. If a user does that and a buffer gets killed by the way and the user later on decides to redisplay that buffer via xrefing, she has to pay the price of re-reading that buffer from file. That's why this feature should be optional. > Overall, solving both problems would be easier if xref used a more > restricting interface which would never allow to switch to the > temporarily displayed buffers until the user made their choice (but > sure, they could scroll the other window). > > Maybe with `Electric-command-loop'. I profoundly dislike modal windows. We should never restrict displaying or perusing the *xref* buffer in any way. Anything hardcoded here will get you into troubles with users and inhibit developers to improve the interface. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 19 08:32:42 2015 Received: (at 19466) by debbugs.gnu.org; 19 Jan 2015 13:32:42 +0000 Received: from localhost ([127.0.0.1]:32825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDCRe-0005Td-Av for submit@debbugs.gnu.org; Mon, 19 Jan 2015 08:32:42 -0500 Received: from mail-wi0-f175.google.com ([209.85.212.175]:51201) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDCRb-0005TQ-LL for 19466@debbugs.gnu.org; Mon, 19 Jan 2015 08:32:40 -0500 Received: by mail-wi0-f175.google.com with SMTP id fb4so9187757wid.2 for <19466@debbugs.gnu.org>; Mon, 19 Jan 2015 05:32:34 -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=CRXAWEodL7oNyuerr4hCZHop9oRLMQe2NkKv26W0mTU=; b=wLPWFkqdqWbcUbkv7WdyQ3Ke/Pd2IPxJsRneKsYm2wXXjH2Hd+vyCGtp+70bXjLVXb 268bF3us9DfPR4XfItSPntV1+ltLr/CezocGXCXsTT5jMoNzHWSQJRV9avNaRZFw2mGK d06wcK46nxleFVpw+OqKO0Zh3i6cXx6sa05/hQcr+g75gmgOTiRQLQ075JkVo0TX1Lj6 EsI7JicRp7qDB2+7I2sOjUa2X3rTg3aV1XDqVLmgcUFZQ0Ki1DjocyJ3m+VYJEkXf7YX fmMX9Idnl16MN06G/X2uTpFX+scPE5wE9n0SZaFaZ+TtWKHZRvriyj8AtK1sIFppJjzp Od8A== X-Received: by 10.194.189.138 with SMTP id gi10mr3050654wjc.86.1421674353555; Mon, 19 Jan 2015 05:32:33 -0800 (PST) Received: from [192.168.1.3] ([82.102.93.54]) by mx.google.com with ESMTPSA id be2sm17292650wjb.38.2015.01.19.05.32.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jan 2015 05:32:32 -0800 (PST) Message-ID: <54BD076E.6090707@yandex.ru> Date: Mon, 19 Jan 2015 15:32:30 +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 To: martin rudalics , Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> In-Reply-To: <54BCC033.2010104@gmx.at> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Helmut Eller 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/19/2015 10:28 AM, martin rudalics wrote: > I didn't see any flaws in it. In any case we'll find out pretty soon if > there are. To me, xref--save-to-history looks like it's exploiting implementation details that could change in the future. Possibly because I haven't found good documentation for the quit-restore values. > That's what I thought. Note in this context that some people might have > globally bound `quit-window' to some key other than 'q' and might want > to quit *xref* with that. You obviously mean [remap quit-window]. Forgot about that. > It's obviously up to them whether > `quit-window' does something additional in that context but it certainly > should do something "intuitively useful". For example, with a prefix > argument it will kill the *xref* buffer and any hooks set up by xrefing > should get removed. I wouldn't say "prefix argument means kill" is inherently intuitive, but sure, a remapped command should mimic behavior of the original command as close as possible (I just wasn't aware of it). > > One question is, how will we know that if was never selected? > > Via `buffer-list-update-hook'? That is, if a buffer (1) was created by > xref but (2) never got "promoted" by `buffer-list-update-hook', then > such a buffer is eligible for being killed quietly. Sounds good. And as soon a it's run, it can change some local variable, and then the function will remove itself from the hook. > > Use a window-configuration-change-hook? Do we keep the newly added > > value there indefinitely, or when will `remove-hook' be called if the > > user never presses `q' in the xref buffer? > > I'd say as soon as the *xref* buffer stops being displayed. Actually, with the above scheme there's no real need to call `remove-hook' from elsewhere. And if the xref buffer was buried sometime, then switched to again, and a buffer in question still wasn't selected in the meantime? Let it be killed, no great loss. > If a user > does that and a buffer gets killed by the way and the user later on > decides to redisplay that buffer via xrefing, she has to pay the price > of re-reading that buffer from file. That's why this feature should be > optional. Does what? I think it might be fine to always delete the "temporary" buffers if `xref--quit' was called with a prefix, as an initial implementation. After all, if the user doesn't mind having extra file buffers around, they'd also probably just bury xref. > I profoundly dislike modal windows. We should never restrict displaying > or perusing the *xref* buffer in any way. Anything hardcoded here will > get you into troubles with users and inhibit developers to improve the > interface. I wouldn't necessarily agree (the keys and allowed commands could be customizable), but ok, let's not go that way. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 19 12:42:20 2015 Received: (at 19466) by debbugs.gnu.org; 19 Jan 2015 17:42:21 +0000 Received: from localhost ([127.0.0.1]:49831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDGLE-0000ll-GH for submit@debbugs.gnu.org; Mon, 19 Jan 2015 12:42:20 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:32942) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDGLA-0000lR-2z for 19466@debbugs.gnu.org; Mon, 19 Jan 2015 12:42:17 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NIF00100QD4OC00@a-mtaout20.012.net.il> for 19466@debbugs.gnu.org; Mon, 19 Jan 2015 19:42:08 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIF0015SQI8HJ20@a-mtaout20.012.net.il>; Mon, 19 Jan 2015 19:42:08 +0200 (IST) Date: Mon, 19 Jan 2015 19:41:59 +0200 From: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions In-reply-to: <54BCC033.2010104@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83oapuy8ew.fsf@gnu.org> References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, eller.helmut@gmail.com, dgutov@yandex.ru 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: 1.0 (+) > Date: Mon, 19 Jan 2015 09:28:35 +0100 > From: martin rudalics > CC: 19466@debbugs.gnu.org, Helmut Eller > > > Pushed. I'd really like you to look at the implementation, though. > > I didn't see any flaws in it. In any case we'll find out pretty soon if > there are. One issue I still see is that if TAGS is slightly outdated, point is positioned not on the first line of a function/macro/struct, but on the line recorded in TAGS. I hope this will be fixed soon. Another minor issue is with the help-echo in the xref buffer: it says "mouse-2: display, mouse-1: navigate", which is confusing because it's unclear what exactly each of these 2 means. How about saying explicitly "show in this window" and "show in another window" (assuming this is what that does)? Finally, I still think we need to allow searching symbols not only in the current buffer's programming language, at least with the tags back-end. Without that, we cannot deprecate find-tag. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 19 21:54:14 2015 Received: (at 19466) by debbugs.gnu.org; 20 Jan 2015 02:54:14 +0000 Received: from localhost ([127.0.0.1]:50174 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDOxJ-0005vt-TL for submit@debbugs.gnu.org; Mon, 19 Jan 2015 21:54:14 -0500 Received: from mail-wg0-f49.google.com ([74.125.82.49]:45591) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDOxI-0005ve-Bk for 19466@debbugs.gnu.org; Mon, 19 Jan 2015 21:54:12 -0500 Received: by mail-wg0-f49.google.com with SMTP id l18so9185499wgh.8 for <19466@debbugs.gnu.org>; Mon, 19 Jan 2015 18:54:06 -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=Hp8EEW+hNeeKG/ZDRN8fXl05nBZT/A7T+vk24bHSORI=; b=oqoz8xBBtdwnM/oX6yZS+JxjXd/1i5AeaGQhOCAp1dlHJmIHa8saE+98ibxnAX/zxX vlZ4f9J9HDP6x4sJDH3Y9Cc4IOa6zl1D5Dwd0lgolVN6xnjC1RXVhopA+FF45Ru40KOV RnhzUdf2ZC/ssHzYux84acuG/g1Kf4Mdr15y3J8NlFnRbEY50/gXbxbEo1Bhwqdg5+1r 3t/KDcDmA5bM2B5c+nTMohJkFBtRvcmWch99saBqmd4v7oC9b3eufixosmUUD3HUnSXA 9qs14YaF/QjGJdaV8sOH7DeHBNV0G4XIxZyjcItsasQj+1C6GJSEBnTRFBrST+MGgUFv raSg== X-Received: by 10.194.193.4 with SMTP id hk4mr67199984wjc.38.1421722446495; Mon, 19 Jan 2015 18:54:06 -0800 (PST) Received: from [192.168.1.3] ([82.102.93.54]) by mx.google.com with ESMTPSA id eu8sm1160134wib.21.2015.01.19.18.54.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jan 2015 18:54:05 -0800 (PST) Message-ID: <54BDC34C.5070309@yandex.ru> Date: Tue, 20 Jan 2015 04:54:04 +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 To: Eli Zaretskii , martin rudalics Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> In-Reply-To: <83oapuy8ew.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, eller.helmut@gmail.com 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/19/2015 07:41 PM, Eli Zaretskii wrote: >> Date: Mon, 19 Jan 2015 09:28:35 +0100 >> From: martin rudalics >> CC: 19466@debbugs.gnu.org, Helmut Eller >> >> > Pushed. I'd really like you to look at the implementation, though. >> >> I didn't see any flaws in it. In any case we'll find out pretty soon if >> there are. The above refers to the window configuration-restoring logic. > One issue I still see is that if TAGS is slightly outdated, point is > positioned not on the first line of a function/macro/struct, but on > the line recorded in TAGS. I hope this will be fixed soon. Okay, should work now. Thanks for the reminder. > Another minor issue is with the help-echo in the xref buffer: it says > "mouse-2: display, mouse-1: navigate", which is confusing because it's > unclear what exactly each of these 2 means. How about saying > explicitly "show in this window" and "show in another window" > (assuming this is what that does)? Not exactly. Here "navigate" means bury the xref and other temporary buffers, and then display the reference in the current or other window, or frame it was originally intended to be displayed in (depending on which command was invoked: `xref-find-definitions', `xref-find-definitions-other-window' or `xref-find-definitions-other-frame'). > Finally, I still think we need to allow searching symbols not only in > the current buffer's programming language, at least with the tags > back-end. Without that, we cannot deprecate find-tag. Please refer to the following messages: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19466#32 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19466#41 And for completeness, a third option: define a minor mode that would remap xref-find-* commands to their etags-only variants, which can be trivially implemented by let-binding the two relevant variables to their default values. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 20 03:01:46 2015 Received: (at 19466) by debbugs.gnu.org; 20 Jan 2015 08:01:46 +0000 Received: from localhost ([127.0.0.1]:50227 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDTkv-0007mr-NQ for submit@debbugs.gnu.org; Tue, 20 Jan 2015 03:01:46 -0500 Received: from mout.gmx.net ([212.227.15.19]:52765) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDTkt-0007me-0S for 19466@debbugs.gnu.org; Tue, 20 Jan 2015 03:01:43 -0500 Received: from [91.113.1.213] ([91.113.1.213]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MSMKx-1YJtWn2WGR-00TRWl; Tue, 20 Jan 2015 09:01:34 +0100 Message-ID: <54BE0B5A.6060706@gmx.at> Date: Tue, 20 Jan 2015 09:01:30 +0100 From: martin rudalics MIME-Version: 1.0 To: Dmitry Gutov , Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <54BD076E.6090707@yandex.ru> In-Reply-To: <54BD076E.6090707@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:jQTQR0UN+5SjO8awFfx3aj9FoWuiZuSRhb+mLvtXUIpXmhmOUBh Erl56A3qBSVgmYXA+RoxW9gFPAbRXP1k0vDlq8k8XgXI8RR0trCfpEViQQ7AHTn8KfvdXew rgROBtoTSqY+8yLqJBoJ/2Nczt/N5g/ET2Rw9N7acTEq+UQCH7BZ6478EZ3qk8QKJYkxb+g xlzlAbBjlO6RWnufFrjpw== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Helmut Eller 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 (/) > To me, xref--save-to-history looks like it's exploiting implementation > details that could change in the future. They could change, of course. But since `xref--save-to-history' exploits them, its designers should be able to participate in such changes in the future. > Possibly because I haven't > found good documentation for the quit-restore values. Hmm... They are documented in the Window Parameters section. What do you miss? >> That's what I thought. Note in this context that some people might have >> globally bound `quit-window' to some key other than 'q' and might want >> to quit *xref* with that. > > You obviously mean [remap quit-window]. No. IMO it should be up to the user to remap `quit-window'. > I wouldn't say "prefix argument means kill" is inherently intuitive, Backward compatibility. That's also why `quit-window' has KILL as first argument :-( > but sure, a remapped command should mimic behavior of the original > command as close as possible (I just wasn't aware of it). What I meant was that people might be used to kill the *xref* buffer along with closing its window or use `kill-buffer' directly on *xref*. And that xref should be aware of that and act accordingly, for example, by removing its hooks, _if any_. Probably in `kill-buffer-hook'. >> If a user >> does that and a buffer gets killed by the way and the user later on >> decides to redisplay that buffer via xrefing, she has to pay the price >> of re-reading that buffer from file. That's why this feature should be >> optional. > > Does what? Remove *xref* from display, later on display *xref* again and try to visit a buffer that was killed in between by xref. > I wouldn't necessarily agree (the keys and allowed commands could be > customizable), but ok, let's not go that way. I don't want to impose my dislike on others. But if you want to do things modally you should give people means to optionally do things manually. IDE lovers, for example, might want to keep a small *xref* window permanently open in some corner of the frame, with backward/forward buttons for navigating their xref history. And I'd probably plug in a timer-driven variant of `xref-next-line' where moving to some particular line in the *xref* buffer window will display the tag in another window, provided point remains sufficiently long on that line. martin From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 20 07:14:24 2015 Received: (at 19466) by debbugs.gnu.org; 20 Jan 2015 12:14:24 +0000 Received: from localhost ([127.0.0.1]:50286 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDXhP-0006pW-R4 for submit@debbugs.gnu.org; Tue, 20 Jan 2015 07:14:24 -0500 Received: from mail-wi0-f173.google.com ([209.85.212.173]:57660) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDXhM-0006pH-Ec for 19466@debbugs.gnu.org; Tue, 20 Jan 2015 07:14:21 -0500 Received: by mail-wi0-f173.google.com with SMTP id r20so22661903wiv.0 for <19466@debbugs.gnu.org>; Tue, 20 Jan 2015 04:14:14 -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=tCZseLdqZH0WTTsbiVwFfFQSlGBuU+eQCDXFFdxMh28=; b=QgMPMK5wTDRVBHURLCMHqq/hDLwrcXhBFQU1NSKWyV1uikFr6haw19sVjpbKwC66El RKJDIsEaVoAh3IJZuVDZLcv9bgUE90iUoCeesCIcOzgZJCa0M5YNytb4maibm3LceyJ7 o1TYVwoV8yjGmlPzrwA/wCchYUMQBv8Xqr7w5DzgAV8kBddDbHl0GSPIKhB+L8miIu2E kQf5ep8K2PvfcjGcno3zuCdJ4d1kJd/YFVAI43255/7lLBBRD/OGQsYM9fLzjMgQPxXw VzHr3hSXeTfgpiW59CeOVgPh++12zWCrzlvWXMeWlvfvQJTKptGGDFNimmLmKk5Qt14A WwZA== X-Received: by 10.180.73.178 with SMTP id m18mr45494173wiv.65.1421756054554; Tue, 20 Jan 2015 04:14:14 -0800 (PST) Received: from [192.168.1.3] ([82.102.93.54]) by mx.google.com with ESMTPSA id dp8sm2772054wib.20.2015.01.20.04.14.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Jan 2015 04:14:13 -0800 (PST) Message-ID: <54BE4693.5050804@yandex.ru> Date: Tue, 20 Jan 2015 14:14:11 +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 To: martin rudalics , Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <54BD076E.6090707@yandex.ru> <54BE0B5A.6060706@gmx.at> In-Reply-To: <54BE0B5A.6060706@gmx.at> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Helmut Eller 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/20/2015 10:01 AM, martin rudalics wrote: > Hmm... They are documented in the Window Parameters section. What do > you miss? No, that's good enough, thanks. I was looking for that documentation in window.el. > >> Note in this context that some people might have > >> globally bound `quit-window' to some key other than 'q' and might want > >> to quit *xref* with that. > > > > You obviously mean [remap quit-window]. > > No. IMO it should be up to the user to remap `quit-window'. If you're arguing to remove the `q' mapping in xref--xref-buffer-mode-map, that's a pretty circumstantial way to go about it. And I disagree. The user is in control either way (they can modify the above map just as well), but the binding should be there by default because it's a part of the core functionality. `xref-goto-xref' also calls `xref--quit', and having one without the other by default would be weird. > What I meant was that people might be used to kill the *xref* buffer > along with closing its window or use `kill-buffer' directly on *xref*. > And that xref should be aware of that and act accordingly, for example, > by removing its hooks, _if any_. Probably in `kill-buffer-hook'. The hooks won't be a real problem. Currently, it sets up none. If we use buffer-list-update-hook, that it will fire at most once in each used buffer, and then remove itself. There's no harm leaving it in, and either way, it's a pretty unimportant detail. > I don't want to impose my dislike on others. But if you want to do > things modally you should give people means to optionally do things > manually. Conceptually, doing things in a different way would correspond to a different value of xref-show-xrefs-function. Everyone's welcome to try creating a different interface. > IDE lovers, for example, might want to keep a small *xref* window > permanently open in some corner of the frame, with backward/forward > buttons for navigating their xref history. While I like the sound of this, I'm having hard time imagining how xrefs would work with back-forward buttons. Suppose the user performed a jump to a definition. What contents will xref buffer have after that? The same? > And I'd probably plug in a timer-driven variant of `xref-next-line' > where moving to some particular line in the *xref* buffer window will > display the tag in another window, provided point remains sufficiently > long on that line. That's trivial to implement (I'm thinking post-command-hook with sit-for rather than a timer), but the hard part is creating, naming and documenting the yet-another user option, as far as I'm concerned. Feel free to try your hand at it. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 20 09:51:25 2015 Received: (at 19466) by debbugs.gnu.org; 20 Jan 2015 14:51:25 +0000 Received: from localhost ([127.0.0.1]:50338 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDa9M-0004ss-MC for submit@debbugs.gnu.org; Tue, 20 Jan 2015 09:51:25 -0500 Received: from mout.gmx.net ([212.227.15.15]:57379) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDa9I-0004sZ-R3 for 19466@debbugs.gnu.org; Tue, 20 Jan 2015 09:51:21 -0500 Received: from [178.191.138.58] ([178.191.138.58]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lu7a2-1XlZRj3bYk-011OgH; Tue, 20 Jan 2015 15:51:10 +0100 Message-ID: <54BE6B59.5090404@gmx.at> Date: Tue, 20 Jan 2015 15:51:05 +0100 From: martin rudalics MIME-Version: 1.0 To: Dmitry Gutov , Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <54BD076E.6090707@yandex.ru> <54BE0B5A.6060706@gmx.at> <54BE4693.5050804@yandex.ru> In-Reply-To: <54BE4693.5050804@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ImfI6ex16fgVlrwhyGQP50I0lsHQJSJ/lTJZyoKQxm4MHUa/z7I GCgMFWLEkqTbsa8Y7VZ5H2e7H4ksObpH0aH6pD3eUxBEYLC94OkIh9vs4j1ynFZViuiJ+Gb z+OU9EHTXaRX6IXi+9wjINFK5mo7OUM9AXXwq8rp8F5DgZC3/0i1mpfoT9oVDgm9GmCkrRP GGvigzrujSQlYeJtxmT2g== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Helmut Eller 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 (/) > If you're arguing to remove the `q' mapping in > xref--xref-buffer-mode-map, that's a pretty circumstantial way to go > about it. And I disagree. By no means. `q' should do what it does now. > The user is in control either way (they can modify the above map just > as well), but the binding should be there by default because it's a > part of the core functionality. `xref-goto-xref' also calls > `xref--quit', and having one without the other by default would be > weird. Sure. All I mean is that if the user decides to bury the *xref* buffer and later switches back to it, it should be functional as before. And if the user kills the buffer, there should not be any traces left. Both seem to work at the moment IIUC. Here I only wanted to state that there might be other means to stop/suspend xrefing than via `xref--quit'. > The hooks won't be a real problem. Currently, it sets up none. If we > use buffer-list-update-hook, that it will fire at most once in each > used buffer, and then remove itself. There's no harm leaving it in, > and either way, it's a pretty unimportant detail. I think that the "remove itself" feature is good and if it can be done I see no problems. > Conceptually, doing things in a different way would correspond to a > different value of xref-show-xrefs-function. Everyone's welcome to try > creating a different interface. `xref--show-xref-buffer' is good as it is. `xref-show-xrefs-function' might be useful to emulate the old behavior where the buffer is never shown but some keystroke is used to jump to the next tag. > While I like the sound of this, I'm having hard time imagining how > xrefs would work with back-forward buttons. Suppose the user performed > a jump to a definition. What contents will xref buffer have after > that? The same? Yes. But the buttons could get me to a buffer showing the result(s) of the next and previous tag searches. Basically what M-. followed by previous-/next-history-element should do (and for some reason doesn't do here yet). > That's trivial to implement (I'm thinking post-command-hook with > sit-for rather than a timer), but the hard part is creating, naming > and documenting the yet-another user option, as far as I'm > concerned. Feel free to try your hand at it. I'll do that here as soon as I know where I want to place my *xref* window within a frame. In addition to what Eli reclaimed earlier: I need M-. to work in texi buffers, the Emacs manuals, from *Help*, backtrace and customization buffers. How set things up for that? Thanks, martin From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 20 12:25:02 2015 Received: (at 19466) by debbugs.gnu.org; 20 Jan 2015 17:25:02 +0000 Received: from localhost ([127.0.0.1]:50931 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDcY1-0000Oy-R3 for submit@debbugs.gnu.org; Tue, 20 Jan 2015 12:25:02 -0500 Received: from mtaout26.012.net.il ([80.179.55.182]:36698) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDcXz-0000OV-1S for 19466@debbugs.gnu.org; Tue, 20 Jan 2015 12:25:00 -0500 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NIH00700K8OXL00@mtaout26.012.net.il> for 19466@debbugs.gnu.org; Tue, 20 Jan 2015 19:24:42 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIH00NEMKD6EU90@mtaout26.012.net.il>; Tue, 20 Jan 2015 19:24:42 +0200 (IST) Date: Tue, 20 Jan 2015 19:24:46 +0200 From: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions In-reply-to: <54BDC34C.5070309@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Gutov Message-id: <83wq4hwejl.fsf@gnu.org> References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19466 Cc: rudalics@gmx.at, eller.helmut@gmail.com, 19466@debbugs.gnu.org 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: 1.0 (+) > Date: Tue, 20 Jan 2015 04:54:04 +0200 > From: Dmitry Gutov > CC: 19466@debbugs.gnu.org, eller.helmut@gmail.com > > > One issue I still see is that if TAGS is slightly outdated, point is > > positioned not on the first line of a function/macro/struct, but on > > the line recorded in TAGS. I hope this will be fixed soon. > > Okay, should work now. Thanks for the reminder. Thanks. > > Another minor issue is with the help-echo in the xref buffer: it says > > "mouse-2: display, mouse-1: navigate", which is confusing because it's > > unclear what exactly each of these 2 means. How about saying > > explicitly "show in this window" and "show in another window" > > (assuming this is what that does)? > > Not exactly. Here "navigate" means bury the xref and other temporary > buffers, and then display the reference in the current or other window, > or frame it was originally intended to be displayed in (depending on > which command was invoked: `xref-find-definitions', > `xref-find-definitions-other-window' or > `xref-find-definitions-other-frame'). Then I'd suggest "show definition" instead of "navigate". The latter has no useful meaning in this context, and just confuses. > > Finally, I still think we need to allow searching symbols not only in > > the current buffer's programming language, at least with the tags > > back-end. Without that, we cannot deprecate find-tag. > > Please refer to the following messages: > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19466#32 > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19466#41 > > And for completeness, a third option: define a minor mode that would > remap xref-find-* commands to their etags-only variants, which can be > trivially implemented by let-binding the two relevant variables to their > default values. I don't really understand the difference between the various options, so my suggestion would be to start with something that looks promising, and then see if users like that. The important thing is implement something; just enumerating the alternatives is not enough. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 20 15:49:48 2015 Received: (at 19466) by debbugs.gnu.org; 20 Jan 2015 20:49:48 +0000 Received: from localhost ([127.0.0.1]:51079 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDfkC-0006uH-BM for submit@debbugs.gnu.org; Tue, 20 Jan 2015 15:49:48 -0500 Received: from mail-wi0-f178.google.com ([209.85.212.178]:65422) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDfkB-0006u3-6H for 19466@debbugs.gnu.org; Tue, 20 Jan 2015 15:49:47 -0500 Received: by mail-wi0-f178.google.com with SMTP id em10so16920478wid.5 for <19466@debbugs.gnu.org>; Tue, 20 Jan 2015 12:49:41 -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=KqOIegy9SL2Ll4DxC8RN8sRgy/DiEycD28jE9Z9jK3k=; b=pj1vzG2PLjV1mvWitP+y/Q2DUmwdsKl4MlhCx3Ev60kBolWzjgJ6LDsWxwIPAxXfte t4yvaUftxqNlYOCrs6vhDiluuLFvFN2TyfrSWDKlZdAt3MGOjOU1UT4G3//0EsYFU+7U olucP/2U2KVl0hsXl1ISj5uJmsPT3FuAQZ8lBCeRdH/nqtxAd1drdrksbSTnvCMH84Kc fqsWOe1zYOUvVwkmhX4Z2FaCDkpJ0fgi+NtDuZKj7UfotSlkY+Zce1QC26er+norwMJM ta8PIERMey7M6dfgxoJJ9SQd23GCc6L2Vjq/395qopzMdEBvY1v//C8JwQh5+vpSydot uAGg== X-Received: by 10.180.90.241 with SMTP id bz17mr31856537wib.0.1421786981579; Tue, 20 Jan 2015 12:49:41 -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 bb2sm11033703wjc.43.2015.01.20.12.49.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Jan 2015 12:49:40 -0800 (PST) Message-ID: <54BEBF63.9050709@yandex.ru> Date: Tue, 20 Jan 2015 22:49:39 +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 To: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> In-Reply-To: <83wq4hwejl.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: rudalics@gmx.at, eller.helmut@gmail.com, 19466@debbugs.gnu.org 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/20/2015 07:24 PM, Eli Zaretskii wrote: > Then I'd suggest "show definition" instead of "navigate". The latter > has no useful meaning in this context, and just confuses. "go to definition" should be the clearest option, then. ...Except the xref interface is also supposed to be used for "apropos" and "find references". The latter, though not implemented for the two current backends, would be reasonably easy to do for certain environments like SLIME. "definition" won't be the right term then. Any suggestions? > I don't really understand the difference between the various options, I'm afraid you'll have to spend the effort to understand it (but feel free to ask questions). AFAICT, the audience for this feature is just a few people, and myself is not among them. So far, I don't have the proper requirements to work with. Come on, in each case that's just a few lines of Lisp you need to look at, and maybe try. > so my suggestion would be to start with something that looks > promising, and then see if users like that. The important thing is > implement something; just enumerating the alternatives is not enough. Messages 32 and 41 include functional implementations you can try. The patches that would go into Emacs won't be much different, we'd just have to decide on code organization. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 21 02:20:47 2015 Received: (at 19466) by debbugs.gnu.org; 21 Jan 2015 07:20:47 +0000 Received: from localhost ([127.0.0.1]:51268 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDpap-0006rV-BY for submit@debbugs.gnu.org; Wed, 21 Jan 2015 02:20:47 -0500 Received: from mail-wi0-f182.google.com ([209.85.212.182]:40800) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDpan-0006rF-Fd for 19466@debbugs.gnu.org; Wed, 21 Jan 2015 02:20:45 -0500 Received: by mail-wi0-f182.google.com with SMTP id n3so28509692wiv.3 for <19466@debbugs.gnu.org>; Tue, 20 Jan 2015 23:20:39 -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=MAgadINpPAdAn7o1xRt/OhKWsgXE5brWS4dJWlr8blE=; b=CnuJs89rLqfVyR9mJqRXWwuyi0Sxux7CoVIYiJDSjqISNyYdr2uLA1i0Bv7DBUN+lG wdqnsVi2IIP0W9rLrB3IdfMdiQG1+lgBAVGDl5B5tA3Jw49/kNhNTWtpJ2MsL6C/GF+K AF34IZwMSi/rOL+dTw6buJMDePMR5liP1weNPbnxzPZihenS6AuH4CPYfqgQltb0qQac p+zdJZYIwen0phu8cGCy1Je2cBHDYzrF12wDZtJwI/P5tsgHLhdWmkV4CZYUXG8qqb19 dhnk749xz3M0NljDV1e9tAgE3dhkji5Wc/bxVSDmQ6z1zN6RN6PZm7R6BGe6wTFuHwFG NbGw== X-Received: by 10.194.57.84 with SMTP id g20mr20849924wjq.122.1421824839645; Tue, 20 Jan 2015 23:20:39 -0800 (PST) Received: from [192.168.1.3] ([82.102.93.54]) by mx.google.com with ESMTPSA id w16sm5999428wia.15.2015.01.20.23.20.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Jan 2015 23:20:38 -0800 (PST) Message-ID: <54BF5345.9090303@yandex.ru> Date: Wed, 21 Jan 2015 09:20:37 +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 To: martin rudalics , Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <54BD076E.6090707@yandex.ru> <54BE0B5A.6060706@gmx.at> <54BE4693.5050804@yandex.ru> <54BE6B59.5090404@gmx.at> In-Reply-To: <54BE6B59.5090404@gmx.at> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Helmut Eller 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/20/2015 04:51 PM, martin rudalics wrote: > Sure. All I mean is that if the user decides to bury the *xref* buffer > and later switches back to it, it should be functional as before. And > if the user kills the buffer, there should not be any traces left. Both > seem to work at the moment IIUC. Yeah, both should still work. I've pushed the buffer-killing implementation, please take a look. One drawback comes to mind: xref-goto-xref calls xref-quit without the KILL argument, so the temporary buffers are not cleared if you make a choice and press RET. > previous-/next-history-element Not sure what these are. > In addition to what Eli reclaimed earlier: I need M-. to work in texi > buffers, the Emacs manuals, from *Help*, backtrace and customization > buffers. How set things up for that? Depends on what you want each of them to do. debugger-mode should probably set both relevant vars to the same values as emacs-lisp-mode. help-mode and Custom-mode - maybe too, although they might use some custom logic. In Info-mode, xref-find-function could use the index and the search functionality. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 21 05:49:50 2015 Received: (at 19466) by debbugs.gnu.org; 21 Jan 2015 10:49:50 +0000 Received: from localhost ([127.0.0.1]:51289 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDsr7-0003WT-EV for submit@debbugs.gnu.org; Wed, 21 Jan 2015 05:49:49 -0500 Received: from mout.gmx.net ([212.227.15.15]:62577) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDsr5-0003WG-TC for 19466@debbugs.gnu.org; Wed, 21 Jan 2015 05:49:48 -0500 Received: from [188.22.44.50] ([188.22.44.50]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LaoHI-1XTaou06ZM-00kQbo; Wed, 21 Jan 2015 11:49:40 +0100 Message-ID: <54BF843E.10907@gmx.at> Date: Wed, 21 Jan 2015 11:49:34 +0100 From: martin rudalics MIME-Version: 1.0 To: Dmitry Gutov , Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <54BD076E.6090707@yandex.ru> <54BE0B5A.6060706@gmx.at> <54BE4693.5050804@yandex.ru> <54BE6B59.5090404@gmx.at> <54BF5345.9090303@yandex.ru> In-Reply-To: <54BF5345.9090303@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:NyNSFKa2gj6Tkon3I9vGK8/ejbPnO4feHN7vCpU5fhAAY/Sok8H btQDht6BHqSe0KTIGm6fUc87hIUER4KE2jU5M2nXZCD9tCETRNk2QLNzUoW5+P3wFrsPF9h 8yqkzXIf0p4qfzTjWib0JOWBoZw9VC3kXxPnkX10OY6U5r6WPvsSJoFdVpxG6e0EnKNf1Ec tECnGYzNwoIeytCtpTiuA== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Helmut Eller 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 (/) > Yeah, both should still work. I've pushed the buffer-killing implementation, please take a look. The idea to do it via the KILL argument is good. I think some doc-strings are bad. For example, instead of (defvar-local xref--selected nil "t if the current buffer has ever been selected. Used for temporary buffers.") I'd say something like (defvar-local xref--current nil "Non-nil if this buffer was current once while finding xrefs.") And for `xref-quit' I'd describe the standard behavior first and the KILL behavior afterwards. Also I'm not sure it it's just cosmetics but shouldn't the (pcase-dolist (`(,buf . ,win) history) (when (and (window-live-p win) (eq buf (window-buffer win))) (quit-window nil win))) precede the (when kill (let ((xref--inhibit-mark-selected t) kill-buffer-query-functions) (dolist (buf xref--temporary-buffers) (unless (buffer-local-value 'xref--selected buf) (kill-buffer buf))) (setq xref--temporary-buffers nil))) part? I can't test it currently because I always get Debugger entered--Lisp error: (args-out-of-range "" 0) help-function-arglist(#[257 "\300\207" ["(No location)"] 2 "(No location)\n\n(fn ##)"] preserve-names) eieio--defmethod(xref-location-group nil xref-bogus-location #[257 "\300\207" ["(No location)"] 2 "(No location)\n\n(fn ##)"]) byte-code("\300\301\302\301\303\"\"\210\304\301\303\305\306$\210\300\307\302\307\303\"\"\210\304\307\303\305\310$\207" [eieio--defalias xref-location-marker eieio--defgeneric-init-form nil eieio--defmethod xref-bogus-location #[257 "\300\301\302\303\"\"\207" [user-error "%s" eieio-oref :message] 6 "\n\n(fn L)"] xref-location-group #[257 "\300\207" ["(No location)"] 2 "(No location)\n\n(fn ##)"]] 5) autoload-do-load((autoload "xref" 1640080 t nil) xref-find-definitions) command-execute(xref-find-definitions) even after a bootstrap. > One drawback comes to mind: > > xref-goto-xref calls xref-quit without the KILL argument, so the temporary buffers are not cleared if you make a choice and press RET. You can redisplay the *xref* buffer and provide the KILL there. >> previous-/next-history-element > > Not sure what these are. Something like typing M-. doing something else and typing M-. again. At this time up/down should get you the next/previous history elements of your xref searches. > Depends on what you want each of them to do. > > debugger-mode should probably set both relevant vars to the same values as emacs-lisp-mode. help-mode and Custom-mode - maybe too, although they might use some custom logic. > > In Info-mode, xref-find-function could use the index and the search functionality. Will there be a canonical way to add these? martin From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 21 09:24:44 2015 Received: (at 19466) by debbugs.gnu.org; 21 Jan 2015 14:24:44 +0000 Received: from localhost ([127.0.0.1]:51546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDwD6-0001r1-5U for submit@debbugs.gnu.org; Wed, 21 Jan 2015 09:24:44 -0500 Received: from mail-wg0-f44.google.com ([74.125.82.44]:41430) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDwD3-0001qn-Aq for 19466@debbugs.gnu.org; Wed, 21 Jan 2015 09:24:42 -0500 Received: by mail-wg0-f44.google.com with SMTP id z12so6421299wgg.3 for <19466@debbugs.gnu.org>; Wed, 21 Jan 2015 06:24:35 -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=p7luDdvEQ81UIaTLmZTJwJGO15lC9Csi3exp9d6akaI=; b=i9pjDPuRGxdc/IsHSrLoynKJOX217ajRI/t8pkXarCc67VSOWKmIoQc77EsImIb8m6 5kP/ceVwPuHNN72L3Cun9mceRshBR39fDlCidQ2qHklssP99pKNKCwNAf0DcYGJ1vf47 aPP76cbyXv3xC6TkPaLmom1a9Qbo7xxrJXimtfj6VRlCKeb6xygnAeCVRsYoIljCOWdB VSe/3Je4RlU+OsSRyB0Bf0yLM2QwA1Gb9voKhVW8oy5FtbNE4Z3UiVJG3z4QpC5rT69l ao0nYqaveM65U/FIorw0iifbDkje/SbFgkQrZ3G21JNoJHQ7T6UJMXPKNY0tskqnLGMA 6VMw== X-Received: by 10.180.91.109 with SMTP id cd13mr56804989wib.46.1421850275679; Wed, 21 Jan 2015 06:24:35 -0800 (PST) Received: from [192.168.1.3] ([82.102.93.54]) by mx.google.com with ESMTPSA id gl1sm7491929wib.13.2015.01.21.06.24.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jan 2015 06:24:35 -0800 (PST) Message-ID: <54BFB6A1.8050802@yandex.ru> Date: Wed, 21 Jan 2015 16:24:33 +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 To: martin rudalics , Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <54BD076E.6090707@yandex.ru> <54BE0B5A.6060706@gmx.at> <54BE4693.5050804@yandex.ru> <54BE6B59.5090404@gmx.at> <54BF5345.9090303@yandex.ru> <54BF843E.10907@gmx.at> In-Reply-To: <54BF843E.10907@gmx.at> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Helmut Eller 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/21/2015 12:49 PM, martin rudalics wrote: > The idea to do it via the KILL argument is good. I think some > doc-strings are bad. For example, instead of > > (defvar-local xref--selected nil > "t if the current buffer has ever been selected. > Used for temporary buffers.") > > I'd say something like > > (defvar-local xref--current nil > "Non-nil if this buffer was current once while finding xrefs.") "current" would be good, but "while finding xrefs" is iffy: we actually try to ignore instances of buffers being current while we display them (see xref--inhibit-mark-selected). > And for `xref-quit' I'd describe the standard behavior first and the > KILL behavior afterwards. Would you like to suggest a specific wording? > Also I'm not sure it it's just cosmetics but > shouldn't the > > (pcase-dolist (`(,buf . ,win) history) > (when (and (window-live-p win) > (eq buf (window-buffer win))) > (quit-window nil win))) > > precede the > > (when kill > (let ((xref--inhibit-mark-selected t) > kill-buffer-query-functions) > (dolist (buf xref--temporary-buffers) > (unless (buffer-local-value 'xref--selected buf) > (kill-buffer buf))) > (setq xref--temporary-buffers nil))) > > part? Probably, but there's likely not much difference at the moment. xref doesn't pop any new windows, so we shouldn't miss on deleting those when quitting temporary buffers. > I can't test it currently because I always get > > Debugger entered--Lisp error: (args-out-of-range "" 0) > help-function-arglist(#[257 "\300\207" ["(No location)"] 2 "(No > location)\n\n(fn ##)"] preserve-names) > eieio--defmethod(xref-location-group nil xref-bogus-location #[257 > "\300\207" ["(No location)"] 2 "(No location)\n\n(fn ##)"]) I'm sure Someone(tm) will fix that right away. :) > > xref-goto-xref calls xref-quit without the KILL argument, so the > temporary buffers are not cleared if you make a choice and press RET. > > You can redisplay the *xref* buffer and provide the KILL there. You mean, for the user to switch to the buried xref buffer, then press C-u q? That's quite a few keypresses. > >> previous-/next-history-element > > > > Not sure what these are. > > Something like typing M-. doing something else and typing M-. again. At > this time up/down should get you the next/previous history elements of > your xref searches. You mean in the current interface? I'm confused. > > debugger-mode should probably set both relevant vars to the same > values as emacs-lisp-mode. help-mode and Custom-mode - maybe too, > although they might use some custom logic. > > > > In Info-mode, xref-find-function could use the index and the search > functionality. > > Will there be a canonical way to add these? I meant that xref-identifier-completion-table-function would return identifiers from the index, and xref-find-function would delegate to the search functionality. With xref, we already sorta have both as features (C-u M-x xref-find-definitions and M-x xref-find-apropos). From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 21 11:25:49 2015 Received: (at 19466) by debbugs.gnu.org; 21 Jan 2015 16:25:50 +0000 Received: from localhost ([127.0.0.1]:52037 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDy6H-0004xq-6x for submit@debbugs.gnu.org; Wed, 21 Jan 2015 11:25:49 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:53152) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDy6E-0004xa-8d for 19466@debbugs.gnu.org; Wed, 21 Jan 2015 11:25:47 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NIJ00K00C6JAO00@a-mtaout22.012.net.il> for 19466@debbugs.gnu.org; Wed, 21 Jan 2015 18:25:39 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIJ00KSFCAR0G70@a-mtaout22.012.net.il>; Wed, 21 Jan 2015 18:25:39 +0200 (IST) Date: Wed, 21 Jan 2015 18:25:36 +0200 From: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions In-reply-to: <54BEBF63.9050709@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Gutov Message-id: <8361c0w16n.fsf@gnu.org> References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> <54BEBF63.9050709@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19466 Cc: rudalics@gmx.at, eller.helmut@gmail.com, 19466@debbugs.gnu.org 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: 1.0 (+) > Date: Tue, 20 Jan 2015 22:49:39 +0200 > From: Dmitry Gutov > CC: rudalics@gmx.at, 19466@debbugs.gnu.org, eller.helmut@gmail.com > > On 01/20/2015 07:24 PM, Eli Zaretskii wrote: > > > Then I'd suggest "show definition" instead of "navigate". The latter > > has no useful meaning in this context, and just confuses. > > "go to definition" should be the clearest option, then. Works for me. > ...Except the xref interface is also supposed to be used for "apropos" > and "find references". The latter, though not implemented for the two > current backends, would be reasonably easy to do for certain > environments like SLIME. "definition" won't be the right term then. Any > suggestions? Can the package that uses xref modify that string? If so, we don't need a single-fits-all phrase. If we do need a single phrase, then how about "go to definition/reference"? > > I don't really understand the difference between the various options, > > I'm afraid you'll have to spend the effort to understand it (but feel > free to ask questions). AFAICT, the audience for this feature is just a > few people, and myself is not among them. So far, I don't have the > proper requirements to work with. Perhaps you could ask what issues need to be resolved for you to understand the requirements. > Come on, in each case that's just a few lines of Lisp you need to look > at, and maybe try. If you can show me the complete Lisp, I can try that and return feedback. > Messages 32 and 41 include functional implementations you can try. The > patches that would go into Emacs won't be much different, we'd just have > to decide on code organization. The recipe in #32 is clearly incomplete. Not sure about 41. Once again, if you can show a complete Lisp to try, I will. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 21 11:54:26 2015 Received: (at 19466) by debbugs.gnu.org; 21 Jan 2015 16:54:26 +0000 Received: from localhost ([127.0.0.1]:52047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDyXx-0005gl-Qf for submit@debbugs.gnu.org; Wed, 21 Jan 2015 11:54:26 -0500 Received: from mout.gmx.net ([212.227.15.15]:64742) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDyXw-0005gY-6l for 19466@debbugs.gnu.org; Wed, 21 Jan 2015 11:54:25 -0500 Received: from [188.22.33.74] ([188.22.33.74]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0McEI3-1YTaPy0IfH-00JaAT; Wed, 21 Jan 2015 17:54:13 +0100 Message-ID: <54BFD9AF.10002@gmx.at> Date: Wed, 21 Jan 2015 17:54:07 +0100 From: martin rudalics MIME-Version: 1.0 To: Dmitry Gutov , Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <54BD076E.6090707@yandex.ru> <54BE0B5A.6060706@gmx.at> <54BE4693.5050804@yandex.ru> <54BE6B59.5090404@gmx.at> <54BF5345.9090303@yandex.ru> <54BF843E.10907@gmx.at> <54BFB6A1.8050802@yandex.ru> In-Reply-To: <54BFB6A1.8050802@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:FHH0ZRqfqHsa/Mpg+Gzokv9qMQ2jrNUKx5Wb9fFW/UjiIFzWiMT wSkB14xEHCJlsIolTpicFLvQ3XPrXEaLl9+m32vSaXPOskGUyEJ1FtbYMXxR0N/p/vDSI89 dhErGjqWaKxNOSsbluESyOdmBLKCcRmwj4pMhVRgSO9FzbeUONbDtmadkhfIPh5drEc5ot7 qTALVNnswyVkCR66vkxcg== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Helmut Eller 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 (/) > "current" would be good, but "while finding xrefs" is iffy: we actually try to ignore instances of buffers being current while we display them (see xref--inhibit-mark-selected). In any case please stick to the "`current' is a predicate for buffers and `selected' is a predicate for windows and frames" convention. >> And for `xref-quit' I'd describe the standard behavior first and the >> KILL behavior afterwards. > > Would you like to suggest a specific wording? I'll try to as soon as I know what it does. Usually the "If optional argument KILL is non-nil ..." idiom should appear after describing the normal behavior. >> Also I'm not sure it it's just cosmetics but >> shouldn't the >> >> (pcase-dolist (`(,buf . ,win) history) >> (when (and (window-live-p win) >> (eq buf (window-buffer win))) >> (quit-window nil win))) >> >> precede the >> >> (when kill >> (let ((xref--inhibit-mark-selected t) >> kill-buffer-query-functions) >> (dolist (buf xref--temporary-buffers) >> (unless (buffer-local-value 'xref--selected buf) >> (kill-buffer buf))) >> (setq xref--temporary-buffers nil))) >> >> part? > > Probably, but there's likely not much difference at the moment. xref > doesn't pop any new windows, ... well, it did so here all the time ... > so we shouldn't miss on deleting those when quitting temporary buffers. Are you sure? Suppose `xref-show-location-at-point' reused a window showing a buffer A for showing a buffer B instead. Now `xref-quit' would kill B which should again show A instead. But here you rely on `kill-buffer' (that is `replace-buffer-in-windows') DTRT. >> I can't test it currently because I always get >> >> Debugger entered--Lisp error: (args-out-of-range "" 0) >> help-function-arglist(#[257 "\300\207" ["(No location)"] 2 "(No >> location)\n\n(fn ##)"] preserve-names) >> eieio--defmethod(xref-location-group nil xref-bogus-location #[257 >> "\300\207" ["(No location)"] 2 "(No location)\n\n(fn ##)"]) > > I'm sure Someone(tm) will fix that right away. :) For some value of "right away" :) >> > xref-goto-xref calls xref-quit without the KILL argument, so the >> temporary buffers are not cleared if you make a choice and press RET. >> >> You can redisplay the *xref* buffer and provide the KILL there. > > You mean, for the user to switch to the buried xref buffer, then press C-u q? That's quite a few keypresses. Then you probably want the KILL argument for `xref-goto-xref' too. >> >> previous-/next-history-element >> > >> > Not sure what these are. >> >> Something like typing M-. doing something else and typing M-. again. At >> this time up/down should get you the next/previous history elements of >> your xref searches. > > You mean in the current interface? I'm confused. When xref prompts me with Find definitions of: I'd expect to be able to browse my history of definitions I tried or succeeded to find. > With xref, we already sorta have both as features (C-u M-x xref-find-definitions and M-x xref-find-apropos). OK. They all work well in my gdb buffer. So it shouldn't be too hard. martin From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 21 13:00:38 2015 Received: (at 19466) by debbugs.gnu.org; 21 Jan 2015 18:00:38 +0000 Received: from localhost ([127.0.0.1]:52077 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDza0-0007M0-Hi for submit@debbugs.gnu.org; Wed, 21 Jan 2015 13:00:37 -0500 Received: from mout.gmx.net ([212.227.17.21]:53224) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YDzZx-0007Lh-Ar for 19466@debbugs.gnu.org; Wed, 21 Jan 2015 13:00:34 -0500 Received: from [188.22.33.74] ([188.22.33.74]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MI5rO-1YA8l51OqU-003vny; Wed, 21 Jan 2015 19:00:25 +0100 Message-ID: <54BFE933.9090009@gmx.at> Date: Wed, 21 Jan 2015 19:00:19 +0100 From: martin rudalics MIME-Version: 1.0 To: Dmitry Gutov , Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <54BD076E.6090707@yandex.ru> <54BE0B5A.6060706@gmx.at> <54BE4693.5050804@yandex.ru> <54BE6B59.5090404@gmx.at> <54BF5345.9090303@yandex.ru> <54BF843E.10907@gmx.at> <54BFB6A1.8050802@yandex.ru> <54BFD9AF.10002@gmx.at> In-Reply-To: <54BFD9AF.10002@gmx.at> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:EBUQ8zCqM6efsi34FPLTPrS/vWmY2ra4LDgknbYbWUbpFmXDoIx O4QPD0F1qtv8i59GEklNlkeQGbOdAMzvyHNsSg4mPpX7pHp0mL0FprU8wNUOw9uJDbkhdi+ 50QYUqUyyo2nf272XPznihMH9pekmYpabYDpjhPCZWWKF6FYJ0T4CgTa6qvSVBDSWKDEypc +gQZgesu8ZRmPZtBsBC7Q== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Helmut Eller 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 (/) > >> Debugger entered--Lisp error: (args-out-of-range "" 0) > >> help-function-arglist(#[257 "\300\207" ["(No location)"] 2 "(No > >> location)\n\n(fn ##)"] preserve-names) > >> eieio--defmethod(xref-location-group nil xref-bogus-location #[257 > >> "\300\207" ["(No location)"] 2 "(No location)\n\n(fn ##)"]) > > > > I'm sure Someone(tm) will fix that right away. :) > > For some value of "right away" :) Meanwhile I additionally get: ELC progmodes/xref.elc `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead. `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead. `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead. `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead. `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead. `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead. `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead. `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead. `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead. `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead. `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead. `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. In end of data: progmodes/xref.el:625:1:Warning: the function `apropos-parse-pattern' is not known to be defined. martin From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 21 14:02:39 2015 Received: (at 19466) by debbugs.gnu.org; 21 Jan 2015 19:02:40 +0000 Received: from localhost ([127.0.0.1]:52113 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YE0Y3-0000SA-CU for submit@debbugs.gnu.org; Wed, 21 Jan 2015 14:02:39 -0500 Received: from mail-wi0-f171.google.com ([209.85.212.171]:52486) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YE0Y0-0000Rv-TA for 19466@debbugs.gnu.org; Wed, 21 Jan 2015 14:02:37 -0500 Received: by mail-wi0-f171.google.com with SMTP id l15so28518871wiw.4 for <19466@debbugs.gnu.org>; Wed, 21 Jan 2015 11:02:31 -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=ANu6ONIaa8MwAQqOI9ZvUn3Ff1TRtCElGg91X0AAyx8=; b=neyFd3k9TECOLMsA8VlNi0W43gHOmkTl4HsbZ8SLHo532GnTYzMO6M4xBuldVRVRlt g23VulHWmYgaTuLGxICoX8kkhFWdrNoFVFpozuAn37NpgG+yeQ6e14zTWcF6g+3Uzfdt KuGxtXvGtR0HYlGwOe6EprkkUJk0+8vqQjpnQElRll77mUtPU9u2NOtUedo4WOdvqnHG 0433xFDZx6m69f6JNLhUYoE4nn3DNAeLt9Yx05/CDvwFdZr+nGVf/10P9fU/zn1DKz2o vxO3gltybUL0FeNHKb1cYUrPDLxU4NQEUklEoHXGT0LnHfRDBVJznGBV20lazbnbOBs8 ALNg== X-Received: by 10.194.62.19 with SMTP id u19mr809418wjr.0.1421866951230; Wed, 21 Jan 2015 11:02:31 -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 dt10sm7251055wib.23.2015.01.21.11.02.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jan 2015 11:02:30 -0800 (PST) Message-ID: <54BFF7C4.9010500@yandex.ru> Date: Wed, 21 Jan 2015 21:02:28 +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 To: martin rudalics , Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <54BD076E.6090707@yandex.ru> <54BE0B5A.6060706@gmx.at> <54BE4693.5050804@yandex.ru> <54BE6B59.5090404@gmx.at> <54BF5345.9090303@yandex.ru> <54BF843E.10907@gmx.at> <54BFB6A1.8050802@yandex.ru> <54BFD9AF.10002@gmx.at> In-Reply-To: <54BFD9AF.10002@gmx.at> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Helmut Eller 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/21/2015 06:54 PM, martin rudalics wrote: > In any case please stick to the "`current' is a predicate for buffers > and `selected' is a predicate for windows and frames" convention. How about `visited'? The other precise alternative for that variable named is `was-current'. And considering that our main caller of that hook would be `select-window', maybe the current name isn't too far from the mark? > Are you sure? Suppose `xref-show-location-at-point' reused a window > showing a buffer A for showing a buffer B instead. Now `xref-quit' > would kill B which should again show A instead. But here you rely on > `kill-buffer' (that is `replace-buffer-in-windows') DTRT. Right, I do rely on kill-buffer doing what I'd expect. Anyway, I'm fine with swapping the order, will do so soon. > > You mean, for the user to switch to the buried xref buffer, then > press C-u q? That's quite a few keypresses. > > Then you probably want the KILL argument for `xref-goto-xref' too. Maybe. Wouldn't an option server this better? We also allow jumping to a mouse click, and pressing C-u in that case becomes more awkward. > When xref prompts me with > > Find definitions of: > > I'd expect to be able to browse my history of definitions I tried or > succeeded to find. Ok, thanks. I'll look into input history. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 21 15:03:00 2015 Received: (at 19466) by debbugs.gnu.org; 21 Jan 2015 20:03:00 +0000 Received: from localhost ([127.0.0.1]:52125 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YE1UR-0001wq-GN for submit@debbugs.gnu.org; Wed, 21 Jan 2015 15:03:00 -0500 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:49805) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YE1UP-0001wi-PL for 19466@debbugs.gnu.org; Wed, 21 Jan 2015 15:02:58 -0500 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 7A49F85E8B; Wed, 21 Jan 2015 15:02:57 -0500 (EST) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 1EDC71E5B8B; Wed, 21 Jan 2015 15:02:35 -0500 (EST) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 01F94B4102; Wed, 21 Jan 2015 15:02:34 -0500 (EST) From: Stefan Monnier To: martin rudalics Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions Message-ID: References: <8361cucl3u.fsf@gnu.org> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <54BD076E.6090707@yandex.ru> <54BE0B5A.6060706@gmx.at> <54BE4693.5050804@yandex.ru> <54BE6B59.5090404@gmx.at> <54BF5345.9090303@yandex.ru> <54BF843E.10907@gmx.at> <54BFB6A1.8050802@yandex.ru> <54BFD9AF.10002@gmx.at> <54BFE933.9090009@gmx.at> Date: Wed, 21 Jan 2015 15:02:34 -0500 In-Reply-To: <54BFE933.9090009@gmx.at> (martin rudalics's message of "Wed, 21 Jan 2015 19:00:19 +0100") 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-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Eli Zaretskii , Helmut Eller , Dmitry Gutov 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 (--) >> >> Debugger entered--Lisp error: (args-out-of-range "" 0) >> >> help-function-arglist(#[257 "\300\207" ["(No location)"] 2 "(No >> >> location)\n\n(fn ##)"] preserve-names) >> >> eieio--defmethod(xref-location-group nil xref-bogus-location #[257 >> >> "\300\207" ["(No location)"] 2 "(No location)\n\n(fn ##)"]) >> > I'm sure Someone(tm) will fix that right away. :) Sorry, I missed this. When/how do you get this error? > Meanwhile I additionally get: > ELC progmodes/xref.elc > `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. > `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. > `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead. > `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. > `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead. > `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. > `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead. > `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. > `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead. > `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. > `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead. > `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. > `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead. > `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. > `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead. > `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. > `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead. > `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. > `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead. > `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. > `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead. > `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. > `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead. > `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead. There are two problems here: 1- The warnings fail to include the "xref.el:: " prefix. Haven't figured out why yet. If someone wants to help fix this, he'd be very welcome. The problem seems to happen only when macroexp--warn-and-return is used on a toplevel form (aka "file-form"). The warnings themselves are otherwise correct (and "harmless"). 2- xref.el (just like pretty much all existing code using EIEIO) uses obsolete macros, indeed. This is easy to fix. Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 21 21:27:02 2015 Received: (at 19466) by debbugs.gnu.org; 22 Jan 2015 02:27:02 +0000 Received: from localhost ([127.0.0.1]:52206 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YE7U5-00048C-9V for submit@debbugs.gnu.org; Wed, 21 Jan 2015 21:27:01 -0500 Received: from mail-we0-f182.google.com ([74.125.82.182]:42158) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YE7U3-00047t-Ev for 19466@debbugs.gnu.org; Wed, 21 Jan 2015 21:26:59 -0500 Received: by mail-we0-f182.google.com with SMTP id l61so21185753wev.13 for <19466@debbugs.gnu.org>; Wed, 21 Jan 2015 18:26: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=+bW0pZKlnZ2GkxEBFX3g1BkBq/GqlYLk1bSkRbDWfBE=; b=SGr7T5DaIzOTyushqCsRKUwitEeFOq6NmZjmQ/mlvwPzUkhIl+zVRK0gHySIteVVkw XWbc4/8LsWt6jIiLS7LANtoC8zdLlQHQUHO5rX+zOmiNkiZf3BjdLumMivcGqJoC9P3S iNh3OzKmoeego0wYvMIAiYOWhfHI6FzsPEgAr4Jc8MVlCnPOwGRpPNw86jFoC2oNnMmH CPFIjgLqi78cDUgqfR4eF+/G1ccUb9NeRq6JHnrF3COvMzLJP0bJJ8lm9otXqezBhCQd v9OmENkWOYqLPAIp4P3lLLaiRd/Lsk34SLJ1C0Nkf/5DyqxI+/fdondyFY7SFTiRDT29 eipg== X-Received: by 10.194.175.39 with SMTP id bx7mr78326053wjc.22.1421893613890; Wed, 21 Jan 2015 18:26:53 -0800 (PST) Received: from [192.168.1.3] ([82.102.93.54]) by mx.google.com with ESMTPSA id di11sm1123551wid.8.2015.01.21.18.26.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jan 2015 18:26:53 -0800 (PST) Message-ID: <54C05FEB.1090601@yandex.ru> Date: Thu, 22 Jan 2015 04:26:51 +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 To: martin rudalics , Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <54BD076E.6090707@yandex.ru> <54BE0B5A.6060706@gmx.at> <54BE4693.5050804@yandex.ru> <54BE6B59.5090404@gmx.at> <54BF5345.9090303@yandex.ru> <54BF843E.10907@gmx.at> <54BFB6A1.8050802@yandex.ru> <54BFD9AF.10002@gmx.at> In-Reply-To: <54BFD9AF.10002@gmx.at> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Helmut Eller 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/21/2015 06:54 PM, martin rudalics wrote: > In any case please stick to the "`current' is a predicate for buffers > and `selected' is a predicate for windows and frames" convention. Anyway, xref--current seems good enough. > I'll try to as soon as I know what it does. Usually the "If optional > argument KILL is non-nil ..." idiom should appear after describing the > normal behavior. I've updated it in that direction. > When xref prompts me with > > Find definitions of: > > I'd expect to be able to browse my history of definitions I tried or > succeeded to find. This should work now. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 21 21:32:11 2015 Received: (at 19466) by debbugs.gnu.org; 22 Jan 2015 02:32:11 +0000 Received: from localhost ([127.0.0.1]:52211 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YE7Z4-0004HN-Ea for submit@debbugs.gnu.org; Wed, 21 Jan 2015 21:32:10 -0500 Received: from mail-wg0-f47.google.com ([74.125.82.47]:47209) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YE7Z2-0004H8-33 for 19466@debbugs.gnu.org; Wed, 21 Jan 2015 21:32:08 -0500 Received: by mail-wg0-f47.google.com with SMTP id n12so13049243wgh.6 for <19466@debbugs.gnu.org>; Wed, 21 Jan 2015 18:32:02 -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=wxMhbN3bgoS3CwAA/i3p8J6mnjNix7ytbvMH3pXAOis=; b=eAEntLHMAsJSyMzDJctzbM4tXNk7e0x94AGvd0X3zIc54uLYTshdC5z/DU1yCeAMXN F3ockx3SoZuSt/RY5ergEixMr53jVP3lI4nPJTRYflJ3a4eNptN4J+4+AJThw55mC5b2 WY0+ieT2YR8kz618tHXxV+qbH04lgXd0i+lk8zNM5T8x1JzRVlau7+c9BxVhjAloMRyn akUsWwwU8Gq9OaLVHUAYIcAc0IgggrMe+D1PXBNQFq3R46YRPwjd/R7KQ6uqLQYtH/uj XW5BWjN8lcOULU2ay1sOjuC2GD9I1N71oFYpazYvlu3sS61EdQdvNgPrScun9h4vhawN lbAA== X-Received: by 10.194.236.1 with SMTP id uq1mr32793582wjc.28.1421893922611; Wed, 21 Jan 2015 18:32:02 -0800 (PST) Received: from [192.168.1.3] ([82.102.93.54]) by mx.google.com with ESMTPSA id r3sm1118836wic.10.2015.01.21.18.32.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jan 2015 18:32:02 -0800 (PST) Message-ID: <54C06120.30606@yandex.ru> Date: Thu, 22 Jan 2015 04:32:00 +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 To: Stefan Monnier , martin rudalics Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <54BD076E.6090707@yandex.ru> <54BE0B5A.6060706@gmx.at> <54BE4693.5050804@yandex.ru> <54BE6B59.5090404@gmx.at> <54BF5345.9090303@yandex.ru> <54BF843E.10907@gmx.at> <54BFB6A1.8050802@yandex.ru> <54BFD9AF.10002@gmx.at> <54BFE933.9090009@gmx.at> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Helmut Eller 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/21/2015 10:02 PM, Stefan Monnier wrote: > Sorry, I missed this. When/how do you get this error? I happened on evaluating xref.el after you do 'make' in Emacs sources. > There are two problems here: > 1- The warnings fail to include the "xref.el:: " prefix. > Haven't figured out why yet. If someone wants to help fix this, he'd > be very welcome. The problem seems to happen only when > macroexp--warn-and-return is used on a toplevel form (aka > "file-form"). The warnings themselves are otherwise correct (and > "harmless"). > 2- xref.el (just like pretty much all existing code using EIEIO) uses > obsolete macros, indeed. This is easy to fix. Guess which one I've just fixed. :) From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 21 21:43:58 2015 Received: (at 19466) by debbugs.gnu.org; 22 Jan 2015 02:43:58 +0000 Received: from localhost ([127.0.0.1]:52215 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YE7kU-0004Yt-3H for submit@debbugs.gnu.org; Wed, 21 Jan 2015 21:43:58 -0500 Received: from mail-we0-f171.google.com ([74.125.82.171]:64100) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YE7kR-0004Yd-7h for 19466@debbugs.gnu.org; Wed, 21 Jan 2015 21:43:55 -0500 Received: by mail-we0-f171.google.com with SMTP id q58so988368wes.2 for <19466@debbugs.gnu.org>; Wed, 21 Jan 2015 18:43:49 -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=tvD0NKB+mMYklksosnhW/tRcNXH0yySnNY3/9NgINSU=; b=cAijfgUNBxoJTz2FNRHsNzNvCb4CN85qUg8uamPBeQJYcoLH9KTKJnmBclatCoGsd4 J7mosWU17PJ0cQF7X32csC0fYhzYiHfZJS3a6pqBrTn9GqaIT3EtuK1Tz5vK7HSXvLW/ 7R/bhJe80NLJYjO+TmmP/+F+4ITofsRXwQXstdNby9+gjS1xK+ORGdQtvn1Fq+Fuvnle bBD0PAafqo8N+oZR6w5cT8SoB5CP09V4ETWkryLYDpasqmsuuVHZdKO0eIY+xhhAy3Ty RtcsRFx8RLiY46pmUSxLbPQFP7I25T3gQrEwWo/HjKurLb7tHRPhdejYn5toq4xe22tm UXWA== X-Received: by 10.180.98.202 with SMTP id ek10mr38395138wib.56.1421894629353; Wed, 21 Jan 2015 18:43:49 -0800 (PST) Received: from [192.168.1.3] ([82.102.93.54]) by mx.google.com with ESMTPSA id u7sm1131522wiy.18.2015.01.21.18.43.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jan 2015 18:43:48 -0800 (PST) Message-ID: <54C063E3.8020401@yandex.ru> Date: Thu, 22 Jan 2015 04:43: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 To: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> <54BEBF63.9050709@yandex.ru> <8361c0w16n.fsf@gnu.org> In-Reply-To: <8361c0w16n.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: rudalics@gmx.at, eller.helmut@gmail.com, 19466@debbugs.gnu.org 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/21/2015 06:25 PM, Eli Zaretskii wrote: > Can the package that uses xref modify that string? If so, we don't > need a single-fits-all phrase. It can't, right now. But it would have to be modified by the used command (find-definitions/references/apropos), not the package. > If we do need a single phrase, then how about "go to > definition/reference"? I've settled on "follow reference" for now. > Perhaps you could ask what issues need to be resolved for you to > understand the requirements. Someone would have to gather them, and participate in the discussion about the tradeoffs. AFAICS you've pretty much stopped formulating the requirements at "there should be a way to use the tags.el backend instead of the major mode's backend". That's not good enough for me. > If you can show me the complete Lisp, I can try that and return > feedback. That would be good, but unless you declare one of them good enough, participation in the technical discussion will also be needed. >> Messages 32 and 41 include functional implementations you can try. The >> patches that would go into Emacs won't be much different, we'd just have >> to decide on code organization. > > The recipe in #32 is clearly incomplete. Not sure about 41. It's only incomplete because I expected you'd be able to turn on the minor mode defined there yourself, in any Emacs Lisp buffers you like. Here's the "missing piece" for #32: (defun elisp-maybe-turn-on-xref-etags-mode () (when (and buffer-file-name (string-prefix-p source-directory buffer-file-name)) (xref-etags-mode))) (add-hook 'emacs-lisp-mode-hook 'elisp-maybe-turn-on-xref-etags-mode) Which part of it was hard? > Once again, if you can show a complete Lisp to try, I will. To my knowledge, #41 was/is quite complete. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 22 13:02:26 2015 Received: (at 19466) by debbugs.gnu.org; 22 Jan 2015 18:02:26 +0000 Received: from localhost ([127.0.0.1]:53200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEM5J-0005ar-Mt for submit@debbugs.gnu.org; Thu, 22 Jan 2015 13:02:26 -0500 Received: from mtaout24.012.net.il ([80.179.55.180]:42949) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEM5H-0005ab-Nb for 19466@debbugs.gnu.org; Thu, 22 Jan 2015 13:02:24 -0500 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NIL00D00AQ55000@mtaout24.012.net.il> for 19466@debbugs.gnu.org; Thu, 22 Jan 2015 19:54:10 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIL0041TB29F3A0@mtaout24.012.net.il>; Thu, 22 Jan 2015 19:54:10 +0200 (IST) Date: Thu, 22 Jan 2015 20:02:16 +0200 From: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions In-reply-to: <54C063E3.8020401@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Gutov Message-id: <83a91avglz.fsf@gnu.org> References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> <54BEBF63.9050709@yandex.ru> <8361c0w16n.fsf@gnu.org> <54C063E3.8020401@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19466 Cc: rudalics@gmx.at, eller.helmut@gmail.com, 19466@debbugs.gnu.org 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: 1.0 (+) > Date: Thu, 22 Jan 2015 04:43:47 +0200 > From: Dmitry Gutov > CC: rudalics@gmx.at, 19466@debbugs.gnu.org, eller.helmut@gmail.com > > On 01/21/2015 06:25 PM, Eli Zaretskii wrote: > > > Can the package that uses xref modify that string? If so, we don't > > need a single-fits-all phrase. > > It can't, right now. But it would have to be modified by the used > command (find-definitions/references/apropos), not the package. > > > If we do need a single phrase, then how about "go to > > definition/reference"? > > I've settled on "follow reference" for now. Probably good enough, thanks. > AFAICS you've pretty much stopped formulating the requirements at "there > should be a way to use the tags.el backend instead of the major mode's > backend". Not really, I think that was Stefan's proposal. What I need is a way to find definitions of both C and Lisp symbols (functions, macros, struct's, etc.) irrespective of the current buffer's major mode. If xref can do that, it's fine with me. > > If you can show me the complete Lisp, I can try that and return > > feedback. > > That would be good, but unless you declare one of them good enough, > participation in the technical discussion will also be needed. > > >> Messages 32 and 41 include functional implementations you can try. The > >> patches that would go into Emacs won't be much different, we'd just have > >> to decide on code organization. > > > > The recipe in #32 is clearly incomplete. Not sure about 41. > > It's only incomplete because I expected you'd be able to turn on the > minor mode defined there yourself, in any Emacs Lisp buffers you like. > > Here's the "missing piece" for #32: > > (defun elisp-maybe-turn-on-xref-etags-mode () > (when (and buffer-file-name > (string-prefix-p source-directory buffer-file-name)) > (xref-etags-mode))) > > (add-hook 'emacs-lisp-mode-hook 'elisp-maybe-turn-on-xref-etags-mode) > > Which part of it was hard? > > > Once again, if you can show a complete Lisp to try, I will. > > To my knowledge, #41 was/is quite complete. I will try those when I have time, thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 22 13:23:08 2015 Received: (at 19466) by debbugs.gnu.org; 22 Jan 2015 18:23:08 +0000 Received: from localhost ([127.0.0.1]:53222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEMPL-0007U1-SJ for submit@debbugs.gnu.org; Thu, 22 Jan 2015 13:23:08 -0500 Received: from mout.gmx.net ([212.227.17.22]:49328) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEMPJ-0007TM-HL for 19466@debbugs.gnu.org; Thu, 22 Jan 2015 13:23:06 -0500 Received: from [178.191.140.119] ([178.191.140.119]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LfYqz-1XuMVs3x3h-00p8F2; Thu, 22 Jan 2015 19:22:50 +0100 Message-ID: <54C13FF0.8050307@gmx.at> Date: Thu, 22 Jan 2015 19:22:40 +0100 From: martin rudalics MIME-Version: 1.0 To: Stefan Monnier Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <54BD076E.6090707@yandex.ru> <54BE0B5A.6060706@gmx.at> <54BE4693.5050804@yandex.ru> <54BE6B59.5090404@gmx.at> <54BF5345.9090303@yandex.ru> <54BF843E.10907@gmx.at> <54BFB6A1.8050802@yandex.ru> <54BFD9AF.10002@gmx.at> <54BFE933.9090009@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:LTJE7epYc1V8np4/PodXBzvBU1sblDnOxGVReQe53zK+KoGJaLl jT2LqYYIKZUcIkiw4JWCd7v4mYVG+TsSUdgduSaq/iy2MDko4+vnWFo/fXjUslfCoXtQmRG kSgw0T48blkMfKUIrjgqVBwdeXJVJLREX+1EfYoALW8YeYbcYeLn+hWkvVQThDR8axCPNV5 JH9+13Z4SEnoY1zk5GsUA== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Eli Zaretskii , Helmut Eller , Dmitry Gutov 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 (/) >>>>> Debugger entered--Lisp error: (args-out-of-range "" 0) >>>>> help-function-arglist(#[257 "\300\207" ["(No location)"] 2 "(No >>>>> location)\n\n(fn ##)"] preserve-names) >>>>> eieio--defmethod(xref-location-group nil xref-bogus-location #[257 >>>>> "\300\207" ["(No location)"] 2 "(No location)\n\n(fn ##)"]) >>>> I'm sure Someone(tm) will fix that right away. :) > > Sorry, I missed this. When/how do you get this error? Never mind. You fixed it already ;-) > There are two problems here: > 1- The warnings fail to include the "xref.el:: " prefix. > Haven't figured out why yet. If someone wants to help fix this, he'd > be very welcome. The problem seems to happen only when > macroexp--warn-and-return is used on a toplevel form (aka > "file-form"). The warnings themselves are otherwise correct (and > "harmless"). > 2- xref.el (just like pretty much all existing code using EIEIO) uses > obsolete macros, indeed. This is easy to fix. These have been fixed as well. Thanks, martin From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 22 13:23:19 2015 Received: (at 19466) by debbugs.gnu.org; 22 Jan 2015 18:23:19 +0000 Received: from localhost ([127.0.0.1]:53225 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEMPW-0007UQ-Fi for submit@debbugs.gnu.org; Thu, 22 Jan 2015 13:23:18 -0500 Received: from mout.gmx.net ([212.227.17.22]:63952) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEMPU-0007UC-Mk for 19466@debbugs.gnu.org; Thu, 22 Jan 2015 13:23:17 -0500 Received: from [178.191.140.119] ([178.191.140.119]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MIPhr-1YHx2Z2ngl-004CZ8; Thu, 22 Jan 2015 19:23:08 +0100 Message-ID: <54C14002.9020803@gmx.at> Date: Thu, 22 Jan 2015 19:22:58 +0100 From: martin rudalics MIME-Version: 1.0 To: Dmitry Gutov , Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <54BD076E.6090707@yandex.ru> <54BE0B5A.6060706@gmx.at> <54BE4693.5050804@yandex.ru> <54BE6B59.5090404@gmx.at> <54BF5345.9090303@yandex.ru> <54BF843E.10907@gmx.at> <54BFB6A1.8050802@yandex.ru> <54BFD9AF.10002@gmx.at> <54C05FEB.1090601@yandex.ru> In-Reply-To: <54C05FEB.1090601@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:N4xak3S96n/HlrgjoLDzFZkSXmDVxxY+UtkNNO7MW/hbScOTT+V xm7Qx/4ey0gI5/lt6/Arw5Lndg9WznbdSV72wkapG5TyEBamPrS+k78nEGHjjzx3yoLfVX/ U9tGAZOcKvUj9DQZojbaYtcx4wcgH+RbRYtvAWFcowMN8aSkAzQw6HQeFeS/E/uafNaIdGY nFJNyEUrE9X0gclhT5h4A== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Helmut Eller 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 (/) > Anyway, xref--current seems good enough. It's OK now. > I've updated it in that direction. OK as well. >> When xref prompts me with >> >> Find definitions of: >> >> I'd expect to be able to browse my history of definitions I tried or >> succeeded to find. > > This should work now. It does. Thanks, martin From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 22 16:02:36 2015 Received: (at 19466) by debbugs.gnu.org; 22 Jan 2015 21:02:36 +0000 Received: from localhost ([127.0.0.1]:53286 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEOtf-00035X-Dd for submit@debbugs.gnu.org; Thu, 22 Jan 2015 16:02:35 -0500 Received: from mail-we0-f176.google.com ([74.125.82.176]:53938) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEOtc-00035H-Kv for 19466@debbugs.gnu.org; Thu, 22 Jan 2015 16:02:33 -0500 Received: by mail-we0-f176.google.com with SMTP id w62so4093536wes.7 for <19466@debbugs.gnu.org>; Thu, 22 Jan 2015 13:02:26 -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=m2P4z6x7mRs+4tapjsgCv7+rguQeCGZm5jMsjiIGACU=; b=U/O57IcKZWCpeGNrSMAX9s8k2C+3CJ1wqOQ7+Qdwq3PeK41S047xcBgCAtWwRq7Fdi XxNHStEL0KLB53cnf/CxLidPMLmzTF1J014jMUF2a4XGWyVKOS0iFcqb1pnMRcAX6dzm 5/6L6BQ4BKj41BU9skJUfNkx/TvGXNLzFurtho+fqfFE/mr7MvYIyTU3xLEvPGvBYdBC zJgBZey6YUtn0ByZabkDRG10GrkY4WAcX9CzM5U/tl4rpAu+OrFrgnooI8sps6B1TP2N Lhz2SF2YdxFo/3NnqRLJUDXvrayTUjXcwnbR5l3a3+5x5cbSJ05JmhKbqAd57NW8KfJJ wzWg== X-Received: by 10.181.29.201 with SMTP id jy9mr8855609wid.17.1421960546875; Thu, 22 Jan 2015 13:02:26 -0800 (PST) Received: from [192.168.1.3] ([82.102.93.54]) by mx.google.com with ESMTPSA id s9sm277003wiz.12.2015.01.22.13.02.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Jan 2015 13:02:26 -0800 (PST) Message-ID: <54C1655E.4050403@yandex.ru> Date: Thu, 22 Jan 2015 23:02: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 To: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> <54BEBF63.9050709@yandex.ru> <8361c0w16n.fsf@gnu.org> <54C063E3.8020401@yandex.ru> <83a91avglz.fsf@gnu.org> In-Reply-To: <83a91avglz.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: rudalics@gmx.at, eller.helmut@gmail.com, 19466@debbugs.gnu.org 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/22/2015 08:02 PM, Eli Zaretskii wrote: > What I need is a way to find definitions of both C and Lisp symbols > (functions, macros, struct's, etc.) irrespective of the current > buffer's major mode. If xref can do that, it's fine with me. Would it also be irrespective of the current file, or its project? Would it not depend on major mode at all, so it would also be true in help-mode and similar buffers? If you want it in all major modes, you can use find-file-hook instead of emacs-lisp-mode-hook. If in all files everywhere, then you can also drop the buffer-file-name check, ending up with (add-hook 'find-file-hook #'xref-etags-mode t) That doesn't help with non-file buffers, though. But you can use a separate major mode hook for each. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 23 04:03:49 2015 Received: (at 19466) by debbugs.gnu.org; 23 Jan 2015 09:03:49 +0000 Received: from localhost ([127.0.0.1]:53475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEa9d-0005sH-6U for submit@debbugs.gnu.org; Fri, 23 Jan 2015 04:03:49 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:62883) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEa9Z-0005rn-Nk for 19466@debbugs.gnu.org; Fri, 23 Jan 2015 04:03:47 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NIM00D00GZDRI00@a-mtaout20.012.net.il> for 19466@debbugs.gnu.org; Fri, 23 Jan 2015 11:03:13 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIM00DNPH5CQN20@a-mtaout20.012.net.il>; Fri, 23 Jan 2015 11:03:13 +0200 (IST) Date: Fri, 23 Jan 2015 11:03:14 +0200 From: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions In-reply-to: <54C1655E.4050403@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Gutov Message-id: <83r3uluawd.fsf@gnu.org> References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> <54BEBF63.9050709@yandex.ru> <8361c0w16n.fsf@gnu.org> <54C063E3.8020401@yandex.ru> <83a91avglz.fsf@gnu.org> <54C1655E.4050403@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19466 Cc: rudalics@gmx.at, eller.helmut@gmail.com, 19466@debbugs.gnu.org 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: 1.0 (+) > Date: Thu, 22 Jan 2015 23:02:22 +0200 > From: Dmitry Gutov > CC: rudalics@gmx.at, 19466@debbugs.gnu.org, eller.helmut@gmail.com > > On 01/22/2015 08:02 PM, Eli Zaretskii wrote: > > > What I need is a way to find definitions of both C and Lisp symbols > > (functions, macros, struct's, etc.) irrespective of the current > > buffer's major mode. If xref can do that, it's fine with me. > > Would it also be irrespective of the current file, or its project? Most, if not all, projects I work on aren't "projects" in your sense of the word, I think -- they lack any "project" files except the sources and Makefile's. With etags, I switch "projects" by invoking visit-tags-table and typing a name of a different TAGS file (I'm then given a choice of whether to keep the previous TAGS table or discard it, which is important -- see below). If xref can reliably deduce that I switched projects and automatically update its database, that's fine with me, and would probably constitute what you mean by "dependence on the current file or project". But I doubt that this can be done reliably enough to satisfy users like me, when a project doesn't have a definitive description of what is or isn't part of it. Take, for example, the use case where I'm testing a program and found a bug. I then need to be able to quickly find and examine the definition of symbols that might be involved in the bug, look at their code, perhaps make some changes -- this all will be served well by using the database (such as TAGS) of that single program. But suppose I now come to the conclusion that the bug is not in the program per se, but involves one of the external libraries it uses. Now I need to go through the sources of that library (whose sources, by sheer luck or maybe something else, I already have available on my system). How would xref or etags know whether I switched to that library as part of my previous work (and therefore still need access to the previous project's symbols), or because I'm now working on an entirely different project? What if investigating the bug needs to intermittently look at the sources of the program and the library (e.g., because the bug happens due to some incompatibility between them)? So I think there will always be a need for asking the user about this, and in addition there are projects without "project" infrastructure, where xref or etags or any similar feature will have to rely on the user for telling them which database of symbols to use. Is xref ready for these use cases? If so, in what form (simple variable customizations, specified commands, Lisp code that the use must supply, something else) can the user specify what she wants? > Would it not depend on major mode at all, so it would also be true > in help-mode and similar buffers? Sometimes, I guess. Like doing that in *scratch* after "emacs -Q", or in the *Help* buffer (which sometimes refers to external library functions). > If you want it in all major modes, you can use find-file-hook instead of > emacs-lisp-mode-hook. If in all files everywhere, then you can also drop > the buffer-file-name check, ending up with > > (add-hook 'find-file-hook #'xref-etags-mode t) > > That doesn't help with non-file buffers, though. But you can use a > separate major mode hook for each. Is it possible to turn on xref-etags-mode (or its equivalents) globally? Are there any disadvantages of that? IOW, why does it need to be turned on by a hook? From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 23 12:34:58 2015 Received: (at 19466) by debbugs.gnu.org; 23 Jan 2015 17:34:58 +0000 Received: from localhost ([127.0.0.1]:54560 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEi8G-0006nd-P7 for submit@debbugs.gnu.org; Fri, 23 Jan 2015 12:34:57 -0500 Received: from mail-wi0-f182.google.com ([209.85.212.182]:38721) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEi8E-0006nO-1T for 19466@debbugs.gnu.org; Fri, 23 Jan 2015 12:34:54 -0500 Received: by mail-wi0-f182.google.com with SMTP id n3so4388476wiv.3 for <19466@debbugs.gnu.org>; Fri, 23 Jan 2015 09:34:47 -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=t7wOH8ODAF1hVdmIx7XjIP9HEM4zDC8hTQpW86y/eQo=; b=VFtgp6GzDRIlxHKp4YJF61ve+95RP9I4dXvAK57ZMxhsseV26KL2GZmWHyy4K0rrnh /Flu1yPr2vfvGpV6c5O7FvLJ+7wPiFEGSu9oFbh7LeD/aXakzlqbWqeYCq1KB/XHutOU ERDEm5HC1pD0eVPD3hGjSMnSAfzdnShaBd5csXXJB2Z9SFbH1sYRcl4Ey1vH0c8MXbrb weNTWflFeVDsxeJgd4i1BUvq7xXODKQ1Ue/6YEGHvkyQ2ZKP3YEH6nM1lmS4lGFojs6O R0EXmlx6idxLcgeyjAUWVwGW2UBBrubzwsciC6eJ6PagRGwmVP9MMaWzJ/xKc57EqWS6 nylA== X-Received: by 10.194.81.104 with SMTP id z8mr16145446wjx.45.1422034487731; Fri, 23 Jan 2015 09:34:47 -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 gm10sm2645630wib.19.2015.01.23.09.34.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Jan 2015 09:34:47 -0800 (PST) Message-ID: <54C28635.8070606@yandex.ru> Date: Fri, 23 Jan 2015 19:34:45 +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 To: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> <54BEBF63.9050709@yandex.ru> <8361c0w16n.fsf@gnu.org> <54C063E3.8020401@yandex.ru> <83a91avglz.fsf@gnu.org> <54C1655E.4050403@yandex.ru> <83r3uluawd.fsf@gnu.org> In-Reply-To: <83r3uluawd.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: rudalics@gmx.at, eller.helmut@gmail.com, 19466@debbugs.gnu.org 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/23/2015 11:03 AM, Eli Zaretskii wrote: > Most, if not all, projects I work on aren't "projects" in your sense > of the word, I think -- they lack any "project" files except the > sources and Makefile's. A top Makefile is enough for me, conceptually. > With etags, I switch "projects" by invoking > visit-tags-table and typing a name of a different TAGS file (I'm then > given a choice of whether to keep the previous TAGS table or discard > it, which is important -- see below). I would consider this you adapting to Emacs's lack of support for projects: many people like to have commands that work on the "current project" (find-file, replace, etc), and depend on which buffer you're currently in. But anyway... > If xref can reliably deduce that I switched projects and automatically > update its database, that's fine with me, and would probably > constitute what you mean by "dependence on the current file or > project". There's no single database. If you're using the etags backend, it should be just as affected by `M-x visit-tags-table', as `find-tag' is. So that should be good enough. > Take, for example, the use case where I'm testing a program and found > a bug. I then need to be able to quickly find and examine the > definition of symbols that might be involved in the bug, look at their > code, perhaps make some changes -- this all will be served well by > using the database (such as TAGS) of that single program. But suppose > I now come to the conclusion that the bug is not in the program per > se, but involves one of the external libraries it uses. Now I need to > go through the sources of that library (whose sources, by sheer luck > or maybe something else, I already have available on my system). How > would xref or etags know whether I switched to that library as part of > my previous work (and therefore still need access to the previous > project's symbols), or because I'm now working on an entirely > different project? What if investigating the bug needs to > intermittently look at the sources of the program and the library > (e.g., because the bug happens due to some incompatibility between > them)? Honestly, I would probably run two instances of Emacs. But the tags-file-name/tags-table-list approach should still work, as long as the etags backend is used. Note that currently the only thing that depends on a specific buffer is the backend used. And the only buffers that use the non-default value now are in emacs-lisp-mode or its derivatives. Until that changes, applying either of the code samples I presented should give you find-tag-ish behavior everywhere. So I was a bit too alarmist about you having to use find-file-hook and different major mode hooks.... yet. > So I think there will always be a need for asking the user about this, > and in addition there are projects without "project" infrastructure, > where xref or etags or any similar feature will have to rely on the > user for telling them which database of symbols to use. A project infrastructure should take priority over this. For instance, how the current Projectile users switch to a file in a "different project"? They call `M-x projectile-switch-project', pick one from the cached list of projects, and then `M-x projectile-find-file' in the resulting buffer. I believe this kind of workflow scales better. The logic behind determining the current project is entirely configurable, so there's no reason why a directory with a Makefile can't be considered a project, if the user is so inclined. > Is xref ready for these use cases? If so, in what form (simple > variable customizations, specified commands, Lisp code that the use > must supply, something else) can the user specify what she wants? If they really want to, using simple functions and major mode hooks. Maybe minor modes. As you've seen, the code to "get back to using etags" is trivial. >> Would it not depend on major mode at all, so it would also be true >> in help-mode and similar buffers? > > Sometimes, I guess. Like doing that in *scratch* after "emacs -Q", or > in the *Help* buffer (which sometimes refers to external library > functions). Right. You'll only need to worry about help-mode buffers after someone writes dedicated xref support for it, and if you want to ignore their effors (just like it seems elisp-xref-find is not valuable for you). > Is it possible to turn on xref-etags-mode (or its equivalents) > globally? It's "turned on" by default. All it does is restore the default values of two variables, to get back to the default behavior in emacs-lisp-mode buffers. (I don't understand why this is not blindingly obvious from looking at those several lines.) > Are there any disadvantages of that? The find-func package is generally considered better and easier for Emacs Lisp navigation than etags. It's more precise, it distinguishes between different kinds of symbols, AND it can easily visit definitions from third-party code loaded in user's Emacs. The one downside (it won't offer non-autoloaded symbols from not loaded packages) doesn't seems to be a real problem in practice. Compared to etags, it also won't jump to the C functions that are not exposed to Emacs Lisp. The overwhelming majority of our users (myself probably included), won't ever need this. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 23 16:04:06 2015 Received: (at 19466) by debbugs.gnu.org; 23 Jan 2015 21:04:06 +0000 Received: from localhost ([127.0.0.1]:54612 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YElOf-0004hp-4C for submit@debbugs.gnu.org; Fri, 23 Jan 2015 16:04:05 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:44906) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YElOb-0004hL-Mh for 19466@debbugs.gnu.org; Fri, 23 Jan 2015 16:04:03 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NIN00I00ECQ9600@a-mtaout20.012.net.il> for 19466@debbugs.gnu.org; Fri, 23 Jan 2015 23:03:55 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIN00IQVEII2Z70@a-mtaout20.012.net.il>; Fri, 23 Jan 2015 23:03:55 +0200 (IST) Date: Fri, 23 Jan 2015 23:03:57 +0200 From: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions In-reply-to: <54C28635.8070606@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Gutov Message-id: <83twzhryyq.fsf@gnu.org> References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> <54BEBF63.9050709@yandex.ru> <8361c0w16n.fsf@gnu.org> <54C063E3.8020401@yandex.ru> <83a91avglz.fsf@gnu.org> <54C1655E.4050403@yandex.ru> <83r3uluawd.fsf@gnu.org> <54C28635.8070606@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19466 Cc: rudalics@gmx.at, eller.helmut@gmail.com, 19466@debbugs.gnu.org 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: 1.0 (+) > Date: Fri, 23 Jan 2015 19:34:45 +0200 > From: Dmitry Gutov > CC: rudalics@gmx.at, 19466@debbugs.gnu.org, eller.helmut@gmail.com > > On 01/23/2015 11:03 AM, Eli Zaretskii wrote: > > > Most, if not all, projects I work on aren't "projects" in your sense > > of the word, I think -- they lack any "project" files except the > > sources and Makefile's. > > A top Makefile is enough for me, conceptually. I didn't mean conceptually, I meant in practice. Collecting all the bits and pieces of a project scattered across many Makefile's in a large tree is not an easy task. It's little wonder most if not all "project systems" use a single file to describe the entire project workspace. > > With etags, I switch "projects" by invoking > > visit-tags-table and typing a name of a different TAGS file (I'm then > > given a choice of whether to keep the previous TAGS table or discard > > it, which is important -- see below). > > I would consider this you adapting to Emacs's lack of support for > projects: many people like to have commands that work on the "current > project" (find-file, replace, etc), and depend on which buffer you're > currently in. But anyway... I also like commands that work on the current project, I just don't like them to depend too much on the current buffer. E.g., I have a habit of switching to *scratch* quite often and leave random notes there, or text I'd like to have at my fingertips. That doesn't mean that when I'm in *scratch* I'm not working on the same project I was a minute ago and need to be able to access the same symbols. IOW, I find it hard to believe Emacs can be smart enough to know when I switch projects; at best it could employ some heuristics to offer me that for confirmation. Realistically, we need a command to switch to another project, and xref should plug into it, instead of trying to second-guess what I want. > > If xref can reliably deduce that I switched projects and automatically > > update its database, that's fine with me, and would probably > > constitute what you mean by "dependence on the current file or > > project". > > There's no single database. It doesn't matter if there's one or many. The important part is that the active one(s) need to be switched when I change to another project, and otherwise kept until I say-so. > If you're using the etags backend, it should be just as affected by > `M-x visit-tags-table', as `find-tag' is. I don't understand what that means, sorry. find-tag cannot work without me visiting a TAGS table. > > Take, for example, the use case where I'm testing a program and found > > a bug. I then need to be able to quickly find and examine the > > definition of symbols that might be involved in the bug, look at their > > code, perhaps make some changes -- this all will be served well by > > using the database (such as TAGS) of that single program. But suppose > > I now come to the conclusion that the bug is not in the program per > > se, but involves one of the external libraries it uses. Now I need to > > go through the sources of that library (whose sources, by sheer luck > > or maybe something else, I already have available on my system). How > > would xref or etags know whether I switched to that library as part of > > my previous work (and therefore still need access to the previous > > project's symbols), or because I'm now working on an entirely > > different project? What if investigating the bug needs to > > intermittently look at the sources of the program and the library > > (e.g., because the bug happens due to some incompatibility between > > them)? > > Honestly, I would probably run two instances of Emacs. Blasphemy ;-) Seriously, though: I very much hope this was a semi-joke, because we really don't want asking users to do that. A single instance of Emacs should be able to cope with such a simple task. FWIW, I regularly have about a dozen projects in my Emacs session, and switch between them quite a lot. > But the tags-file-name/tags-table-list approach should still work, > as long as the etags backend is used. I thought you were asking whether I must stick to etags, and was trying to explain which features I need to have, not necessarily in etags. If the only conclusion from this discussion is that I must stick to etags or give up on features that it has been offering for years, then I'm sorry to say that xref doesn't seem progress to me. > Note that currently the only thing that depends on a specific buffer is > the backend used. I fail to understand the rationale behind such a design. As long as we are talking about buffers that hold source code of some programming language, why would it be a good idea to switch backends depending on the buffer? > > So I think there will always be a need for asking the user about this, > > and in addition there are projects without "project" infrastructure, > > where xref or etags or any similar feature will have to rely on the > > user for telling them which database of symbols to use. > > A project infrastructure should take priority over this. For instance, > how the current Projectile users switch to a file in a "different > project"? They call `M-x projectile-switch-project', pick one from the > cached list of projects, and then `M-x projectile-find-file' in the > resulting buffer. I believe this kind of workflow scales better. projectile-switch-project is conceptually the same as visit-tags-table, so I see no difference. Not sure what kind of scaling is being alluded to here; in any case, I wasn't talking about finding files, although TAGS allow that as well (I never used that feature of etags). > The logic behind determining the current project is entirely > configurable, so there's no reason why a directory with a Makefile can't > be considered a project, if the user is so inclined. That's not the issue. The issue is that the logic behind determining the current project cannot be reliable enough to decide for the user which collection(s) of symbols are of interest to me at any given time. Only the user knows that. Unlike some other heuristics, where it's okay to have an imperfect success rate, in this case it's terribly annoying when Emacs refuses to admit that a symbol exists and show it to you, when you _know_ for sure it does exist. This kind of annoyance _will_ happen if you rely on automated logic for deciding which symbols are or aren't relevant. > > Is xref ready for these use cases? If so, in what form (simple > > variable customizations, specified commands, Lisp code that the use > > must supply, something else) can the user specify what she wants? > > If they really want to, using simple functions and major mode hooks. > Maybe minor modes. As you've seen, the code to "get back to using etags" > is trivial. That's not user-level customization. It's too complex to be that. We need simpler, higher-level customizations. > > Is it possible to turn on xref-etags-mode (or its equivalents) > > globally? > > It's "turned on" by default. Then why did you propose to use hooks? > Compared to etags, it also won't jump to the C functions that are not > exposed to Emacs Lisp. The overwhelming majority of our users (myself > probably included), won't ever need this. You can't build useful features on such assumptions. Btw, this mode of work, in more than one language, is not limited to Emacs. You will see it in Guile, in Python, in Awk, in GDB, and in many other places. It begins to be the rule rather than exception these days. It's not good if Emacs will ask developers to jump through hoops to support that. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 23 16:16:24 2015 Received: (at 19466) by debbugs.gnu.org; 23 Jan 2015 21:16:24 +0000 Received: from localhost ([127.0.0.1]:54621 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YElaa-0004zk-5I for submit@debbugs.gnu.org; Fri, 23 Jan 2015 16:16:24 -0500 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:35585) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YElaQ-0004zU-K5 for 19466@debbugs.gnu.org; Fri, 23 Jan 2015 16:16:22 -0500 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 5A5028514C; Fri, 23 Jan 2015 16:16:14 -0500 (EST) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 62BB91E5B8B; Fri, 23 Jan 2015 16:15:49 -0500 (EST) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 46D79B4102; Fri, 23 Jan 2015 16:15:49 -0500 (EST) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions Message-ID: References: <8361cucl3u.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> <54BEBF63.9050709@yandex.ru> <8361c0w16n.fsf@gnu.org> <54C063E3.8020401@yandex.ru> <83a91avglz.fsf@gnu.org> <54C1655E.4050403@yandex.ru> <83r3uluawd.fsf@gnu.org> <54C28635.8070606@yandex.ru> Date: Fri, 23 Jan 2015 16:15:49 -0500 In-Reply-To: <54C28635.8070606@yandex.ru> (Dmitry Gutov's message of "Fri, 23 Jan 2015 19:34:45 +0200") 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-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, Eli Zaretskii , eller.helmut@gmail.com 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 (--) >> If xref can reliably deduce that I switched projects and automatically >> update its database, that's fine with me, and would probably >> constitute what you mean by "dependence on the current file or >> project". Right, ideally that's what tags.el should do: it should associate a "file-system area" to each TAGS file; so it can know automatically which TAGS file to use based on default-directory. Whether it then keeps several TAGS file opened at the same time, or whether it only keeps a single-one-at-a-time (and reloads the other when you move to a buffer that belongs to a different project) is just an implementation detail. >> Take, for example, the use case where I'm testing a program and found >> a bug. I then need to be able to quickly find and examine the >> definition of symbols that might be involved in the bug, look at their >> code, perhaps make some changes -- this all will be served well by >> using the database (such as TAGS) of that single program. But suppose >> I now come to the conclusion that the bug is not in the program per >> se, but involves one of the external libraries it uses. Now I need to >> go through the sources of that library (whose sources, by sheer luck >> or maybe something else, I already have available on my system). How >> would xref or etags know whether I switched to that library as part of >> my previous work (and therefore still need access to the previous >> project's symbols), or because I'm now working on an entirely >> different project? It wouldn't and it would only give you access to the identifiers of the project to which the current-buffer belongs. So if you use M-. from a file in the buggy library it's use the TAGS file of that library, and if you then go to a different buffer belonging to your program and use M-. xref should then use the TAGS file of that program. I.e. you tell Emacs which TAGS file to use by selecting an appropriate buffer before you hit M-. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 23 16:34:13 2015 Received: (at 19466) by debbugs.gnu.org; 23 Jan 2015 21:34:13 +0000 Received: from localhost ([127.0.0.1]:54642 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YElro-0006nh-Oe for submit@debbugs.gnu.org; Fri, 23 Jan 2015 16:34:13 -0500 Received: from mtaout29.012.net.il ([80.179.55.185]:49727) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YElrl-0006nT-UR for 19466@debbugs.gnu.org; Fri, 23 Jan 2015 16:34:11 -0500 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NIN00700FQNYT00@mtaout29.012.net.il> for 19466@debbugs.gnu.org; Fri, 23 Jan 2015 23:30:38 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIN00M41FR2QO80@mtaout29.012.net.il>; Fri, 23 Jan 2015 23:30:38 +0200 (IST) Date: Fri, 23 Jan 2015 23:34:05 +0200 From: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83oapprxki.fsf@gnu.org> References: <8361cucl3u.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> <54BEBF63.9050709@yandex.ru> <8361c0w16n.fsf@gnu.org> <54C063E3.8020401@yandex.ru> <83a91avglz.fsf@gnu.org> <54C1655E.4050403@yandex.ru> <83r3uluawd.fsf@gnu.org> <54C28635.8070606@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, eller.helmut@gmail.com, dgutov@yandex.ru 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: 1.0 (+) > From: Stefan Monnier > Cc: Eli Zaretskii , eller.helmut@gmail.com, 19466@debbugs.gnu.org > Date: Fri, 23 Jan 2015 16:15:49 -0500 > > >> If xref can reliably deduce that I switched projects and automatically > >> update its database, that's fine with me, and would probably > >> constitute what you mean by "dependence on the current file or > >> project". > > Right, ideally that's what tags.el should do: it should associate > a "file-system area" to each TAGS file; so it can know automatically > which TAGS file to use based on default-directory. It does (try "M-x visit-tags-table" and you will see that the default it suggests is like you say). It just doesn't automatically load TAGS, because the fact that I am in some buffer doesn't yet mean that I'm working on that buffer's project and need its TAGS. > Whether it then keeps several TAGS file opened at the same time, or > whether it only keeps a single-one-at-a-time (and reloads the other > when you move to a buffer that belongs to a different project) is just > an implementation detail. The important part is that it allows me to keep or discard portions of the tags table. _That_ is certainly NOT an implementation detail. > >> Take, for example, the use case where I'm testing a program and found > >> a bug. I then need to be able to quickly find and examine the > >> definition of symbols that might be involved in the bug, look at their > >> code, perhaps make some changes -- this all will be served well by > >> using the database (such as TAGS) of that single program. But suppose > >> I now come to the conclusion that the bug is not in the program per > >> se, but involves one of the external libraries it uses. Now I need to > >> go through the sources of that library (whose sources, by sheer luck > >> or maybe something else, I already have available on my system). How > >> would xref or etags know whether I switched to that library as part of > >> my previous work (and therefore still need access to the previous > >> project's symbols), or because I'm now working on an entirely > >> different project? > > It wouldn't and it would only give you access to the identifiers of the > project to which the current-buffer belongs. So if you use M-. from > a file in the buggy library it's use the TAGS file of that library, and > if you then go to a different buffer belonging to your program and use > M-. xref should then use the TAGS file of that program. I.e. you tell > Emacs which TAGS file to use by selecting an appropriate buffer before > you hit M-. So you are saying that when I'm in some buffer, I cannot look at some of the identifiers until I switch to another buffer? That's very inconvenient. Again, when I work on a problem that happens between a program and a library, I need to see both sides of the interface at the same time, independently of which buffer I am in. Conceptually, the set of identifiers that are relevant to me in this situation is the union of both projects, and I should be able to find any identifier from this union no matter which buffer is the current one. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 23 17:23:34 2015 Received: (at 19466) by debbugs.gnu.org; 23 Jan 2015 22:23:34 +0000 Received: from localhost ([127.0.0.1]:54673 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEmda-0007zH-64 for submit@debbugs.gnu.org; Fri, 23 Jan 2015 17:23:34 -0500 Received: from mail-we0-f170.google.com ([74.125.82.170]:48841) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEmdY-0007z3-5T for 19466@debbugs.gnu.org; Fri, 23 Jan 2015 17:23:32 -0500 Received: by mail-we0-f170.google.com with SMTP id x3so28384wes.1 for <19466@debbugs.gnu.org>; Fri, 23 Jan 2015 14:23:26 -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=cxsFxsM7zjxjwg3kTvNnRGVq9VPr0Byre+ooSd1xW8c=; b=Gq6H+N7yWdEvFiDR6dvgI2IS3W3sjYDwialJ3FRIZb7zVWRVifkdsM7J3MsHAkn4jt YKs+83OA5qyk0PVEf4em8pRLNjbaBFEIcccgD9m7o6m0NCk/eRcyL8dhe7RnPM4hLBmm C37Dp6fLFcWCmIjkUpOFsY61opVEf0qRxAPUz5CacWyKFgyj0W1F/MaxPtwdyfKcYy1I d8HPdMiotSNRswhtKvNQRBlbWdP8VJIl4V1vbCsnBNyck9IooqPeInOqYsyiAuzlOtBR dxlCbZP29HfZce49RApAJKAd9kHGbbPhDmwdqzo3HBX/Hs69KhlnT2V0W+UX6jW08aoU Zo8A== X-Received: by 10.180.109.79 with SMTP id hq15mr8099410wib.47.1422051806569; Fri, 23 Jan 2015 14:23:26 -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 k1sm3887398wjn.9.2015.01.23.14.23.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Jan 2015 14:23:25 -0800 (PST) Message-ID: <54C2C9DC.1050908@yandex.ru> Date: Sat, 24 Jan 2015 00:23: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 To: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> <54BEBF63.9050709@yandex.ru> <8361c0w16n.fsf@gnu.org> <54C063E3.8020401@yandex.ru> <83a91avglz.fsf@gnu.org> <54C1655E.4050403@yandex.ru> <83r3uluawd.fsf@gnu.org> <54C28635.8070606@yandex.ru> <83twzhryyq.fsf@gnu.org> In-Reply-To: <83twzhryyq.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, eller.helmut@gmail.com 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/23/2015 11:03 PM, Eli Zaretskii wrote: > I also like commands that work on the current project, I just don't > like them to depend too much on the current buffer. To cut this part of discussion short, yes, the project system can well be designed so that the "current project" depends not on the current buffer but on the user's choice. So to switch between projects, you invoke an explicit command, but don't visit a buffer belonging to the other project. And xref can work with such a system (just as it works with etags) without significant problems. > Realistically, we need a command to switch to > another project, and xref should plug into it, instead of trying to > second-guess what I want. Instead of xref plugging into whatever, any project system (which I'm assuming is implemented as a minor mode) can plug into xref and set up xref-find-function, etc, to use itself. > It doesn't matter if there's one or many. The important part is that > the active one(s) need to be switched when I change to another > project, and otherwise kept until I say-so. That depends on the backend's implementation. etags works that way. >> If you're using the etags backend, it should be just as affected by >> `M-x visit-tags-table', as `find-tag' is. > > I don't understand what that means, sorry. find-tag cannot work > without me visiting a TAGS table. etags-xref-find, likewise, will ask you for the path to the TAGS file, if it's not set yet. > Seriously, though: I very much hope this was a semi-joke, because we > really don't want asking users to do that. A single instance of Emacs > should be able to cope with such a simple task. FWIW, I regularly > have about a dozen projects in my Emacs session, and switch between > them quite a lot. Semi-joke, yes. That's just what I often do to avoid the clutter of buffers opened from different projects. It could work almost as well using different frames, but I'd have to find a way to hide the one frame's file buffers from the other frames. You can continue doing what you've always done, no problem. >> But the tags-file-name/tags-table-list approach should still work, >> as long as the etags backend is used. > > I thought you were asking whether I must stick to etags, and was > trying to explain which features I need to have, not necessarily in > etags. If the only conclusion from this discussion is that I must > stick to etags or give up on features that it has been offering for > years, then I'm sorry to say that xref doesn't seem progress to me. Not at all. When I say "etags backend", I mean "etags backend for xref", since the latter is the subject of our discussion. I think it's high time you've tried the snippets I wrote. >> Note that currently the only thing that depends on a specific buffer is >> the backend used. > > I fail to understand the rationale behind such a design. As long as > we are talking about buffers that hold source code of some programming > language, why would it be a good idea to switch backends depending on > the buffer? You may not like it, but it's the easiest viable approach we can take, and a lot of people find it natural. For instance, both original proposals for the xref implementation used it. However, like I mentioned, when a project system is used, we can use its backend in all project files, and so the backend would depend on the directory you in. But also see my first paragraph in this email. > projectile-switch-project is conceptually the same as > visit-tags-table, so I see no difference. Except it visits the "root file" of the project after switching, and immediately "forgets" the previous project. So it's the kind of design you don't like. It's the most popular project solution for Emacs that I know. > That's not the issue. The issue is that the logic behind determining > the current project cannot be reliable enough to decide for the user > which collection(s) of symbols are of interest to me at any given > time. Only the user knows that. Unlike some other heuristics, where > it's okay to have an imperfect success rate, in this case it's > terribly annoying when Emacs refuses to admit that a symbol exists and > show it to you, when you _know_ for sure it does exist. This kind of > annoyance _will_ happen if you rely on automated logic for deciding > which symbols are or aren't relevant. While I can understand it, that's just your (i.e. not universal) opinion, and I believe it's addressed above. That is, a backend can use this approach as well. > That's not user-level customization. It's too complex to be that. We > need simpler, higher-level customizations. We don't even know what and how to customize yet. It might be time for you to swap the user shoes for the developer shoes. >>> Is it possible to turn on xref-etags-mode (or its equivalents) >>> globally? >> >> It's "turned on" by default. > > Then why did you propose to use hooks? Because emacs-lisp-mode overrides it, and to reach certain level of happiness, you seem to need to revert that override. I believe I've explained that in the previous email, no? >> Compared to etags, it also won't jump to the C functions that are not >> exposed to Emacs Lisp. The overwhelming majority of our users (myself >> probably included), won't ever need this. > > You can't build useful features on such assumptions. I can, and I do. > Btw, this mode of work, in more than one language, is not limited to > Emacs. You will see it in Guile, in Python, in Awk, in GDB, and in > many other places. It begins to be the rule rather than exception > these days. It's not good if Emacs will ask developers to jump > through hoops to support that. You seem to be clamoring for project support in Emacs. That's commendable, and it's a separate discussion. Meanwhile, a lot of features currently depend just on the current major mode and buffer. There's nothing new about it. The easiest example is code completion. In emacs-lisp-mode, it will parse the current buffer context and offer completions from obarray, somewhat filtered. If you have a README in the same directory as foo.el (so we might consider them to be in the same project), when you open it, you definitely won't get the same completions as in emacs-lisp-mode. In fact, if there's no current tags file visited, in the default Emacs configuration you won't get any completions at all. Similarly for python-mode (python-shell-completion-at-point only works in Python buffers, and only when an inferior shell is running). Likewise for Octave, and I just haven't looked at Guile, Awk and GDB support. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 24 04:41:10 2015 Received: (at 19466) by debbugs.gnu.org; 24 Jan 2015 09:41:10 +0000 Received: from localhost ([127.0.0.1]:54806 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YExDI-0000oI-S1 for submit@debbugs.gnu.org; Sat, 24 Jan 2015 04:41:09 -0500 Received: from mtaout26.012.net.il ([80.179.55.182]:55889) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YExDA-0000na-It for 19466@debbugs.gnu.org; Sat, 24 Jan 2015 04:41:02 -0500 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NIO00N00D2A6300@mtaout26.012.net.il> for 19466@debbugs.gnu.org; Sat, 24 Jan 2015 11:40:47 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIO00MZ3DJYEV30@mtaout26.012.net.il>; Sat, 24 Jan 2015 11:40:47 +0200 (IST) Date: Sat, 24 Jan 2015 11:40:57 +0200 From: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions In-reply-to: <54C2C9DC.1050908@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Gutov Message-id: <83h9vgsehi.fsf@gnu.org> References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> <54BEBF63.9050709@yandex.ru> <8361c0w16n.fsf@gnu.org> <54C063E3.8020401@yandex.ru> <83a91avglz.fsf@gnu.org> <54C1655E.4050403@yandex.ru> <83r3uluawd.fsf@gnu.org> <54C28635.8070606@yandex.ru> <83twzhryyq.fsf@gnu.org> <54C2C9DC.1050908@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, eller.helmut@gmail.com 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: 1.0 (+) > Date: Sat, 24 Jan 2015 00:23:24 +0200 > From: Dmitry Gutov > CC: eller.helmut@gmail.com, 19466@debbugs.gnu.org > > On 01/23/2015 11:03 PM, Eli Zaretskii wrote: > > > I also like commands that work on the current project, I just don't > > like them to depend too much on the current buffer. > > To cut this part of discussion short, yes, the project system can well > be designed so that the "current project" depends not on the current > buffer but on the user's choice. So to switch between projects, you > invoke an explicit command, but don't visit a buffer belonging to the > other project. And xref can work with such a system (just as it works > with etags) without significant problems. Can you tell how can this be set up with xref, or point me to the relevant documentation? > > Realistically, we need a command to switch to > > another project, and xref should plug into it, instead of trying to > > second-guess what I want. > > Instead of xref plugging into whatever, any project system (which I'm > assuming is implemented as a minor mode) can plug into xref and set up > xref-find-function, etc, to use itself. Any of these two will do (a plug has 2 parts). > > It doesn't matter if there's one or many. The important part is that > > the active one(s) need to be switched when I change to another > > project, and otherwise kept until I say-so. > > That depends on the backend's implementation. etags works that way. That's not my point. My point is that it is up to the user to decide when she switches projects, and tell Emacs about that. Emacs should not try doing that on its own, whatever the backend's implementation is. The backend cannot make this decision for the user. > I think it's high time you've tried the snippets I wrote. I said I will -- when I have time. I didn't have that time yet, sorry. > >> Note that currently the only thing that depends on a specific buffer is > >> the backend used. > > > > I fail to understand the rationale behind such a design. As long as > > we are talking about buffers that hold source code of some programming > > language, why would it be a good idea to switch backends depending on > > the buffer? > > You may not like it, but it's the easiest viable approach we can take, > and a lot of people find it natural. For instance, both original > proposals for the xref implementation used it. I believe you it's the easiest approach. But that doesn't yet make it viable, because IMO it doesn't scale. Only very simple projects will be happy with such a design. The example I described is not very complicated, either, but it already bumps into this limitation. I think this is a clear sign that the limitation should be lifted. > However, like I mentioned, when a project system is used, we can use its > backend in all project files, and so the backend would depend on the > directory you in. If lifting the above limitation requires some project system, then we should provide a simple one for a project that uses only Makefile's. That could be a single command that just specifies the top-level directory of the project, or something similar. However, it sounds like xref is not yet ready for that, either, is it? If so, I suggest to add these simple features, because that would allow to lift the limitation and make the feature much more scalable. > > projectile-switch-project is conceptually the same as > > visit-tags-table, so I see no difference. > > Except it visits the "root file" of the project after switching, and > immediately "forgets" the previous project. So it's the kind of design > you don't like. Then there should be a projectile-add-project and projectile-remove-project as well. I'm sure someone already thought about that. (I know nothing about Projectile, except that I think the name is unfortunate -- take this from someone who has an intimate familiarity with real projectiles.) > > That's not the issue. The issue is that the logic behind determining > > the current project cannot be reliable enough to decide for the user > > which collection(s) of symbols are of interest to me at any given > > time. Only the user knows that. Unlike some other heuristics, where > > it's okay to have an imperfect success rate, in this case it's > > terribly annoying when Emacs refuses to admit that a symbol exists and > > show it to you, when you _know_ for sure it does exist. This kind of > > annoyance _will_ happen if you rely on automated logic for deciding > > which symbols are or aren't relevant. > > While I can understand it, that's just your (i.e. not universal) > opinion I'd be surprised if it was just mine. I know people who work on projects much more complex than the use case I described. Perhaps they don't use Emacs, which would be an indirect approval of my opinions. > That is, a backend can use this approach as well. "Can" and "does" have a large gap between them, from the user's POV. Do we already have such a backend? If not, I suggest to add it. > > That's not user-level customization. It's too complex to be that. We > > need simpler, higher-level customizations. > > We don't even know what and how to customize yet. It might be time for > you to swap the user shoes for the developer shoes. Unlikely to happen. Given that etags exists and pretty much satisfies my needs (with 30-year old technology!), there's not enough itch here for me to scratch. If xref is going to be as good as etags, let alone better, I _will_ switch, I can promise you that much. Until then, I'm happy enough with etags, thank you very much. I'm here merely as a user, providing feedback for features someone else develops. I hope this is helpful; if not, feel free to discontinue the discussion at any point you like. > >>> Is it possible to turn on xref-etags-mode (or its equivalents) > >>> globally? > >> > >> It's "turned on" by default. > > > > Then why did you propose to use hooks? > > Because emacs-lisp-mode overrides it, and to reach certain level of > happiness, you seem to need to revert that override. I believe I've > explained that in the previous email, no? No, I only understood that now. Sorry for being dense. So perhaps some users, like myself, will benefit from preventing the override? Is that possible with the current master? > > Btw, this mode of work, in more than one language, is not limited to > > Emacs. You will see it in Guile, in Python, in Awk, in GDB, and in > > many other places. It begins to be the rule rather than exception > > these days. It's not good if Emacs will ask developers to jump > > through hoops to support that. > > You seem to be clamoring for project support in Emacs. Maybe I am, I don't know. I don't care how this is called. What I do care is to be able to start working on a project with minimal fuss. Having to spend a significant time telling Emacs just what constitutes the project is therefore a turn-off: it is why I dislike Visual Studio like "projects" and "solutions" system -- it might be OK for starting a project from scratch, but sucks when you need to work on an existing project, let alone a large one. > That's commendable, and it's a separate discussion. It is a very much related discussion, since you think the features I miss in xref should be implemented by "project support". Because etags seems to seamlessly let me have that. So if xref is meant to replace etags, it should provide the same functionality, and if that requires some rudimentary "project support", we should include it when we announce deprecation of etags. > Meanwhile, a lot of features currently depend just on the current major > mode and buffer. There's nothing new about it. I never said that no feature can ever depend on the major mode. All I'm saying is that this particular feature shouldn't, and I gave simple enough use cases to demonstrate why it is IMO wrong in this case. > The easiest example is code completion. In emacs-lisp-mode, it will > parse the current buffer context and offer completions from obarray, > somewhat filtered. If you have a README in the same directory as > foo.el (so we might consider them to be in the same project), when > you open it, you definitely won't get the same completions as in > emacs-lisp-mode. In fact, if there's no current tags file visited, > in the default Emacs configuration you won't get any completions at > all. > > Similarly for python-mode (python-shell-completion-at-point only works > in Python buffers, and only when an inferior shell is running). Likewise > for Octave, and I just haven't looked at Guile, Awk and GDB support. I'm not sure what completions are alluded to here. Completions are context-dependent, i.e. their DWIM-ish nature should depend on what is being completed, and for what purposes. For example, I hope you'd agree that it would be bad in general for completion in "C-x C-f" to show only files from the current project. By contrast, a specialized command that is meant to find files only from the current project should probably limit the candidates to the project. Likewise with symbols -- when the user wants only symbols from the current project, or from the programming language of the current buffer, that's what Emacs should show. But there are also situations where such limitations produce bad results. Since only the user knows what she wants to see at any given moment, Emacs must support that. It can do that in several ways: . have dedicated commands for each kind of situation . apply some heuristics to order the candidates in a particular way, so that the ones deemed more DWIM-ish appear first; this heuristics could use the current major mode or the current project or something else . maybe some other possibilities I haven't thought about The important point is we cannot limit the user to just one possible context, even if it is the most frequent one. Such a feature would be too limited. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 24 11:47:58 2015 Received: (at 19466) by debbugs.gnu.org; 24 Jan 2015 16:47:58 +0000 Received: from localhost ([127.0.0.1]:55328 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YF3sL-0003ig-OJ for submit@debbugs.gnu.org; Sat, 24 Jan 2015 11:47:58 -0500 Received: from mail-wi0-f170.google.com ([209.85.212.170]:35245) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YF3sJ-0003iT-8W for 19466@debbugs.gnu.org; Sat, 24 Jan 2015 11:47:56 -0500 Received: by mail-wi0-f170.google.com with SMTP id em10so727398wid.1 for <19466@debbugs.gnu.org>; Sat, 24 Jan 2015 08:47:49 -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=8uLTYtcFA3vzIi4mvUUKQK7cVtk2O7YWQtNsmp1cwFs=; b=Zdv/pcBIcYjktIxmw/Q/0a959/7WFIQrMUnM8nU7ez59QrahrsUNm67A8XsLacxeMw 5PCNiBTVMGR907hvx0/yjNCCHarE1i3J55z/Q74YxH5rFyl+Sg6zOUwNM4iw//d43l28 gc7DFZRvgQWOkzqzka8M/oIyvxITcmYQY0iUgVxvinG5QKufogbUETa5BsRSvFQpLcfb k1SL3WtuZP0rNXGANgPyce8UFfq12mtDCOQP5OlXZ1nHQt7WgH2SLTrbP8BywO7HfCMP +CBXoXKZ2J3ggjoqi1q3lkpWO5FTSupOOPHBYzXBx+MzhmBqd17IRPP75LW+WAHQCRuY Qgag== X-Received: by 10.180.36.226 with SMTP id t2mr15384321wij.16.1422118069616; Sat, 24 Jan 2015 08:47:49 -0800 (PST) Received: from [192.168.1.3] ([82.102.93.54]) by mx.google.com with ESMTPSA id bj3sm6499942wib.3.2015.01.24.08.47.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Jan 2015 08:47:49 -0800 (PST) Message-ID: <54C3CCB2.5030708@yandex.ru> Date: Sat, 24 Jan 2015 18:47:46 +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 To: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> <54BEBF63.9050709@yandex.ru> <8361c0w16n.fsf@gnu.org> <54C063E3.8020401@yandex.ru> <83a91avglz.fsf@gnu.org> <54C1655E.4050403@yandex.ru> <83r3uluawd.fsf@gnu.org> <54C28635.8070606@yandex.ru> <83twzhryyq.fsf@gnu.org> <54C2C9DC.1050908@yandex.ru> <83h9vgsehi.fsf@gnu.org> In-Reply-To: <83h9vgsehi.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, eller.helmut@gmail.com 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/24/2015 11:40 AM, Eli Zaretskii wrote: >> To cut this part of discussion short, yes, the project system can well >> be designed so that the "current project" depends not on the current >> buffer but on the user's choice. So to switch between projects, you >> invoke an explicit command, but don't visit a buffer belonging to the >> other project. And xref can work with such a system (just as it works >> with etags) without significant problems. > > Can you tell how can this be set up with xref, or point me to the > relevant documentation? I did. "Just like it works with etags" was a big hint in the quote above. > I said I will -- when I have time. I didn't have that time yet, > sorry. Please respond after you've found that time, then. Is it is, the current discussion is getting nowhere. > I believe you it's the easiest approach. But that doesn't yet make it > viable, because IMO it doesn't scale. Only very simple projects will > be happy with such a design. The example I described is not very > complicated, either, but it already bumps into this limitation. I > think this is a clear sign that the limitation should be lifted. Just for the sake of the argument: instead of visiting two tag tables at the same time from Emacs, you could instead include the external library's tag file in the application's tag file ("--include" etags argument). That doesn't seem like it'll work with several external libraries, but maybe it should. That wouldn't allow you to jump from a library file to the application's file (I think; you'd have to use e.g. switch-buffer instead), but there is a certain semantic strictness in that (the library doesn't know about the application). > However, it sounds like xref is not yet ready for that, either, is it? > If so, I suggest to add these simple features, because that would > allow to lift the limitation and make the feature much more scalable. It's quite ready. xref will work with any such backend. > Then there should be a projectile-add-project and > projectile-remove-project as well. I'm sure someone already thought > about that. Maybe they didn't but they haven't shared that with the rest of us. Given Projectile's current behavior, though it would cause incompatibility or complications in the implementation. But anyway, I think I'm starting to like the idea of this approach. Maybe I'll try to implement it sometime. > (I know nothing about Projectile, except that I think the > name is unfortunate -- take this from someone who has an intimate > familiarity with real projectiles.) I think it's fine. A projectile is not necessarily an ammo round. >> That is, a backend can use this approach as well. > > "Can" and "does" have a large gap between them, from the user's POV. > Do we already have such a backend? If not, I suggest to add it. etagggggsss. Its only drawback, from your standpoint, stems from it being the default one (which major modes can override), instead from being assigned in a globalized minor mode. I'm not sure if we want to have it both as default, and have a minor mode (a by-default-on minor mode won't be good enough). > I'm here merely as a user, providing feedback for features someone > else develops. I hope this is helpful; if not, feel free to > discontinue the discussion at any point you like. I you were just a user, I'd have stopped a while ago, since I still don't think this feature request is useful to the majority of users. Since you're a valued core contributor, though, I'd really like to accommodate your needs. However, that comes with the expectation that you can participate in the design and provide more nuanced requirements than an ordinary user would do. Maybe you'd a least look at the code, if not implement the improvements yourself. > So perhaps some users, like myself, will benefit from preventing the > override? Is that possible with the current master? Yes: you use the snippets I provided together with the current master. Whether any part of them is worthy of installing into master, is yet to be determined. > Maybe I am, I don't know. I don't care how this is called. What I do > care is to be able to start working on a project with minimal fuss. > Having to spend a significant time telling Emacs just what constitutes > the project is therefore a turn-off: it is why I dislike Visual Studio > like "projects" and "solutions" system -- it might be OK for starting > a project from scratch, but sucks when you need to work on an existing > project, let alone a large one. I'm pretty sure some users would consider having to call visit-tags-table as "having to spend time telling Emacs just what constitutes a project", as opposed to Projectile's current approach. > It is a very much related discussion, since you think the features I > miss in xref should be implemented by "project support". No: the xref features should work with etags without additional infrastructure. We won't know that for certain, though, until you find that free time. I mentioned project support, which we don't have, because you've expanded the discussion to supporting "this mode of work" in different languages and, I'm assuming, for different features. And not every language/framework ecosystem considers the tag files to be the best solution for code navigation, completion, etc. I'll respond to the rest of this email in a separate thread, but that discussion is likely premature. > etags seems to seamlessly let me have that. So if xref is meant to > replace etags, it should provide the same functionality, and if that > requires some rudimentary "project support", we should include it when > we announce deprecation of etags. xref is meant to replace `find-tag' and `tags-apropos'. etags, as a package, is unlikely to ever be deprecated. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 31 03:53:26 2015 Received: (at 19466) by debbugs.gnu.org; 31 Jan 2015 08:53:26 +0000 Received: from localhost ([127.0.0.1]:58424 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YHTny-0007Hq-GH for submit@debbugs.gnu.org; Sat, 31 Jan 2015 03:53:26 -0500 Received: from mtaout29.012.net.il ([80.179.55.185]:49803) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YHTnw-0007Hc-2O for 19466@debbugs.gnu.org; Sat, 31 Jan 2015 03:53:25 -0500 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NJ1003009M9BW00@mtaout29.012.net.il> for 19466@debbugs.gnu.org; Sat, 31 Jan 2015 10:49:17 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJ100JRB9U4BT90@mtaout29.012.net.il>; Sat, 31 Jan 2015 10:49:17 +0200 (IST) Date: Sat, 31 Jan 2015 10:52:53 +0200 From: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions In-reply-to: <54C3CCB2.5030708@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Gutov Message-id: <83y4ojjpqy.fsf@gnu.org> References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> <54BEBF63.9050709@yandex.ru> <8361c0w16n.fsf@gnu.org> <54C063E3.8020401@yandex.ru> <83a91avglz.fsf@gnu.org> <54C1655E.4050403@yandex.ru> <83r3uluawd.fsf@gnu.org> <54C28635.8070606@yandex.ru> <83twzhryyq.fsf@gnu.org> <54C2C9DC.1050908@yandex.ru> <83h9vgsehi.fsf@gnu.org> <54C3CCB2.5030708@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, eller.helmut@gmail.com 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: 1.0 (+) > Date: Sat, 24 Jan 2015 18:47:46 +0200 > From: Dmitry Gutov > CC: 19466@debbugs.gnu.org, eller.helmut@gmail.com > > > I said I will -- when I have time. I didn't have that time yet, > > sorry. > > Please respond after you've found that time, then. Is it is, the current > discussion is getting nowhere. I tried that a few days ago, but didn't see any significant changes in behavior. I'm probably missing something -- what exactly did you want me to pay attention to? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 31 21:25:00 2015 Received: (at 19466) by debbugs.gnu.org; 1 Feb 2015 02:25:00 +0000 Received: from localhost ([127.0.0.1]:59282 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YHkDc-0001vM-87 for submit@debbugs.gnu.org; Sat, 31 Jan 2015 21:25:00 -0500 Received: from mail-wi0-f182.google.com ([209.85.212.182]:56593) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YHkDa-0001v8-K2 for 19466@debbugs.gnu.org; Sat, 31 Jan 2015 21:24:59 -0500 Received: by mail-wi0-f182.google.com with SMTP id n3so9081766wiv.3 for <19466@debbugs.gnu.org>; Sat, 31 Jan 2015 18:24:53 -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=9cWsNf4LD2BiebQd3Jf46Ocb5HsMGxmxlAHcTaq1hWU=; b=xhfgshAvP9JGUYJgwzOxOP52IhGtexEdnY/v7ft9/dOuOdxYKdrr21OxX6Vjf8OQQL Ud3zURgj/DVO5RVobCYbH/eErz00tWS5hsIJCnu/2g5LQLkWMSWIavucZkvm+qAvFauz FamliCX4wbl0XNj2AkzPMsNqQc8kbrHDtRdzl8W7aoNhgHlSiq5DFkXuHTu/neaihkuq BYRcgP6xmnF0DvL49M5KyubytVYW/+uCHaNxhypyjgveVMEz7nJig56AcfwiM4OBFF2F 7KPim7v2gC+1jtMu+skXuyDNOAxX/4BXf3E6At4tbxDe74K8+vM9bAEoGP5EZeOSyMhH Ab3g== X-Received: by 10.180.79.131 with SMTP id j3mr10000384wix.33.1422757493005; Sat, 31 Jan 2015 18:24:53 -0800 (PST) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id cm7sm13486328wib.6.2015.01.31.18.24.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Jan 2015 18:24:52 -0800 (PST) Message-ID: <54CD8E72.5000902@yandex.ru> Date: Sun, 01 Feb 2015 04:24:50 +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 To: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> <54BEBF63.9050709@yandex.ru> <8361c0w16n.fsf@gnu.org> <54C063E3.8020401@yandex.ru> <83a91avglz.fsf@gnu.org> <54C1655E.4050403@yandex.ru> <83r3uluawd.fsf@gnu.org> <54C28635.8070606@yandex.ru> <83twzhryyq.fsf@gnu.org> <54C2C9DC.1050908@yandex.ru> <83h9vgsehi.fsf@gnu.org> <54C3CCB2.5030708@yandex.ru> <83y4ojjpqy.fsf@gnu.org> In-Reply-To: <83y4ojjpqy.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, eller.helmut@gmail.com 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/31/2015 10:52 AM, Eli Zaretskii wrote: > I tried that a few days ago, but didn't see any significant changes in > behavior. I'm probably missing something -- what exactly did you want > me to pay attention to? What have you tried, exactly? You should have noticed that `M-.' in emacs-lisp-mode buffers behaves like in other buffers and uses the current tags table (and prompts for it if the tags table hasn't been visited yet). I've found one caveat now: even though the tags list is not buffer-local (right?), (tags-lazy-completion-table) returns different results in lisp/**/*.el buffers and src/*.c buffers. `find-tag' completion exhibits the same difference. For instance, calling `M-x find-tag' in src/disp.c, then typing `display_li' and pressing TAB will complete it to `display_line'. No so in lisp/progmodes/etags.el. Doing it in that buffer results in [No match]. However, typing `display_line' fully in either, then pressing RET, brings you to that function's definition. This should be considered a bug, right? Until it is fixed, to be able to jump to `display_line' from lisp/** buffers, we have to disable the strict matching in `xref--read-identifier'. Please try #41 again with this patch applied: diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index 55405b6..f550282 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -562,7 +562,7 @@ Return an alist of the form ((FILENAME . (XREF ...)) ...)." (cond ((or current-prefix-arg (not id)) (completing-read prompt (funcall xref-identifier-completion-table-function) - nil t id + nil nil id 'xref--read-identifier-history)) (t id)))) From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 01 11:01:59 2015 Received: (at 19466) by debbugs.gnu.org; 1 Feb 2015 16:01:59 +0000 Received: from localhost ([127.0.0.1]:59763 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YHwyF-0007V9-3K for submit@debbugs.gnu.org; Sun, 01 Feb 2015 11:01:59 -0500 Received: from mtaout24.012.net.il ([80.179.55.180]:59266) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YHwyB-0007Us-S7 for 19466@debbugs.gnu.org; Sun, 01 Feb 2015 11:01:57 -0500 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NJ300I00O3ASX00@mtaout24.012.net.il> for 19466@debbugs.gnu.org; Sun, 01 Feb 2015 17:53:38 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJ300FXHO5CPW20@mtaout24.012.net.il>; Sun, 01 Feb 2015 17:53:38 +0200 (IST) Date: Sun, 01 Feb 2015 18:01:31 +0200 From: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions In-reply-to: <54CD8E72.5000902@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Gutov Message-id: <83ioflipt0.fsf@gnu.org> References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> <54BEBF63.9050709@yandex.ru> <8361c0w16n.fsf@gnu.org> <54C063E3.8020401@yandex.ru> <83a91avglz.fsf@gnu.org> <54C1655E.4050403@yandex.ru> <83r3uluawd.fsf@gnu.org> <54C28635.8070606@yandex.ru> <83twzhryyq.fsf@gnu.org> <54C2C9DC.1050908@yandex.ru> <83h9vgsehi.fsf@gnu.org> <54C3CCB2.5030708@yandex.ru> <83y4ojjpqy.fsf@gnu.org> <54CD8E72.5000902@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, eller.helmut@gmail.com 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: 1.0 (+) > Date: Sun, 01 Feb 2015 04:24:50 +0200 > From: Dmitry Gutov > CC: 19466@debbugs.gnu.org, eller.helmut@gmail.com > > On 01/31/2015 10:52 AM, Eli Zaretskii wrote: > > > I tried that a few days ago, but didn't see any significant changes in > > behavior. I'm probably missing something -- what exactly did you want > > me to pay attention to? > > What have you tried, exactly? I evaluated your suggested code, and then typed "M-.". > You should have noticed that `M-.' in emacs-lisp-mode buffers behaves > like in other buffers and uses the current tags table (and prompts for > it if the tags table hasn't been visited yet). It does. > I've found one caveat now: even though the tags list is not buffer-local > (right?), (tags-lazy-completion-table) returns different results in > lisp/**/*.el buffers and src/*.c buffers. Yes, it's not 100% smooth. > `find-tag' completion exhibits the same difference. For instance, > calling `M-x find-tag' in src/disp.c, then typing `display_li' and > pressing TAB will complete it to `display_line'. No so in > lisp/progmodes/etags.el. Doing it in that buffer results in [No match]. That's not what I see, both in Emacs 24.4 and with the current trunk: the completion works even in buffers whose major mode is emacs-lisp. > However, typing `display_line' fully in either, then pressing RET, > brings you to that function's definition. This should be considered a > bug, right? Yes, except that I don't see it, at least not in "emacs -Q". From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 01 15:11:21 2015 Received: (at 19466) by debbugs.gnu.org; 1 Feb 2015 20:11:21 +0000 Received: from localhost ([127.0.0.1]:59849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YI0rY-00055Q-N4 for submit@debbugs.gnu.org; Sun, 01 Feb 2015 15:11:21 -0500 Received: from mail-we0-f179.google.com ([74.125.82.179]:49957) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YI0rW-00055C-1u for 19466@debbugs.gnu.org; Sun, 01 Feb 2015 15:11:18 -0500 Received: by mail-we0-f179.google.com with SMTP id q59so35642452wes.10 for <19466@debbugs.gnu.org>; Sun, 01 Feb 2015 12:11:12 -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=VXaiziNb6z0IUbs71cMEHU2JqfT8wyL4GD1cIGU4jK0=; b=oea5qFVIphVuTx4ZYwQbvo7tOSfLjyDkT5S5sTszn/dW5ExGwk3bCFBW0r4CfOx1oW fYFj/zpd3wrBlpolvJ3chMJkBEv9idj9QN9vi/e/flFoh9U7W/y6xKDL4OBH7U1+CN35 NBcQsv/ymppB0SPJl+nmx25WXHXthcK5VimSKccf4npizZSBlmCMD0h9M79mUJwqb28w 5qM35ST6Da2UlBw/xTasAUFxKQCfCfhWHZ7p1ynyciZGK2eDB16HI7uggPHXSaM3Ghs7 dWCV0jOmO+wKfhnkBmWfFhtPobbw9A49TjJKpbrA4h0QXp+yl+mjgXUeN5vqbv1nYkcP UOVQ== X-Received: by 10.194.120.40 with SMTP id kz8mr36023029wjb.21.1422821472563; Sun, 01 Feb 2015 12:11:12 -0800 (PST) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id g8sm12274390wiy.6.2015.02.01.12.11.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Feb 2015 12:11:12 -0800 (PST) Message-ID: <54CE885C.8060202@yandex.ru> Date: Sun, 01 Feb 2015 22:11:08 +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 To: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> <54BEBF63.9050709@yandex.ru> <8361c0w16n.fsf@gnu.org> <54C063E3.8020401@yandex.ru> <83a91avglz.fsf@gnu.org> <54C1655E.4050403@yandex.ru> <83r3uluawd.fsf@gnu.org> <54C28635.8070606@yandex.ru> <83twzhryyq.fsf@gnu.org> <54C2C9DC.1050908@yandex.ru> <83h9vgsehi.fsf@gnu.org> <54C3CCB2.5030708@yandex.ru> <83y4ojjpqy.fsf@gnu.org> <54CD8E72.5000902@yandex.ru> <83ioflipt0.fsf@gnu.org> In-Reply-To: <83ioflipt0.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, eller.helmut@gmail.com 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 02/01/2015 06:01 PM, Eli Zaretskii wrote: >> What have you tried, exactly? > > I evaluated your suggested code, and then typed "M-.". If you recall, I gave you several options, with the end goal being making the choice between them or maybe something else. So it would help if you mentioned exactly which one you tried and the problems you experienced after. >> You should have noticed that `M-.' in emacs-lisp-mode buffers behaves >> like in other buffers and uses the current tags table (and prompts for >> it if the tags table hasn't been visited yet). > > It does. Good. So why did you report not seeing any significant changes? >> I've found one caveat now: even though the tags list is not buffer-local >> (right?), (tags-lazy-completion-table) returns different results in >> lisp/**/*.el buffers and src/*.c buffers. > > Yes, it's not 100% smooth. What do you mean by that exactly? It can't be that same as what I meant because you've rejected the only example I gave. >> `find-tag' completion exhibits the same difference. For instance, >> calling `M-x find-tag' in src/disp.c, then typing `display_li' and >> pressing TAB will complete it to `display_line'. No so in >> lisp/progmodes/etags.el. Doing it in that buffer results in [No match]. > > That's not what I see, both in Emacs 24.4 and with the current trunk: > the completion works even in buffers whose major mode is emacs-lisp. Good to know. That means I did something unusual, and the average user won't see that problem. >> However, typing `display_line' fully in either, then pressing RET, >> brings you to that function's definition. This should be considered a >> bug, right? > > Yes, except that I don't see it, at least not in "emacs -Q". This has nothing to do with my configuration, just with a few (maybe ill-considered) steps that I performed: http://debbugs.gnu.org/19741 From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 01 15:30:46 2015 Received: (at 19466) by debbugs.gnu.org; 1 Feb 2015 20:30:46 +0000 Received: from localhost ([127.0.0.1]:59860 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YI1AK-0005Yz-ME for submit@debbugs.gnu.org; Sun, 01 Feb 2015 15:30:46 -0500 Received: from mtaout29.012.net.il ([80.179.55.185]:57753) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YI1A4-0005YV-OZ for 19466@debbugs.gnu.org; Sun, 01 Feb 2015 15:30:30 -0500 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NJ400E000S2SQ00@mtaout29.012.net.il> for 19466@debbugs.gnu.org; Sun, 01 Feb 2015 22:26:44 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJ4003MN0SJK390@mtaout29.012.net.il>; Sun, 01 Feb 2015 22:26:44 +0200 (IST) Date: Sun, 01 Feb 2015 22:30:06 +0200 From: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions In-reply-to: <54CE885C.8060202@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Gutov Message-id: <83y4ohgysx.fsf@gnu.org> References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> <54BEBF63.9050709@yandex.ru> <8361c0w16n.fsf@gnu.org> <54C063E3.8020401@yandex.ru> <83a91avglz.fsf@gnu.org> <54C1655E.4050403@yandex.ru> <83r3uluawd.fsf@gnu.org> <54C28635.8070606@yandex.ru> <83twzhryyq.fsf@gnu.org> <54C2C9DC.1050908@yandex.ru> <83h9vgsehi.fsf@gnu.org> <54C3CCB2.5030708@yandex.ru> <83y4ojjpqy.fsf@gnu.org> <54CD8E72.5000902@yandex.ru> <83ioflipt0.fsf@gnu.org> <54CE885C.8060202@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, eller.helmut@gmail.com 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: 1.0 (+) > Date: Sun, 01 Feb 2015 22:11:08 +0200 > From: Dmitry Gutov > CC: 19466@debbugs.gnu.org, eller.helmut@gmail.com > > On 02/01/2015 06:01 PM, Eli Zaretskii wrote: > > >> What have you tried, exactly? > > > > I evaluated your suggested code, and then typed "M-.". > > If you recall, I gave you several options, with the end goal being > making the choice between them or maybe something else. > > So it would help if you mentioned exactly which one you tried and the > problems you experienced after. They all did the same, AFAICS. > >> You should have noticed that `M-.' in emacs-lisp-mode buffers behaves > >> like in other buffers and uses the current tags table (and prompts for > >> it if the tags table hasn't been visited yet). > > > > It does. > > Good. So why did you report not seeing any significant changes? Because I thought the effects were supposed to be more profound than that. > >> I've found one caveat now: even though the tags list is not buffer-local > >> (right?), (tags-lazy-completion-table) returns different results in > >> lisp/**/*.el buffers and src/*.c buffers. > > > > Yes, it's not 100% smooth. > > What do you mean by that exactly? What you discovered: the order of loading Emacs TAGS tables matters. I have never loaded lisp/TAGS directly, only src/TAGS, which then includes lisp/TAGS. > It can't be that same as what I meant because you've rejected the only > example I gave. I misunderstood your recipe, sorry. I only loaded src/TAGS. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 01 15:53:24 2015 Received: (at 19466) by debbugs.gnu.org; 1 Feb 2015 20:53:24 +0000 Received: from localhost ([127.0.0.1]:59865 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YI1WG-00065o-DP for submit@debbugs.gnu.org; Sun, 01 Feb 2015 15:53:24 -0500 Received: from mail-wi0-f175.google.com ([209.85.212.175]:56728) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YI1WD-00065Z-JW for 19466@debbugs.gnu.org; Sun, 01 Feb 2015 15:53:22 -0500 Received: by mail-wi0-f175.google.com with SMTP id fb4so12829681wid.2 for <19466@debbugs.gnu.org>; Sun, 01 Feb 2015 12:53:15 -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=MqyR+lKOiv6myYD9y/aQve+E1bvK366l/VKTIKctxV0=; b=A6Nqwmb65qmt3UQvL/pQlTZvssNBABLwyDJqfE93NAMmNRNMKrw0Hx8tVKqj8jUX6j 87MZ7HXZoKRwbz54LTfonrnPGQahMYiUToGt75yTTcaGtQZlK3g69wtU2JHOBh6SClEF 9QQ6PvwrFpH5sB7z6aqdo61HAdOYyXbkcpYNiBfz1V27vmWc04O9AKj9bnHMsovYfe5f R7VeMTi+3CM9D9i19RE21JKPHN6q7C4qnGjMXpGz17ijHFjuv8+DY2LqRxr/8WWTr+uk vdXXzbmJuvdb7nSr2q19PrS/M5b/FQv7dpNUpvqhjlxbYX2WeP8e6wbI69OGX3/ril8c c1+g== X-Received: by 10.194.63.172 with SMTP id h12mr36193443wjs.32.1422823995915; Sun, 01 Feb 2015 12:53:15 -0800 (PST) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id et4sm24782506wjd.15.2015.02.01.12.53.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Feb 2015 12:53:15 -0800 (PST) Message-ID: <54CE9237.2010607@yandex.ru> Date: Sun, 01 Feb 2015 22:53:11 +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 To: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> <54BEBF63.9050709@yandex.ru> <8361c0w16n.fsf@gnu.org> <54C063E3.8020401@yandex.ru> <83a91avglz.fsf@gnu.org> <54C1655E.4050403@yandex.ru> <83r3uluawd.fsf@gnu.org> <54C28635.8070606@yandex.ru> <83twzhryyq.fsf@gnu.org> <54C2C9DC.1050908@yandex.ru> <83h9vgsehi.fsf@gnu.org> <54C3CCB2.5030708@yandex.ru> <83y4ojjpqy.fsf@gnu.org> <54CD8E72.5000902@yandex.ru> <83ioflipt0.fsf@gnu.org> <54CE885C.8060202@yandex.ru> <83y4ohgysx.fsf@gnu.org> In-Reply-To: <83y4ohgysx.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, eller.helmut@gmail.com 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 02/01/2015 10:30 PM, Eli Zaretskii wrote: > They all did the same, AFAICS. The end behavior is similar, but in #32, the user can `M-x xref-etags-mode' again to get back to using find-func as xref backend in emacs-lisp-mode buffers. > Because I thought the effects were supposed to be more profound than > that. It solves the original complaint, doesn't it? That's the idea. If that's actually enough for you, we can add xref-reset-backend from #41 to xref.el as `xref-reset-to-etags', and anyone will be able to (add-hook 'emacs-lisp-mode-hook 'xref-reset-to-etags) in their init file to get back to using etags. And same with any other major mode that will implement its own xref backend. > What you discovered: the order of loading Emacs TAGS tables matters. What I see there looks like a bug, and not like a necessary quirk in behavior. > I misunderstood your recipe, sorry. I only loaded src/TAGS. That's my fault, I didn't mention doing that in the previous message. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 01 22:33:04 2015 Received: (at 19466) by debbugs.gnu.org; 2 Feb 2015 03:33:04 +0000 Received: from localhost ([127.0.0.1]:59951 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YI7l0-0007AL-JL for submit@debbugs.gnu.org; Sun, 01 Feb 2015 22:33:04 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:45929) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YI7ky-00079k-0U for 19466@debbugs.gnu.org; Sun, 01 Feb 2015 22:33:01 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NJ400E00JT7LO00@a-mtaout20.012.net.il> for 19466@debbugs.gnu.org; Mon, 02 Feb 2015 05:32:53 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJ400ETCKISBA90@a-mtaout20.012.net.il>; Mon, 02 Feb 2015 05:32:53 +0200 (IST) Date: Mon, 02 Feb 2015 05:32:38 +0200 Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated. From: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions In-reply-to: <54CE9237.2010607@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Gutov Message-id: <83vbjlgf8p.fsf@gnu.org> References: <8361cucl3u.fsf@gnu.org> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> <54BEBF63.9050709@yandex.ru> <8361c0w16n.fsf@gnu.org> <54C063E3.8020401@yandex.ru> <83a91avglz.fsf@gnu.org> <54C1655E.4050403@yandex.ru> <83r3uluawd.fsf@gnu.org> <54C28635.8070606@yandex.ru> <83twzhryyq.fsf@gnu.org> <54C2C9DC.1050908@yandex.ru> <83h9vgsehi.fsf@gnu.org> <54C3CCB2.5030708@yandex.ru> <83y4ojjpqy.fsf@gnu.org> <54CD8E72.5000902@yandex.ru> <83ioflipt0.fsf@gnu.org> <54CE885C.8060202@yandex.ru> <83y4ohgysx.fsf@gnu.org> <54CE9237.2010607@yan> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19466 Cc: 19466@debbugs.gnu.org, eller.helmut@gmail.com 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: 1.0 (+) > Date: Sun, 01 Feb 2015 22:53:11 +0200 > From: Dmitry Gutov > CC: 19466@debbugs.gnu.org, eller.helmut@gmail.com > > On 02/01/2015 10:30 PM, Eli Zaretskii wrote: > > > They all did the same, AFAICS. > > The end behavior is similar, but in #32, the user can `M-x > xref-etags-mode' again to get back to using find-func as xref backend in > emacs-lisp-mode buffers. Then maybe this one is preferable. > It solves the original complaint, doesn't it? That's the idea. > > If that's actually enough for you, we can add xref-reset-backend from > #41 to xref.el as `xref-reset-to-etags', and anyone will be able to > > (add-hook 'emacs-lisp-mode-hook 'xref-reset-to-etags) > > in their init file to get back to using etags. And same with any other > major mode that will implement its own xref backend. Sounds good, thanks. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 22 21:01:33 2015 Received: (at 19466-done) by debbugs.gnu.org; 23 Feb 2015 02:01:33 +0000 Received: from localhost ([127.0.0.1]:50954 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPiKz-0006eG-Cr for submit@debbugs.gnu.org; Sun, 22 Feb 2015 21:01:33 -0500 Received: from mail-wg0-f50.google.com ([74.125.82.50]:39805) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPiKw-0006e8-SC for 19466-done@debbugs.gnu.org; Sun, 22 Feb 2015 21:01:31 -0500 Received: by mail-wg0-f50.google.com with SMTP id l2so22881199wgh.9 for <19466-done@debbugs.gnu.org>; Sun, 22 Feb 2015 18:01:30 -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=vbOkLRGrO+5dUJvDhrKxM1qzyRy9Q2di6KGfRXjCfic=; b=VkeSke1gn2mpy0rs5pwDKnz/CRM0KGfMTWiJjl1Hqpu7lK5tW4u28MDeeZyQ367GpF 8/acgcsk6h4v44Iy0Yh+EgV5vh6vYrSO/6r2IFhv9VO9raKclwl4dh3V/5qCQyAiJ2HY PVcnQGIZj9YI6wjzUgOz/JLHID4nu7Be/DVWPosPBJo94ZbY2YJXLDIx/IQm9tbVY+Po rebAuvyWH9jDF11FUL5GYdoT3XhLjHELKUVMqAleECgjvu82cX+xPgqqWONWUtigjLsa Pyi20nh8RfDtDasp0hUAfY52gtJ1OLjE+I6H6u3OgcAvW4W+dNTsxcAM47w8ocQ0dmbl BKFg== X-Received: by 10.180.24.65 with SMTP id s1mr16189705wif.30.1424656890096; Sun, 22 Feb 2015 18:01:30 -0800 (PST) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id s19sm13714046wik.18.2015.02.22.18.01.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Feb 2015 18:01:29 -0800 (PST) Message-ID: <54EA89F6.6010404@yandex.ru> Date: Mon, 23 Feb 2015 04:01:26 +0200 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions References: <8361cucl3u.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> <54BEBF63.9050709@yandex.ru> <8361c0w16n.fsf@gnu.org> <54C063E3.8020401@yandex.ru> <83a91avglz.fsf@gnu.org> <54C1655E.4050403@yandex.ru> <83r3uluawd.fsf@gnu.org> <54C28635.8070606@yandex.ru> <83twzhryyq.fsf@gnu.org> <54C2C9DC.1050908@yandex.ru> <83h9vgsehi.fsf@gnu.org> <54C3CCB2.5030708@yandex.ru> <83y4ojjpqy.fsf@gnu.org> <54CD8E72.5000902@yandex.ru> <83ioflipt0.fsf@gnu.org> <54CE885C.8060202@yandex.ru> <83y4ohgysx.fsf@gnu.org> <54CE9237.2010607@yan> <83vbjlgf8p.fsf@gnu.org> In-Reply-To: <83vbjlgf8p.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19466-done Cc: 19466-done@debbugs.gnu.org, eller.helmut@gmail.com 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 02/02/2015 05:32 AM, Eli Zaretskii wrote: >> The end behavior is similar, but in #32, the user can `M-x >> xref-etags-mode' again to get back to using find-func as xref backend in >> emacs-lisp-mode buffers. > > Then maybe this one is preferable. Added now. This bug looks resolved to me, so closing. From unknown Tue Aug 19 07:26:18 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 23 Mar 2015 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator