From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#19466: 25.0.50; xref-find-def doesn't find C functions Date: Mon, 19 Jan 2015 15:32:30 +0200 Message-ID: <54BD076E.6090707@yandex.ru> 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> 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 1421674392 11066 80.91.229.3 (19 Jan 2015 13:33:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Jan 2015 13:33:12 +0000 (UTC) Cc: 19466@debbugs.gnu.org, Helmut Eller To: martin rudalics , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 19 14:33:11 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 1YDCS6-000521-Qn for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Jan 2015 14:33:11 +0100 Original-Received: from localhost ([::1]:37501 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDCS6-0002Zj-3g for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Jan 2015 08:33:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52122) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDCS2-0002ZO-2J for bug-gnu-emacs@gnu.org; Mon, 19 Jan 2015 08:33:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YDCRy-0001aE-CH for bug-gnu-emacs@gnu.org; Mon, 19 Jan 2015 08:33:06 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52197) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDCRy-0001Yf-8N for bug-gnu-emacs@gnu.org; Mon, 19 Jan 2015 08:33:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YDCRx-0005UE-PP for bug-gnu-emacs@gnu.org; Mon, 19 Jan 2015 08:33:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Jan 2015 13:33:01 +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.142167436221062 (code B ref 19466); Mon, 19 Jan 2015 13:33:01 +0000 Original-Received: (at 19466) by debbugs.gnu.org; 19 Jan 2015 13:32:42 +0000 Original-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 Original-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 Original-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) Original-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) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 In-Reply-To: <54BCC033.2010104@gmx.at> 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:98472 Archived-At: 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.