From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#19466: 25.0.50; xref-find-def doesn't find C functions Date: Tue, 20 Jan 2015 15:51:05 +0100 Message-ID: <54BE6B59.5090404@gmx.at> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1421765540 14255 80.91.229.3 (20 Jan 2015 14:52:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 Jan 2015 14:52:20 +0000 (UTC) Cc: 19466@debbugs.gnu.org, Helmut Eller To: Dmitry Gutov , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jan 20 15:52:19 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YDaAD-0006Q5-VX for geb-bug-gnu-emacs@m.gmane.org; Tue, 20 Jan 2015 15:52:18 +0100 Original-Received: from localhost ([::1]:43772 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDaAC-0008Qn-Rt for geb-bug-gnu-emacs@m.gmane.org; Tue, 20 Jan 2015 09:52:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56195) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDaA8-0008Oj-Ml for bug-gnu-emacs@gnu.org; Tue, 20 Jan 2015 09:52:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YDa9y-0003Ql-SS for bug-gnu-emacs@gnu.org; Tue, 20 Jan 2015 09:52:12 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59879) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDa9y-0003Qh-PL for bug-gnu-emacs@gnu.org; Tue, 20 Jan 2015 09:52:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YDa9y-0004tz-5H for bug-gnu-emacs@gnu.org; Tue, 20 Jan 2015 09:52:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 20 Jan 2015 14:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19466 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19466-submit@debbugs.gnu.org id=B19466.142176548518783 (code B ref 19466); Tue, 20 Jan 2015 14:52:02 +0000 Original-Received: (at 19466) by debbugs.gnu.org; 20 Jan 2015 14:51:25 +0000 Original-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 Original-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 Original-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 In-Reply-To: <54BE4693.5050804@yandex.ru> X-Provags-ID: V03:K0:ImfI6ex16fgVlrwhyGQP50I0lsHQJSJ/lTJZyoKQxm4MHUa/z7I GCgMFWLEkqTbsa8Y7VZ5H2e7H4ksObpH0aH6pD3eUxBEYLC94OkIh9vs4j1ynFZViuiJ+Gb z+OU9EHTXaRX6IXi+9wjINFK5mo7OUM9AXXwq8rp8F5DgZC3/0i1mpfoT9oVDgm9GmCkrRP GGvigzrujSQlYeJtxmT2g== X-UI-Out-Filterresults: notjunk:1; X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:98499 Archived-At: > 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