From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#33992: 27.0.50; xref-find-definitions wastes too much space Date: Fri, 3 May 2019 02:05:55 +0300 Message-ID: References: <87muoe7jrs.fsf@mail.linkov.net> <87a7hp43a5.fsf@mail.linkov.net> <205acda7-07a3-d85c-378c-c178f9f76b55@yandex.ru> <87o95l4ht4.fsf@mail.linkov.net> <64f42172-460f-a633-1c80-23d34b5c0d07@yandex.ru> <87lg0m96bm.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="37056"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 Cc: 33992@debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 03 01:07:11 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hMKnH-0009WC-IC for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 May 2019 01:07:11 +0200 Original-Received: from localhost ([127.0.0.1]:59664 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMKnG-0005kh-Hf for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 May 2019 19:07:10 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51633) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMKnA-0005kP-Cg for bug-gnu-emacs@gnu.org; Thu, 02 May 2019 19:07:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMKn8-0003q3-Hb for bug-gnu-emacs@gnu.org; Thu, 02 May 2019 19:07:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33731) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hMKn8-0003pm-5i for bug-gnu-emacs@gnu.org; Thu, 02 May 2019 19:07:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hMKn7-0002v4-Sh for bug-gnu-emacs@gnu.org; Thu, 02 May 2019 19:07:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 May 2019 23:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33992 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 33992-submit@debbugs.gnu.org id=B33992.155683836611160 (code B ref 33992); Thu, 02 May 2019 23:07:01 +0000 Original-Received: (at 33992) by debbugs.gnu.org; 2 May 2019 23:06:06 +0000 Original-Received: from localhost ([127.0.0.1]:47275 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMKmE-0002tv-HL for submit@debbugs.gnu.org; Thu, 02 May 2019 19:06:06 -0400 Original-Received: from mail-wr1-f44.google.com ([209.85.221.44]:45026) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMKmC-0002tP-QG for 33992@debbugs.gnu.org; Thu, 02 May 2019 19:06:05 -0400 Original-Received: by mail-wr1-f44.google.com with SMTP id c5so5498085wrs.11 for <33992@debbugs.gnu.org>; Thu, 02 May 2019 16:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=/LI1t1PslZnhhlcQR3oJlOq/Oc+44SECnAW0f8/obps=; b=AKEE6aeb23ILJE42O8JHqO9JBH+YdFLRx8/M0c6sU0v9n4pwhvN0UEXBHuH42I+buV bTdC+rEWWtIy9pGeqy8rm+2KVWyWrWI05DnqT4uuqHiUAAdGF27a0w7sYR/rfW1DnWOj 1twzfzQzsS2XNyMlEAI4xNzs2Kk1c3vA0HizdgZuPQsec/8ta20/zLRa1ZzU+0m/hjEJ t6KIogd4COj6r4UlZrzRSyT0S4TwDYJHlUUjeXyhFc0rEiddiUN5XVDEBcD4DhVe9MlC +f3kQ7BWLqxwCdptJu+OHjA/IFeDrlX5DGZ2SCr+c+LkG1cuFuQeKye7INEJwri0Bn0g qnJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/LI1t1PslZnhhlcQR3oJlOq/Oc+44SECnAW0f8/obps=; b=YwUxm9lgtkmVE3WC4QI16e0YRHCG8j9lONVM0KlWkIOpIW65Lnw1vozhigwxh8n8mH WSU5Gu0EOu38wd6Z3SA65v6YbDKtE/zZ9Zg66LxRFLLOL2Hy4OhvdmwjMHUrg8l2WxEU 0XbHGkJAGGtslMDp24z0P5NXGnsc6Ee2tNzQoJuXzlotnLRiKnBGj88Ie+dEETgdFQTD tyPgcKFnVnWu39U9G4Cn/DO9mRhVe7mTg2P4Wb0DxJ2/oXNuYSi8F4atoaziVSb/fM4+ 64KEpGLuDFBzLE1biPy29RNdg5Vdw3a5EBvDZpcnYEG3hnNUd0H/LN6f1Jv+NDBALEne qllw== X-Gm-Message-State: APjAAAUjrrB+BYWQbFOHlYmj5gluhEc8Xs58q22Yqsc/dW+nWLrFFsGy Vmmhh2m2L6zAh97ASACFQo4= X-Google-Smtp-Source: APXvYqxniY9JNaBXUc5hxfAE9jb4LboQc/YYYlUE6tB9EZjgBfLLg2rKzBehH3DPh8IxzId03GB0ww== X-Received: by 2002:adf:8567:: with SMTP id 94mr4694919wrh.286.1556838358826; Thu, 02 May 2019 16:05:58 -0700 (PDT) Original-Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id f3sm3363823wmb.1.2019.05.02.16.05.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 May 2019 16:05:57 -0700 (PDT) In-Reply-To: <87lg0m96bm.fsf@mail.linkov.net> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.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" Xref: news.gmane.org gmane.emacs.bugs:158675 Archived-At: On 07.04.2019 0:03, Juri Linkov wrote: >>>> Does it feel the same way to you? >>> >>> The difference is that completions pop up in a small unobtrusive window. >> >> Small window? I usually have a side-by-side fullscreen split, and if >> I initiate completion in one of the windows, *Completion* takes up the >> whole other window. Temporarily, of course. > > The key word here is 'Temporarily'. Unlike *Completions*, > the *xref* buffer doesn't go out easily. I can understand that. So yes, I can see myself preferring some different behavior for a particular command. >>> (defun display-buffer-condition-from-xref (_buffer-name _action) >>> (string-match-p "\\`\\*\\(xref\\)\\*\\(\\|<[0-9]+>\\)\\'" >>> (buffer-name (current-buffer)))) >> >> This function seems unused. > > It's unused because it would be useful only in the *xref* buffer > created by the xref-find-definitions command, so xref needs to > provide a way to distinguish such case. Shouldn't it be referenced somewhere else in your patch as well? >>> (setq display-buffer-alist >>> '((display-buffer-condition-xref >>> display-buffer-in-direction >> >> And this function is undefined in my Emacs. > > This function is implemented by Martin in bug#33870. OK, found it, tried it. Seems to work okay-ish for xref-find-definitions, except xref-quit-and-goto-xref doesn't seem to be functioning too well together with your customization (every other time it seemed to use a different window to display the location, not the one I called xref-find-definitions from). >>> (with-eval-after-load 'xref >>> (define-key xref--button-map [(control ?m)] #'xref-quit-and-goto-xref)) >>> >>> How do you like that? >> >> I might, but since I can't really try your customization myself yet, I'll >> repeat a question you might be familiar with already: >> >> Will this also affect xref-find-references and project-find-regexp? > > It should not affect them due to (memq this-command '(xref-find-definitions)) > above. It would affect them due to the modification of xref--button-map above, though. This part I don't like. > But also to not affect commands active in the *xref* buffer, > xref should provide a way to check if the *xref* buffer was created > by xref-find-definitions. Yes, we should retain some extra information, e.g. to support revert-buffer.