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 09:01:30 +0100 Message-ID: <54BE0B5A.6060706@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> 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 1421740934 21143 80.91.229.3 (20 Jan 2015 08:02:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 Jan 2015 08:02:14 +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 09:02:13 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 1YDTlM-0000Td-HO for geb-bug-gnu-emacs@m.gmane.org; Tue, 20 Jan 2015 09:02:12 +0100 Original-Received: from localhost ([::1]:41739 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDTlL-00086U-MY for geb-bug-gnu-emacs@m.gmane.org; Tue, 20 Jan 2015 03:02:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45452) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDTlG-00086I-HG for bug-gnu-emacs@gnu.org; Tue, 20 Jan 2015 03:02:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YDTlD-0003M6-4D for bug-gnu-emacs@gnu.org; Tue, 20 Jan 2015 03:02:06 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59768) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDTlD-0003Lz-1P for bug-gnu-emacs@gnu.org; Tue, 20 Jan 2015 03:02:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YDTlC-0007nO-Hz for bug-gnu-emacs@gnu.org; Tue, 20 Jan 2015 03:02: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 08:02: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.142174090629942 (code B ref 19466); Tue, 20 Jan 2015 08:02:02 +0000 Original-Received: (at 19466) by debbugs.gnu.org; 20 Jan 2015 08:01:46 +0000 Original-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 Original-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 Original-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 In-Reply-To: <54BD076E.6090707@yandex.ru> 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-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:98491 Archived-At: > 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