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: Tue, 20 Jan 2015 14:14:11 +0200 Message-ID: <54BE4693.5050804@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> <54BD076E.6090707@yandex.ru> <54BE0B5A.6060706@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 1421757216 31339 80.91.229.3 (20 Jan 2015 12:33:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 Jan 2015 12:33:36 +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 Tue Jan 20 13:33:34 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 1YDXzy-0002pR-Ke for geb-bug-gnu-emacs@m.gmane.org; Tue, 20 Jan 2015 13:33:34 +0100 Original-Received: from localhost ([::1]:42955 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDXzy-00049M-4C for geb-bug-gnu-emacs@m.gmane.org; Tue, 20 Jan 2015 07:33:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51634) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDXzu-00048V-1A for bug-gnu-emacs@gnu.org; Tue, 20 Jan 2015 07:33:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YDXzp-0001Cv-0Z for bug-gnu-emacs@gnu.org; Tue, 20 Jan 2015 07:33:29 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59827) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDXi3-0006B6-SQ for bug-gnu-emacs@gnu.org; Tue, 20 Jan 2015 07:15:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YDXi3-0006qn-1Y for bug-gnu-emacs@gnu.org; Tue, 20 Jan 2015 07:15:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 20 Jan 2015 12:15: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.142175606426262 (code B ref 19466); Tue, 20 Jan 2015 12:15:02 +0000 Original-Received: (at 19466) by debbugs.gnu.org; 20 Jan 2015 12:14:24 +0000 Original-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 Original-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 Original-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) Original-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) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 In-Reply-To: <54BE0B5A.6060706@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:98495 Archived-At: 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.