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 05:31:03 +0200 Message-ID: <54BC7A77.5020307@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> 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 1421638341 4505 80.91.229.3 (19 Jan 2015 03:32:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Jan 2015 03:32:21 +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 04:32:20 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 1YD34X-0002aq-NZ for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Jan 2015 04:32:13 +0100 Original-Received: from localhost ([::1]:35379 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YD34X-0003Hm-57 for geb-bug-gnu-emacs@m.gmane.org; Sun, 18 Jan 2015 22:32:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49473) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YD34S-0003Hf-3B for bug-gnu-emacs@gnu.org; Sun, 18 Jan 2015 22:32:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YD34N-0003ky-0O for bug-gnu-emacs@gnu.org; Sun, 18 Jan 2015 22:32:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52042) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YD34M-0003ku-TA for bug-gnu-emacs@gnu.org; Sun, 18 Jan 2015 22:32:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YD34M-0004DW-Hh for bug-gnu-emacs@gnu.org; Sun, 18 Jan 2015 22:32:02 -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 03:32: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.142163827516154 (code B ref 19466); Mon, 19 Jan 2015 03:32:02 +0000 Original-Received: (at 19466) by debbugs.gnu.org; 19 Jan 2015 03:31:15 +0000 Original-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 Original-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 Original-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) Original-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) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 In-Reply-To: <54B8C22B.3080200@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:98457 Archived-At: 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.