From unknown Wed Jun 18 23:03:10 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#33992 <33992@debbugs.gnu.org> To: bug#33992 <33992@debbugs.gnu.org> Subject: Status: 27.0.50; xref-find-definitions wastes too much space Reply-To: bug#33992 <33992@debbugs.gnu.org> Date: Thu, 19 Jun 2025 06:03:10 +0000 retitle 33992 27.0.50; xref-find-definitions wastes too much space reassign 33992 emacs submitter 33992 Juri Linkov severity 33992 wishlist tag 33992 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 05 18:50:36 2019 Received: (at submit) by debbugs.gnu.org; 5 Jan 2019 23:50:37 +0000 Received: from localhost ([127.0.0.1]:48135 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gfvi8-0006G6-It for submit@debbugs.gnu.org; Sat, 05 Jan 2019 18:50:36 -0500 Received: from eggs.gnu.org ([208.118.235.92]:53822) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gfvi4-0006Fv-EV for submit@debbugs.gnu.org; Sat, 05 Jan 2019 18:50:33 -0500 Received: from listsout.gnu.org ([208.118.235.17]:33860) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gfvi4-0005kr-1K for submit@debbugs.gnu.org; Sat, 05 Jan 2019 18:50:32 -0500 Received: from eggsout.gnu.org ([209.51.188.92]:36076 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gfvi3-0007T9-2I for bug-gnu-emacs@gnu.org; Sat, 05 Jan 2019 18:50:31 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gfvhz-0005gN-DJ for bug-gnu-emacs@gnu.org; Sat, 05 Jan 2019 18:50:30 -0500 Received: from golden.birch.relay.mailchannels.net ([23.83.209.73]:25983) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gfvhx-0005eJ-R7 for bug-gnu-emacs@gnu.org; Sat, 05 Jan 2019 18:50:26 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 2C3653E403A for ; Sat, 5 Jan 2019 23:50:24 +0000 (UTC) Received: from pdx1-sub0-mail-a35.g.dreamhost.com (unknown [100.96.19.74]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id CB7193E419D for ; Sat, 5 Jan 2019 23:50:23 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a35.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Sat, 05 Jan 2019 23:50:24 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Illegal-Power: 309712aa3d530a61_1546732223985_2994925292 X-MC-Loop-Signature: 1546732223985:337100994 X-MC-Ingress-Time: 1546732223985 Received: from pdx1-sub0-mail-a35.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a35.g.dreamhost.com (Postfix) with ESMTP id 72685811B1 for ; Sat, 5 Jan 2019 15:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to :subject:date:message-id:mime-version:content-type; s= linkov.net; bh=k8Hd9nVsvMMVleU7zqMWCNX1GfE=; b=RSRYsIvZoIUBCmvij mcBuHC2wIt1nPKfkfgYciZZvsGJaYKOKd6uOpfFb8uFKHjhI+kNx/g+lM8VsgdlW jHKNDAzKjlyvIWVER26DYVznTO7YRWQaSKyPNkR0HQNbCcH7lJ9PKwyOlQB8QH/e pNzmctGfQvx5WmiGu+tIYUod/E= Received: from mail.jurta.org (m91-129-109-141.cust.tele2.ee [91.129.109.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 5B4AA7F4DE for ; Sat, 5 Jan 2019 15:50:20 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a35 From: Juri Linkov To: bug-gnu-emacs@gnu.org Subject: 27.0.50; xref-find-definitions wastes too much space Organization: LINKOV.NET Date: Sun, 06 Jan 2019 01:43:35 +0200 Message-ID: <87muoe7jrs.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtledrvdeggdduhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufhofffkfgggtgesmhdtreertderjeenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucfkphepledurdduvdelrddutdelrddugedunecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledruddtledrudeguddprhgvthhurhhnqdhprghthheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqedpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnrhgtphhtthhopegsuhhgqdhgnhhuqdgvmhgrtghssehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptd X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 23.83.209.73 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: -4.1 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.1 (-----) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Tags: patch Severity: wishlist X-Debbugs-CC: Jo=C3=A3o T=C3=A1vora , Dmitry Gutov = As noted in bug#33870 the buffer produced by xref-find-definitions (bound to =E2=80=98M-.=E2=80=99) has a transient nature like the *Complet= ions* buffer. Therefore it makes sense not to waste its space needlessly: --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=display-action-alist.patch diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index 87ce2299c5..169f49a348 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -782,7 +773,7 @@ xref--show-xref-buffer (erase-buffer) (xref--insert-xrefs xref-alist) (xref--xref-buffer-mode) - (pop-to-buffer (current-buffer)) + (pop-to-buffer (current-buffer) (assoc-default 'display-action-alist alist)) (goto-char (point-min)) (setq xref--original-window (assoc-default 'window alist) xref--original-window-intent (assoc-default 'display-action alist)) @@ -808,12 +799,15 @@ xref--show-xrefs (cond ((and (not (cdr xrefs)) (not always-show-list)) (xref-push-marker-stack) - (xref--pop-to-location (car xrefs) display-action)) + (xref--pop-to-location (car xrefs) (unless (listp display-action) display-action))) (t (xref-push-marker-stack) (funcall xref-show-xrefs-function xrefs `((window . ,(selected-window)) - (display-action . ,display-action)))))) + (display-action + . ,(unless (listp display-action) display-action)) + (display-action-alist + . ,(when (listp display-action) display-action))))))) (defun xref--prompt-p (command) (or (eq xref-prompt-for-identifier t) @@ -864,7 +858,7 @@ xref-find-definitions Otherwise, display the list of the possible definitions in a buffer where the user can select from the list." (interactive (list (xref--read-identifier "Find definitions of: "))) - (xref--find-definitions identifier nil)) + (xref--find-definitions identifier '((display-buffer-maybe-below-selected)))) ;;;###autoload (defun xref-find-definitions-other-window (identifier) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 06 06:03:37 2019 Received: (at 33992) by debbugs.gnu.org; 6 Jan 2019 11:03:37 +0000 Received: from localhost ([127.0.0.1]:48253 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gg6DQ-0006Fp-QE for submit@debbugs.gnu.org; Sun, 06 Jan 2019 06:03:37 -0500 Received: from mail-qt1-f172.google.com ([209.85.160.172]:32895) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gg6DO-0006FX-QI for 33992@debbugs.gnu.org; Sun, 06 Jan 2019 06:03:35 -0500 Received: by mail-qt1-f172.google.com with SMTP id l11so44992297qtp.0 for <33992@debbugs.gnu.org>; Sun, 06 Jan 2019 03:03:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7q7kIBaqteK+zxHYh8B9uSz4qvp5mcybolRSY4rYY88=; b=Robi73Q2o5XHjt6I2t48bhX4Bixj9p0LhKG1PGr5Kuh5t18WvyRGQH1nOEpMvYgUP1 RiN38yn5zYBEb1wBit7yMQ2c1UlFloHwo3+LtjbDrgHIlLA2xdHezrGNVfQ+6XTgc4JP Gqef2lZEJvLTXGBwsLWIaFaLCma5VTmsJPDcOBL3NuvscAZINBler05EPmWBSSYw8wp6 PpYzCumVLIL+rgy8WyLkb7HWz3bTMLWVV1Bu/2UczKm8IhnhFD2z6nVj5R3m/pJZnXta m893+mBAXMJRy/uurwYD+dJbmoNgBlwTRDF1koijJYSCzjLLhjOsj00JZlQxQctno4k6 oL3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7q7kIBaqteK+zxHYh8B9uSz4qvp5mcybolRSY4rYY88=; b=GV2088r/QPdMruMDMbICTtZqPgcY4tyDcAsXsI376TT7KSKjuf7X8a0Snk2zcddQxS R21qs4MROsJSIY+miKON/LgxoZJlnuNnib1k0fu3AOAzu5A4yKbSsYRP4P8qgW3smUII wMD/Cwl+9+mk6BXTz02Xk9PaSYOfsVXTbYEWWtHKi66GSI79/m8C6IBJx+aFwTbSL32p GtgkajUwqmO2d92fSbN52J7nvnVtwWfzhXnKEUq+bMCPOLyKnMpbGcvYicJlgHQlPF+Y DGnvZnGX+oMeAtLNnl042/ugvgNDIfKtxs9pqFV+KEJ+Ydnh2g4tXvgDr0I2m9m644pn CTRw== X-Gm-Message-State: AA+aEWajNnvNLNex0uWw480QJsEp0uSmxq8b0TpysnwvkzQjFWd3OpRR 5lbi7vqTev8qtpALLPg4QOgihRivDvlos2ERinA= X-Google-Smtp-Source: ALg8bN4cgkz+QoClij/eDtXY+PQo9Ek6YP6dfN5HZgYQ2sXmCExttXdtzSKajHrgXmV0FwjL8BggQzPFuaa6NSdGRmI= X-Received: by 2002:ac8:88:: with SMTP id c8mr57426191qtg.218.1546772609327; Sun, 06 Jan 2019 03:03:29 -0800 (PST) MIME-Version: 1.0 References: <87muoe7jrs.fsf@mail.linkov.net> In-Reply-To: <87muoe7jrs.fsf@mail.linkov.net> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Sun, 6 Jan 2019 11:03:18 +0000 Message-ID: Subject: Re: bug#33992: 27.0.50; xref-find-definitions wastes too much space To: Juri Linkov Content-Type: multipart/alternative; boundary="000000000000ed692a057ec80fa7" X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 33992 Cc: 33992@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.9 (/) --000000000000ed692a057ec80fa7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jan 5, 2019, 23:51 Juri Linkov Tags: patch > Severity: wishlist > X-Debbugs-CC: Jo=C3=A3o T=C3=A1vora , Dmitry Gutov = < > dgutov@yandex.ru> > > As noted in bug#33870 the buffer produced by xref-find-definitions > (bound to =E2=80=98M-.=E2=80=99) has a transient nature like the *Complet= ions* buffer. > Therefore it makes sense not to waste its space needlessly: > It doesn't make sense to review this patch until the patch that fixes 33870 has been produced. Jo=C3=A3o > > --000000000000ed692a057ec80fa7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, = Jan 5, 2019, 23:51 Juri Linkov <juri@= linkov.net wrote:
Tags: patch Severity: wishlist
X-Debbugs-CC: Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com>, Dmi= try Gutov <dgutov@yandex.ru>

As noted in bug#33870 the buffer produced by xref-find-definitions
(bound to =E2=80=98M-.=E2=80=99) has a transient nature like the *Completio= ns* buffer.
Therefore it makes sense not to waste its space needlessly:

It doesn't m= ake sense to review this patch until the patch that fixes 33870 has been pr= oduced.

Jo=C3=A3o
<= div dir=3D"auto">

--000000000000ed692a057ec80fa7-- From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 20 18:35:06 2019 Received: (at 33992) by debbugs.gnu.org; 20 Mar 2019 22:35:07 +0000 Received: from localhost ([127.0.0.1]:52315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h6jne-0002mB-DZ for submit@debbugs.gnu.org; Wed, 20 Mar 2019 18:35:06 -0400 Received: from firebrick.maple.relay.mailchannels.net ([23.83.214.59]:12259) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h6jnc-0002ly-FN for 33992@debbugs.gnu.org; Wed, 20 Mar 2019 18:35:05 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id F084E2C1366; Wed, 20 Mar 2019 22:35:02 +0000 (UTC) Received: from pdx1-sub0-mail-a45.g.dreamhost.com (100-96-12-106.trex.outbound.svc.cluster.local [100.96.12.106]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 77C342C1B67; Wed, 20 Mar 2019 22:35:02 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a45.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Wed, 20 Mar 2019 22:35:02 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Wipe-Glossy: 34a66aee76c365f3_1553121302702_3435010263 X-MC-Loop-Signature: 1553121302702:982975068 X-MC-Ingress-Time: 1553121302701 Received: from pdx1-sub0-mail-a45.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a45.g.dreamhost.com (Postfix) with ESMTP id 14FEB81B25; Wed, 20 Mar 2019 15:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=linkov.net; bh=ouq+dF wLuIhg1abl+JcjCp6xpFs=; b=xmzHz45Hiuk5T9FG4/qZLIk/8XPpNbOTdGh8Nr lAPPos1lBlnAWU9Y7yZxkd/bPmHWUJlQi4rdSN8JTb+yCtvQ5Du1UDmsOmZTHXly qUZwFlKk0KpuS+wbnmRpqBdUUbwo3pbf6TX3jUKhG7FtTGCYdzOkAjLVvKWEHH0c TawTk= Received: from mail.jurta.org (m91-129-108-250.cust.tele2.ee [91.129.108.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a45.g.dreamhost.com (Postfix) with ESMTPSA id D805181B23; Wed, 20 Mar 2019 15:34:54 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a45 From: Juri Linkov To: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= Subject: Re: bug#33992: 27.0.50; xref-find-definitions wastes too much space Organization: LINKOV.NET References: <87muoe7jrs.fsf@mail.linkov.net> Date: Wed, 20 Mar 2019 23:37:54 +0200 In-Reply-To: (=?iso-8859-1?Q?=22Jo=E3o_T=E1vora=22's?= message of "Sun, 6 Jan 2019 11:03:18 +0000") Message-ID: <87a7hp43a5.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedutddrieeigdduieefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgfgsehtkeertddtreejnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledruddtkedrvdehtdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepmhgrihhlrdhjuhhrthgrrdhorhhgpdhinhgvthepledurdduvdelrddutdekrddvhedtpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepjhhorghothgrvhhorhgrsehgmhgrihhlrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33992 Cc: 33992@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> As noted in bug#33870 the buffer produced by xref-find-definitions >> (bound to =E2=80=98M-.=E2=80=99) has a transient nature like the *Comp= letions* buffer. >> Therefore it makes sense not to waste its space needlessly: > > It doesn't make sense to review this patch until the patch that fixes 3= 3870 > has been produced. Since the patch from bug#33870 has been already committed, this bug#33992 is undeadlocked now. The problem with xref-find-definitions is its unexpected outcome: sometimes it pops up a window, sometimes doesn't. It's like Russian roulette: pull the trigger, bang and there is a hole in the screen that takes the form of glaringly empty space. The proposed change is not to break the window configuration: either split the selected window and show *xref* below, or do inline placement, i.e. to replace the content of the selected window with the *xref* buffer. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 20 19:24:02 2019 Received: (at 33992) by debbugs.gnu.org; 20 Mar 2019 23:24:02 +0000 Received: from localhost ([127.0.0.1]:52478 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h6kYz-0006A0-On for submit@debbugs.gnu.org; Wed, 20 Mar 2019 19:24:02 -0400 Received: from mail-qt1-f170.google.com ([209.85.160.170]:46388) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h6kYx-00069l-RI for 33992@debbugs.gnu.org; Wed, 20 Mar 2019 19:24:00 -0400 Received: by mail-qt1-f170.google.com with SMTP id z17so3647380qts.13 for <33992@debbugs.gnu.org>; Wed, 20 Mar 2019 16:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8glv0c4iMZiuBLEWOnx4RdybsoRKs/KAs83TRP18Zc8=; b=D6wbmLpVQ8KaPy/XXBm5/yTEJl7eIhJDGbKZIkww7I8MQJLzUysLfpkdWMHw2TUQ66 A56UIKA57UicbC1d/lzo2IqdnSwTJXnPqjMox41UIS6oVat603mWUD4VsIgNNPjaOz00 IV27rTHnOuckeeqxG2/mYkre0RjDtYxBr1IKgkN7mlU3hdumIW/CLPn/3wwzDpsUwuFd 0BfFlJZgFvJx3ug5A/bTfXX/MbtdQhe1ySp2BXAX23aVhYBBlST4WlV1bDka7SPlNuQ8 bdcg8OHuTpmdq0N+0tVsRHr7B3qCm/EdLh5Xq2dpVriSK2DP7Je+A23f/XAZOlbDiNS8 IH1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8glv0c4iMZiuBLEWOnx4RdybsoRKs/KAs83TRP18Zc8=; b=BIcishlqphxZ4zuFfJmJhy1LUMAUAQuQpR/hzMFs1WERplLyyQ1V0gqN1HMHB1hgEu Kqsu09gtcyrrOsj8MZ02A8CNAG1Jk8DJVIvG6E/BMt0H1IRdgwJSnvqRMH7kS4bW4soi cIl9ijHcjgZNMP9wLiDQfoJbPev/Vt4whBCuzG5t4P4YrlsL3unBADPZlWNsLYwaP6YA 1nAjrcmJrIDP709wduFYwvp1EniD2zXb97UlVeUue/erzY9BgMFNBFUFkHFFu/wGFn3k a+Y5VYKC3cErdV7FYXlf9y/z5rNC/6n0tUuRnC+5BdiB5QHRpskcpXZoxOp0+sal2ZOV TeNw== X-Gm-Message-State: APjAAAXUtacCf1SKpKkm1yGIGgMPrFPNPy3hWK8jAO2SKrsVUJ0Z4EUg AKbeGOMaOOpeMjDvkN/sUouyvKysQwXw48pLgyQ= X-Google-Smtp-Source: APXvYqz6V04AV88MsPquF6yoI8FRo0Zzpb7rBRKmr/2aRaUJRVOt5RboeLcD2LrAi7chOXms/f2fpwA8okDIHjyFHDM= X-Received: by 2002:a0c:a423:: with SMTP id w32mr586257qvw.104.1553124234319; Wed, 20 Mar 2019 16:23:54 -0700 (PDT) MIME-Version: 1.0 References: <87muoe7jrs.fsf@mail.linkov.net> <87a7hp43a5.fsf@mail.linkov.net> In-Reply-To: <87a7hp43a5.fsf@mail.linkov.net> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Wed, 20 Mar 2019 23:23:43 +0000 Message-ID: Subject: Re: bug#33992: 27.0.50; xref-find-definitions wastes too much space To: Juri Linkov Content-Type: multipart/alternative; boundary="000000000000475bf005848eea30" X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 33992 Cc: 33992@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.9 (/) --000000000000475bf005848eea30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2019 at 10:35 PM Juri Linkov wrote: > >> As noted in bug#33870 the buffer produced by xref-find-definitions > >> (bound to =E2=80=98M-.=E2=80=99) has a transient nature like the *Comp= letions* buffer. > >> Therefore it makes sense not to waste its space needlessly: > > > > It doesn't make sense to review this patch until the patch that fixes > 33870 > > has been produced. > > Since the patch from bug#33870 has been already committed, > this bug#33992 is undeadlocked now. > > The problem with xref-find-definitions is its unexpected outcome: > sometimes it pops up a window, sometimes doesn't. > > It's like Russian roulette: pull the trigger, bang and there is > a hole in the screen that takes the form of glaringly empty space. > I understand, but somehow I'm not very offended by that. It's just something I've grown so used to, even before xref. Just C-h f to a function description of which you know nothing of the length and boom, a lot of empty space too. While I do vaguely remember being annoyed by it many years ago, I don't now. And for xref I like to see it well highlighted away from any other text, so I can easily count the references. Displaying next to the minibuffer are would surround it with more noise. It's just the way I work. Fortunately now it is customizable, right? How about adding an entry to the manual, in the xref section, mentioning a couple of commands or customization variables that can be used to get the interface that you prefer, Juri? Jo=C3=A3o --000000000000475bf005848eea30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Mar 20, 2019 at 10:35 PM Juri Lin= kov <juri@linkov.net> wrote:
>> As noted in bug#33870 the buffer produced by xref-find-= definitions
>> (bound to =E2=80=98M-.=E2=80=99) has a transient nature like the *= Completions* buffer.
>> Therefore it makes sense not to waste its space needlessly:
>
> It doesn't make sense to review this patch until the patch that fi= xes 33870
> has been produced.

Since the patch from bug#33870 has been already committed,
this bug#33992 is undeadlocked now.

The problem with xref-find-definitions is its unexpected outcome:
sometimes it pops up a window, sometimes doesn't.

It's like Russian roulette: pull the trigger, bang and there is
a hole in the screen that takes the form of glaringly empty space.

I understand, but somehow I'm not very offe= nded by that.=C2=A0 It's just
something I've grown so use= d to, even before xref.=C2=A0 Just C-h f to
a function descr= iption of which you know nothing of the length
and boom, a l= ot of empty space too.

While I do vag= uely remember being annoyed by it many years ago,
I don't now= . And for xref I like to see it well highlighted away from any
other text, so I can easily count the references.=C2=A0 Displaying next = to the
minibuffer are would surround it with more noise.

It's just the way I work.=C2=A0 Fortunately = now it is customizable, right? How about
adding an entry to the m= anual, in the xref section, mentioning a couple of
commands or cu= stomization variables that can be used to get the interface
that = you prefer, Juri?

Jo=C3=A3o
--000000000000475bf005848eea30-- From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 03 20:02:45 2019 Received: (at 33992) by debbugs.gnu.org; 4 Apr 2019 00:02:45 +0000 Received: from localhost ([127.0.0.1]:43449 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBpq8-0003KN-Mc for submit@debbugs.gnu.org; Wed, 03 Apr 2019 20:02:44 -0400 Received: from mail-lf1-f46.google.com ([209.85.167.46]:36188) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBpq6-0003K9-Fd for 33992@debbugs.gnu.org; Wed, 03 Apr 2019 20:02:43 -0400 Received: by mail-lf1-f46.google.com with SMTP id d18so433906lfn.3 for <33992@debbugs.gnu.org>; Wed, 03 Apr 2019 17:02:42 -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=J0iUhp1K3jjpYf5bb3EGAa/b0hpBfPDRoA56lmJ6AUg=; b=i06Tc5Lg6CJdiSFNmHUsDcB1TlM6LE2eTtUx8/VbcWaiyd37t1cQ/+sL6OAwPVdoS4 qoOhT+tUrlR/pe85L3igSQX/bXNYL1aYzhgsSJUZq/5+5sxV9CGRx/eQTUDQdL/pfdEe kU85RTs7B5Qr5YW5ySsAJvWbaocYtTfsM38OnHvM2tKDbx/QrgVh2tMpKuBJLLn93bPQ NeG6Tr8zlhvFc9oeMa9zxpQvWwGC/xvvL+u99l3Uvb6FNgUgftcYM8BrRZYbGDbwFjZS eujZhTFVX9pPDXJRCKMe7Dbprn6EWDp3Wq8eYuyWIzF+qA4Z76X5JZyHFdYZzd43ITNF 0qoA== 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=J0iUhp1K3jjpYf5bb3EGAa/b0hpBfPDRoA56lmJ6AUg=; b=qGmvEi1v1FE06i9OYdFtj0ljySGL0radxBOTVd223zx2JEp0/tB3FvxZlNZtr9cTDJ RqOPDoyEo7pJ3yk0z0oKZ0SE+orggdL6KyLdecPZHvVF3qIgTZLi53OPDBg6ehpKk6U6 1qYsKfn2iCZOVoeMx144hPRgILW+bdd+v/rhmutRuMShxU6RymSs7TEMdTw4JrbvoNfp sCSH/PPCCvzzgnAi0CG4E5OoHfiain2lxBNo0JRMzclEDbIJYWTmH9jqftr2MlsZD3Vn 05+N8nUf4N3AmYQWlPTyjYEQRZNN1wPZ0e3QPxIZAYsqXm3PcGkBS1MXJtKEtaLNJrtm FF5g== X-Gm-Message-State: APjAAAU2xbV04wdKcClTNlwVaXmPy9IO2OQRMzo32v4TNzEhv3z+2EMk UogT3q2AwOYRl/SEq0Ur4LHpzF8s X-Google-Smtp-Source: APXvYqw0DB948E5RuK0HiwrkGK+jkEpukWT5LWII+LFFaspXalKL09Cd0EhVFzh7nvYpUjfp2f4h2g== X-Received: by 2002:a05:6512:248:: with SMTP id b8mr1323401lfo.140.1554336156121; Wed, 03 Apr 2019 17:02:36 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id z29sm3236436lfg.52.2019.04.03.17.02.34 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 03 Apr 2019 17:02:35 -0700 (PDT) Subject: Re: bug#33992: 27.0.50; xref-find-definitions wastes too much space To: Juri Linkov , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= References: <87muoe7jrs.fsf@mail.linkov.net> <87a7hp43a5.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <205acda7-07a3-d85c-378c-c178f9f76b55@yandex.ru> Date: Thu, 4 Apr 2019 03:02:33 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:67.0) Gecko/20100101 Thunderbird/67.0 MIME-Version: 1.0 In-Reply-To: <87a7hp43a5.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 33992 Cc: 33992@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 20.03.2019 23:37, Juri Linkov wrote: > The problem with xref-find-definitions is its unexpected outcome: > sometimes it pops up a window, sometimes doesn't. Imagine the process of code completion. Sometimes you press TAB (or C-M-i) and it completes to the symbol you wanted. Sometimes it pops up a window with all matching completions instead. Does it feel the same way to you? From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 04 17:06:38 2019 Received: (at 33992) by debbugs.gnu.org; 4 Apr 2019 21:06:38 +0000 Received: from localhost ([127.0.0.1]:44750 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hC9ZF-000386-Kn for submit@debbugs.gnu.org; Thu, 04 Apr 2019 17:06:37 -0400 Received: from indri.birch.relay.mailchannels.net ([23.83.209.92]:5347) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hC9ZD-00037p-LI for 33992@debbugs.gnu.org; Thu, 04 Apr 2019 17:06:36 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 63F946A207A; Thu, 4 Apr 2019 21:06:29 +0000 (UTC) Received: from pdx1-sub0-mail-a31.g.dreamhost.com (100-96-7-52.trex.outbound.svc.cluster.local [100.96.7.52]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id A03EE6A1F6B; Thu, 4 Apr 2019 21:06:26 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a31.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Thu, 04 Apr 2019 21:06:29 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Ski-Grain: 72676cba69f7074f_1554411987047_2397886376 X-MC-Loop-Signature: 1554411987046:3989711819 X-MC-Ingress-Time: 1554411987046 Received: from pdx1-sub0-mail-a31.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a31.g.dreamhost.com (Postfix) with ESMTP id 1AFC983C91; Thu, 4 Apr 2019 14:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=linkov.net; bh=hrLQLi bkx9VJSUfkVqMgYnwwwa8=; b=zRrbnvojjekkW79v8xfLC3O9zjMFfZuA2r7PI1 dVHbpICY+lEnS1nhBpqYi2MOMwSk2lQD7KTc0CW7KKQYAaSCDM5GxR2WmMn5nq0h 6+fWEZoyQKy7/HwlLrt4P69+pNojK2CO9nOdAn3Iz2RxAmxr5rg06R/jpM4tYNve SwTCM= Received: from mail.jurta.org (m91-129-99-202.cust.tele2.ee [91.129.99.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a31.g.dreamhost.com (Postfix) with ESMTPSA id BD6F983C81; Thu, 4 Apr 2019 14:06:15 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a31 From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#33992: 27.0.50; xref-find-definitions wastes too much space Organization: LINKOV.NET References: <87muoe7jrs.fsf@mail.linkov.net> <87a7hp43a5.fsf@mail.linkov.net> <205acda7-07a3-d85c-378c-c178f9f76b55@yandex.ru> Date: Thu, 04 Apr 2019 23:49:27 +0300 In-Reply-To: <205acda7-07a3-d85c-378c-c178f9f76b55@yandex.ru> (Dmitry Gutov's message of "Thu, 4 Apr 2019 03:02:33 +0300") Message-ID: <87o95l4ht4.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrtdehgdduheeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgfgsehtkeertddtredunecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledrleelrddvtddvnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledrleelrddvtddvpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepughguhhtohhvseihrghnuggvgidrrhhunecuvehluhhsthgvrhfuihiivgeptd Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33992 Cc: 33992@debbugs.gnu.org, =?iso-8859-1?Q?Jo=E3o_T=E1vora?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> The problem with xref-find-definitions is its unexpected outcome: >> sometimes it pops up a window, sometimes doesn't. > > Imagine the process of code completion. > > Sometimes you press TAB (or C-M-i) and it completes to the symbol you > wanted. Sometimes it pops up a window with all matching > completions instead. > > Does it feel the same way to you? The difference is that completions pop up in a small unobtrusive window. But this should be easy to do in xref now too. Thanks to Jo=E3o, we now have configurable window management in xref, so I tried different customizations, and one of the most appealing is this: (defun display-buffer-condition-xref (buffer-name _action) (and (string-match-p "\\`\\*\\(xref\\)\\*\\(\\|<[0-9]+>\\)\\'" buffer-name) (memq this-command '(xref-find-definitions)))) (defun display-buffer-condition-from-xref (_buffer-name _action) (string-match-p "\\`\\*\\(xref\\)\\*\\(\\|<[0-9]+>\\)\\'" (buffer-name (current-buffer)))) (setq display-buffer-alist '((display-buffer-condition-xref display-buffer-in-direction (direction . below) (window-height . fit-window-to-buffer)))) (with-eval-after-load 'xref (define-key xref--button-map [(control ?m)] #'xref-quit-and-goto-xref= )) How do you like that? From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 04 19:07:11 2019 Received: (at 33992) by debbugs.gnu.org; 4 Apr 2019 23:07:11 +0000 Received: from localhost ([127.0.0.1]:44794 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hCBRu-0008Hf-Mo for submit@debbugs.gnu.org; Thu, 04 Apr 2019 19:07:10 -0400 Received: from mail-lf1-f52.google.com ([209.85.167.52]:44941) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hCBRs-0008HN-D5 for 33992@debbugs.gnu.org; Thu, 04 Apr 2019 19:07:09 -0400 Received: by mail-lf1-f52.google.com with SMTP id v71so2965579lfa.11 for <33992@debbugs.gnu.org>; Thu, 04 Apr 2019 16:07:08 -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=3nWPLM0E762t+FxqUJYmmreJkDLSWt280IuTNqIkLyk=; b=OfwK78B7/C9Tj6ZWqwJdQQp2y6iPzhIeqFWqGbHb3GU0GCvzIc40tb4Kys6mxD0kr9 6G4VPb2lSx83k8eL1fqh2+nwrgp1T4XONcrsbxlYn9vDGeX1PYsXjvMmeMUheQ4MAOB7 KJmd4JVy1wctGp7ycUHpwJ/eJ9aBnayzqmzlijgfOaqV1D2xxuHrW98ACECMSG15n9ZT JbYoYsc6OjEqVBIIn7KqBgeZbUp9lsRjvKXi58xl4R14k7vwXUyzj31N0A+HRx+NImQP dHW9awCJ1lUof2McgOndEkzXFSGywTIdfokSenifBo7chYXqLp8AyMXvDhsCAIVY2MYV h3qw== 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=3nWPLM0E762t+FxqUJYmmreJkDLSWt280IuTNqIkLyk=; b=dVxG0O1sh0E7NMjplR8YTl7lPgV6dYWMAVJa7svDIAIL3EYu+TNSpcOL9vNPntst5T omsQivZL6q73l8bgseJA+nCgKKrQ6aEfFfBYDGjJR4ZIfHXjRTySPjekX1Fmkky3daq+ FyVKxGNU4aVgiE7SkxNXtIIvZwwnBn8UC4o1wIYM3alqcQf21JcZijUhAzARD+7YuwhE ZbxeNDyoUVOW6SiqAZdn2KqSJhMfBILsQ4it8pAlpiSHC8umsVt/ukXHuIwd0mbMxNxC rjgoCZU1W1xZ6Z2G1+lizDu1IcogKyLoL9lnp9634HVHkUoOII41DGtjulEz+NdVmla7 3cPA== X-Gm-Message-State: APjAAAWV8stnib1ufPHP8McDogJxV9M4XkdjXjHOAsijVK4ko2c20ugu o/gD0qBWTxO4jrE0ttPAMWDid1uI X-Google-Smtp-Source: APXvYqxqaE2huKHJCJ5/Ul7WYlOXwz0u/mf3mT3hi9Hg7N4yEZBGr57KArv/dutdTdxsMo7SqcnUUA== X-Received: by 2002:a19:c203:: with SMTP id l3mr4519696lfc.39.1554419220953; Thu, 04 Apr 2019 16:07:00 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id 73sm4637785ljf.72.2019.04.04.16.06.58 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 04 Apr 2019 16:06:59 -0700 (PDT) Subject: Re: bug#33992: 27.0.50; xref-find-definitions wastes too much space To: Juri Linkov References: <87muoe7jrs.fsf@mail.linkov.net> <87a7hp43a5.fsf@mail.linkov.net> <205acda7-07a3-d85c-378c-c178f9f76b55@yandex.ru> <87o95l4ht4.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <64f42172-460f-a633-1c80-23d34b5c0d07@yandex.ru> Date: Fri, 5 Apr 2019 02:06:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:67.0) Gecko/20100101 Thunderbird/67.0 MIME-Version: 1.0 In-Reply-To: <87o95l4ht4.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 33992 Cc: 33992@debbugs.gnu.org, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 04.04.2019 23:49, 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. > But this should be easy to do in xref now too. > > Thanks to João, we now have configurable window management in xref, > so I tried different customizations, and one of the most appealing > is this: > > (defun display-buffer-condition-xref (buffer-name _action) > (and (string-match-p "\\`\\*\\(xref\\)\\*\\(\\|<[0-9]+>\\)\\'" > buffer-name) > (memq this-command '(xref-find-definitions)))) > > (defun display-buffer-condition-from-xref (_buffer-name _action) > (string-match-p "\\`\\*\\(xref\\)\\*\\(\\|<[0-9]+>\\)\\'" > (buffer-name (current-buffer)))) This function seems unused. > (setq display-buffer-alist > '((display-buffer-condition-xref > display-buffer-in-direction And this function is undefined in my Emacs. > (direction . below) (window-height . fit-window-to-buffer)))) > > (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? From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 05 05:44:27 2019 Received: (at 33992) by debbugs.gnu.org; 5 Apr 2019 09:44:27 +0000 Received: from localhost ([127.0.0.1]:45062 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hCLOd-0002Vd-2T for submit@debbugs.gnu.org; Fri, 05 Apr 2019 05:44:27 -0400 Received: from mail-wm1-f42.google.com ([209.85.128.42]:33376) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hCLOa-0002VN-Sa for 33992@debbugs.gnu.org; Fri, 05 Apr 2019 05:44:25 -0400 Received: by mail-wm1-f42.google.com with SMTP id z6so9309493wmi.0 for <33992@debbugs.gnu.org>; Fri, 05 Apr 2019 02:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:user-agent:face:date :message-id:mime-version; bh=F9GAVBADSQLdhRmGXotZdc+zCPzoKz/881jose7oRQQ=; b=XUASg4K9b1QZrCbtyXhIlMdT8sIe+Es2fnSuk/CyIsi341zf9LI+sHqwJtMm+SntR+ 5CWmEu4oIuaobhaCAyOCFjvOt2HVahDmcxSn2I04RYO3DwarYaO5l9OILYxt1yPZpWUm Z+wt57enkeDuUdkB/l505uGGPeOhBIFSByB8H5+/IRDwssQH+Y/2RlMamxljHH+eA4nh bo2GvgmEnh6a9b5wg+gaUxUaZG/dLpOottbjIMRMDSr4ej1Vz7P6gLK3EHLQywCh1Z2+ SZeznSQigVZu/DF8WbaEo/0sLcFITxbHz8hXjvz3r+k7tqs+bzDXR4lJaAai3bSjH+Go vLZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references :user-agent:face:date:message-id:mime-version; bh=F9GAVBADSQLdhRmGXotZdc+zCPzoKz/881jose7oRQQ=; b=rPmGywuZL/sQ/J15qu/9xRG/5AGz0qT+oPpyaZnXvWp05ukEWQHywFSQ+/ee6VF8tB pxYfVthRBOYvYsDmBFhrNe670oPkWMJP3ldHAdusIsxbF5bfd+HUmuKWTZd2UaFbn94h c5xaVT+RN0t4htSFLB+ANOzeUpNutd3WAPI5bq3RBx+n0xZSkfL23Eh8fPDZU71/L2yi T2XoNpN0jfYRWH6yM6+O8EW32rWrnWGa2Ac5KW02BlglfhtS6diUwO+7eJnm6I/kkhIo Ig+psCF70vl2XKNxko/NNTXYUgOxPdx82zPLAPPpEItVFn8IeiuLBtnNDb+NEJqmjdrk kGFQ== X-Gm-Message-State: APjAAAUprTojL+DNz1/D+DLiIpYIdBASKb0UXGrbZYRQMrDtpWJiDtwk 8p2ZpMt0XC7Obn3TC9zqE7Y= X-Google-Smtp-Source: APXvYqywn7sotUWSD0DMG+0cy5eT899K6Dtrpwo4+GE4ehsgayMgO9BKMgC5s2oBpXSHd3ruSf7CwQ== X-Received: by 2002:a1c:4e19:: with SMTP id g25mr7519188wmh.9.1554457458888; Fri, 05 Apr 2019 02:44:18 -0700 (PDT) Received: from ulti.gmail.com ([2001:738:2001:407f:d329:3c92:fe6f:14c3]) by smtp.gmail.com with ESMTPSA id a22sm1645039wmj.44.2019.04.05.02.44.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 05 Apr 2019 02:44:18 -0700 (PDT) From: Felician Nemeth To: 33992@debbugs.gnu.org Subject: Re: bug#33992: 27.0.50; xref-find-definitions wastes too much space In-Reply-To: <64f42172-460f-a633-1c80-23d34b5c0d07@yandex.ru> (Dmitry Gutov's message of "Fri, 5 Apr 2019 02:06:57 +0300") 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> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/25.1 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEX5+fmhoaEwMDD/ ///TMNVWAAAAAWJLR0QDEQxM8gAAAAlwSFlzAAAPEgAADxIBIZvyMwAAAAd0SU1FB+AICBUfHgLs gGoAAAGXSURBVCjPRdK/b5tAFAfw753gBEwM2ApMbuVIqf+Ko0qiyhOu4sj2xJBYMn/FUdX7UUUZ OjHgyvf+yj6IcW6Bjx53934ADEvs8bmEr8UVoTYTOyJO9KoYsVofN8kILdbeJ8Li6YpZWop4xOK0 VdfIoXmkHn5/5D7/Ts/8THacSqnkKTcMTxgUkVzFnEIRTKwwYYSCvzfg16f0i8YApW/XG/Pm8R49 dXjxKmRnxv3OwooQWcv4RUYem1fsNe/WU63uk7AmYxk78y32/ee2tZB4fO+WcZ7lnIGEolXW1EGw LfkSuQ0XTgRefgNlfNwRNV6QhBxJ8JNxTMUPyBqTd0bjaAP5G7NJRU39z80hLOZTjqB7K3tEEFSj aEsuQew6qBxxyhHjVUR7H7NpC9iHJZGLMCEuweqAqE1BHbfK2oRIz9EHYA/+wiFWru9smeVfuWNZ 2+NFtX80UA1TvJNdytM4DwO4kY7bJz8Qcd0G0ceslZGkkeoBsjUHwF1+jjM3XHaXEZ7mGLfwPFO+ RV9QLY2iEdmDo78D/gNPaXVYqd+pyQAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAxNi0wOC0wOFQyMzoz MDoyOCswMjowMGy/yHYAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMTYtMDgtMDhUMjM6MzA6MjgrMDI6 MDAd4nDKAAAAAElFTkSuQmCC Date: Fri, 05 Apr 2019 11:44:16 +0200 Message-ID: <87lg0ou6q7.fsf@ulti.tmit.bme.hu> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33992 Cc: Juri Linkov , =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= , Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) (Sorry for replying late, I've just read this bug report.) I thought that I didn't need to see the list of the xref results and the xrefs' window shrank the view of the code I wanted to study. So, I came up with the defun below. It presents the xref results without showing the xref window. I think this idea can be further developed. xref-show--xrefs-buffer could have an 'm' key binding that "minimizes" its window by switching to xref-show-xrefs-without-buffer (below) and that function can "maximize" back with the same 'm' key. A customizable variable could define the initial behavior. Also, I think we can enhance xref-pulse-momentarily to use a different face if there's only one xref to present. (defun xref-show-xrefs-without-buffer (xrefs alist) "Present the results of an xref query in a simple manner. To activate this feature, customize `xref-show-xrefs-function'." (xref--show-xref-buffer xrefs alist) (quit-window) (next-error) (message "%s (%s xrefs in total)" "\",\": previous xref \".\":next xref \"m\":show xref buffer" (length xrefs)) (set-transient-map (let ((map (make-sparse-keymap))) (define-key map (kbd ",") 'previous-error) (define-key map (kbd ".") 'next-error) (define-key map (kbd "m") (lambda () (interactive) (pop-to-buffer xref-buffer-name))) map) t)) (setq xref-show-xrefs-function 'xref-show-xrefs-without-buffer) From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 05 19:20:16 2019 Received: (at 33992) by debbugs.gnu.org; 5 Apr 2019 23:20:17 +0000 Received: from localhost ([127.0.0.1]:46362 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hCY86-0006ws-O8 for submit@debbugs.gnu.org; Fri, 05 Apr 2019 19:20:15 -0400 Received: from mail-lf1-f52.google.com ([209.85.167.52]:40207) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hCY84-0006wb-QB for 33992@debbugs.gnu.org; Fri, 05 Apr 2019 19:20:13 -0400 Received: by mail-lf1-f52.google.com with SMTP id a28so5505332lfo.7 for <33992@debbugs.gnu.org>; Fri, 05 Apr 2019 16:20:12 -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=4MrZpRuRFHWzvKmygmbytJ0AeZGGeGceSG6SqDocmcE=; b=Hw3hdbFoAKwTQaSpKudLPg8UVAqoZmUfan77+bBkej992E8B/3DBrWCjldV1RBoxCL XpJYO+HuVGKa2P7xXlZw10njOVbU6VVo6GGHVrqJnirMWkklIIRmz3N/+nyhT9bTh4Hr FhIFOQKUtvar09isfSa5PXURmG5MZH2xEJQe0QuuBoD9WTodMQbw1vrP+kW0VPxRYTqq D8Rjg1geod+y+evhKEeQCW9ckntn9SSypDJYbYlJru9gbnucYI9jCEzGo1A8Qgu4y877 RwhfSwv1aX6n76MYPRdf0Vr30Px2sBDUTDt/+uo5hXES6ow8lATgI9og46KRBI1RADjK op0A== 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=4MrZpRuRFHWzvKmygmbytJ0AeZGGeGceSG6SqDocmcE=; b=ax4i3URWnO2wJxQieQ4WBz/8EUN0E1FJc7tAqqxxlnEaQsAz1uodCUULdxoANQiVQL 0gHHHv4pyzSyvrBhAzHGXliwxzFV4EF3qTPN6X1UTLXyq+01h7CncmIsT4cBWE6a+mwF cUJuMSs2d7Ib4mnlKx34LJF7ryOPreQBlkyZvtS27N8OQp5AYzLKoqT9VXDMMlW0SGdr rnFGLq9tvyVP+2VWHv2lrL5CwGmJEtsLo2kPS0+vipPVniOgfhIEckwhKq1BI3ieluWq tHHfc68e4nVXZ1tcVFkn8dNiBi25qwEScCJnVedvfC2AyqnDfu6OEmj8Fou3lkkOdHwn dTOg== X-Gm-Message-State: APjAAAUvtrbx39DAbHerSnqpoAYr/XAfdUf07OvRsl0dhbll+F6vkH5O IOs8LLZlfIRUdO2C6CfDQbo= X-Google-Smtp-Source: APXvYqydHmBrK0nUXEYD0OTzPbxLt3OxDZ0MuyKBkE5lf2ePBDvsKnKtkN+qsCKGz2eda5DxCgeWkA== X-Received: by 2002:a19:f81a:: with SMTP id a26mr8504082lff.34.1554506406914; Fri, 05 Apr 2019 16:20:06 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id m28sm5167792lfc.54.2019.04.05.16.20.04 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 05 Apr 2019 16:20:05 -0700 (PDT) Subject: Re: bug#33992: 27.0.50; xref-find-definitions wastes too much space To: Felician Nemeth , 33992@debbugs.gnu.org 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> <87lg0ou6q7.fsf@ulti.tmit.bme.hu> From: Dmitry Gutov Message-ID: Date: Sat, 6 Apr 2019 02:20:02 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.0a1 MIME-Version: 1.0 In-Reply-To: <87lg0ou6q7.fsf@ulti.tmit.bme.hu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 33992 Cc: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 05.04.2019 12:44, Felician Nemeth wrote: > (Sorry for replying late, I've just read this bug report.) > > I thought that I didn't need to see the list of the xref results and the > xrefs' window shrank the view of the code I wanted to study. So, I came > up with the defun below. It presents the xref results without showing > the xref window. I think this idea can be further developed. For instance, by not calling xref--show-xref-buffer right away, and instead storing the arguments. And then maybe calling it later if the user types 'm'. You won't be able to use previous/next-error for such an implementation, though. > xref-show--xrefs-buffer could have an 'm' key binding that "minimizes" > its window by switching to xref-show-xrefs-without-buffer (below) and > that function can "maximize" back with the same 'm' key. A customizable > variable could define the initial behavior. I'm not a fan of this interface, personally. It's good that it's available, though. We will make xref-show-xrefs-function a defcustom sooner or later, when we're sure that it doesn't need to be changed much. > Also, I think we can enhance xref-pulse-momentarily to use a different > face if there's only one xref to present. Yes, but I'm not sure the user will quickly understand the meaning of the different face. Anyway, we can make the exact face name a defcustom (it's currently 'next-error'), and you'd be able to change it via 'let'. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 06 17:47:08 2019 Received: (at 33992) by debbugs.gnu.org; 6 Apr 2019 21:47:09 +0000 Received: from localhost ([127.0.0.1]:47546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hCt9X-0005aO-M8 for submit@debbugs.gnu.org; Sat, 06 Apr 2019 17:47:08 -0400 Received: from cichlid.maple.relay.mailchannels.net ([23.83.214.36]:33213) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hCt9U-0005aE-6v for 33992@debbugs.gnu.org; Sat, 06 Apr 2019 17:47:06 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 283AF8C0662; Sat, 6 Apr 2019 21:47:03 +0000 (UTC) Received: from pdx1-sub0-mail-a41.g.dreamhost.com (100-96-7-60.trex.outbound.svc.cluster.local [100.96.7.60]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 828DD8C0F7F; Sat, 6 Apr 2019 21:47:02 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a41.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Sat, 06 Apr 2019 21:47:03 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Minister-Squirrel: 262d4fb83624a6a6_1554587222988_3123383193 X-MC-Loop-Signature: 1554587222988:2116645507 X-MC-Ingress-Time: 1554587222988 Received: from pdx1-sub0-mail-a41.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a41.g.dreamhost.com (Postfix) with ESMTP id 98257800EA; Sat, 6 Apr 2019 14:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=WfcOyc69HfM55nhnEQo3/JGRIfg=; b= NAhFg/mpmsFBn+YofPSBK96B33hianh033nPYqS3aBUM0kM9RiAJtk+mvOOAiyWd 6ml367RH6GtiD5fThWUE0T6YvVkGz4fNxL5oB5mF9WrKPfftfc8st0BdWJMQFYSY ZBYN7BnTfHthxAGKBDt4D4h+wVVvDrLzG7BnJDxOMUs= Received: from mail.jurta.org (m91-129-99-202.cust.tele2.ee [91.129.99.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a41.g.dreamhost.com (Postfix) with ESMTPSA id 384E6800D9; Sat, 6 Apr 2019 14:46:54 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a41 From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#33992: 27.0.50; xref-find-definitions wastes too much space Organization: LINKOV.NET 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> Date: Sun, 07 Apr 2019 00:03:09 +0300 In-Reply-To: <64f42172-460f-a633-1c80-23d34b5c0d07@yandex.ru> (Dmitry Gutov's message of "Fri, 5 Apr 2019 02:06:57 +0300") Message-ID: <87lg0m96bm.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddruddtgddtfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffuohhfffgjkfgfgggtsehttdertddtredtnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledrleelrddvtddvnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledrleelrddvtddvpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepughguhhtohhvseihrghnuggvgidrrhhunecuvehluhhsthgvrhfuihiivgepud X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 33992 Cc: 33992@debbugs.gnu.org, =?iso-8859-1?Q?Jo=E3o_T=E1vora?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>> 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. >> (defun display-buffer-condition-xref (buffer-name _action) >> (and (string-match-p "\\`\\*\\(xref\\)\\*\\(\\|<[0-9]+>\\)\\'" >> buffer-name) >> (memq this-command '(xref-find-definitions)))) >> >> (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. >> (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. >> (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. 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 06 17:47:13 2019 Received: (at 33992) by debbugs.gnu.org; 6 Apr 2019 21:47:13 +0000 Received: from localhost ([127.0.0.1]:47549 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hCt9c-0005ag-Vj for submit@debbugs.gnu.org; Sat, 06 Apr 2019 17:47:13 -0400 Received: from otter.birch.relay.mailchannels.net ([23.83.209.139]:56879) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hCt9a-0005aW-BM for 33992@debbugs.gnu.org; Sat, 06 Apr 2019 17:47:11 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D27F35E1E76; Sat, 6 Apr 2019 21:47:08 +0000 (UTC) Received: from pdx1-sub0-mail-a41.g.dreamhost.com (100-96-11-84.trex.outbound.svc.cluster.local [100.96.11.84]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 4649A5E1EB7; Sat, 6 Apr 2019 21:47:08 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a41.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Sat, 06 Apr 2019 21:47:08 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Bored-Unite: 73c37456166bbc2f_1554587228674_3742267517 X-MC-Loop-Signature: 1554587228674:452368632 X-MC-Ingress-Time: 1554587228674 Received: from pdx1-sub0-mail-a41.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a41.g.dreamhost.com (Postfix) with ESMTP id 6C386800EA; Sat, 6 Apr 2019 14:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=MLCkjeXm6JGJzH4hk3wpSTQhsyI=; b= Kyn3C94Qmg5u/IAIxObLheyRmy2CajRf5sMEWN9TMv80SuWYMbcZMPifGy+S4fkT 5X5sPGCy3ozX4XguwOBy4Bua303OvIcb13QHZQAukG/wKUj8BlwdgayjA4TW/gsb jp41OtBgW0D6oJmJFIrtYspvL+cpuZgu7VxDwLLNa1s= Received: from mail.jurta.org (m91-129-99-202.cust.tele2.ee [91.129.99.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a41.g.dreamhost.com (Postfix) with ESMTPSA id F178E800E9; Sat, 6 Apr 2019 14:47:00 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a41 From: Juri Linkov To: Felician Nemeth Subject: Re: bug#33992: 27.0.50; xref-find-definitions wastes too much space Organization: LINKOV.NET 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> <87lg0ou6q7.fsf@ulti.tmit.bme.hu> Date: Sun, 07 Apr 2019 00:08:38 +0300 In-Reply-To: <87lg0ou6q7.fsf@ulti.tmit.bme.hu> (Felician Nemeth's message of "Fri, 05 Apr 2019 11:44:16 +0200") Message-ID: <874l7a962h.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddruddtgddtfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffuohhfffgjkfgfgggtsehttdertddtredtnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledrleelrddvtddvnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledrleelrddvtddvpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepfhgvlhhitghirghnrdhnvghmvghthhesghhmrghilhdrtghomhenucevlhhushhtvghrufhiiigvpedv X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33992 Cc: 33992@debbugs.gnu.org, =?iso-8859-1?Q?Jo=E3o_T=E1vora?= , Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > I thought that I didn't need to see the list of the xref results and the > xrefs' window shrank the view of the code I wanted to study. So, I came > up with the defun below. It presents the xref results without showing > the xref window. I think this idea can be further developed. > xref-show--xrefs-buffer could have an 'm' key binding that "minimizes" > its window by switching to xref-show-xrefs-without-buffer (below) and > that function can "maximize" back with the same 'm' key. A customizable > variable could define the initial behavior. This looks like good ol' find-tag and tags-loop-continue bound to M-, with an optional pop-up to the xref buffer by a dedicated key. From debbugs-submit-bounces@debbugs.gnu.org Thu May 02 19:06:06 2019 Received: (at 33992) by debbugs.gnu.org; 2 May 2019 23:06:06 +0000 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 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 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) 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) Subject: Re: bug#33992: 27.0.50; xref-find-definitions wastes too much space To: Juri Linkov 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> From: Dmitry Gutov Message-ID: Date: Fri, 3 May 2019 02:05:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <87lg0m96bm.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 33992 Cc: 33992@debbugs.gnu.org, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.9 (/) 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. From debbugs-submit-bounces@debbugs.gnu.org Wed May 15 17:54:45 2019 Received: (at 33992) by debbugs.gnu.org; 15 May 2019 21:54:45 +0000 Received: from localhost ([127.0.0.1]:53537 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hR1rJ-0002y8-0w for submit@debbugs.gnu.org; Wed, 15 May 2019 17:54:45 -0400 Received: from goldenrod.birch.relay.mailchannels.net ([23.83.209.74]:37557) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hR1rG-0002xw-4p for 33992@debbugs.gnu.org; Wed, 15 May 2019 17:54:43 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 986852C21AE; Wed, 15 May 2019 21:54:40 +0000 (UTC) Received: from pdx1-sub0-mail-a19.g.dreamhost.com (100-96-3-22.trex.outbound.svc.cluster.local [100.96.3.22]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 0446F2C2729; Wed, 15 May 2019 21:54:40 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a19.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Wed, 15 May 2019 21:54:40 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Decisive-Spill: 66484485591995e4_1557957280416_2256688060 X-MC-Loop-Signature: 1557957280416:952627905 X-MC-Ingress-Time: 1557957280415 Received: from pdx1-sub0-mail-a19.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a19.g.dreamhost.com (Postfix) with ESMTP id C07FB815F2; Wed, 15 May 2019 14:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=2qrc/4SvCDRXmGL+tvvKhCQpbT8=; b= OL2SzLuyzmr16zJXgWlQ9foqCxHqP5rq/WlAMXr/+GjB77x6FOx7DK3HYvq6KPKx 8HNIzPPPOG6emfr+IsLtI3kNeUL/RAOhqs8jUlIKhTom+p8EzTkae6IJ6gFmmNsW AvUBbPJKTCT+nDxHsV0P/b5zS+hD8zR2zsHAB16z/6g= Received: from mail.jurta.org (m91-129-96-230.cust.tele2.ee [91.129.96.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 1594B80AF2; Wed, 15 May 2019 14:54:31 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a19 From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#33992: 27.0.50; xref-find-definitions wastes too much space Organization: LINKOV.NET 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> Date: Wed, 15 May 2019 23:57:07 +0300 In-Reply-To: (Dmitry Gutov's message of "Fri, 3 May 2019 02:05:55 +0300") Message-ID: <87ftpfqvvg.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrleelgddtudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffuohhfffgjkfgfgggtsehttdertddtredtnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledrleeirddvfedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledrleeirddvfedtpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepughguhhtohhvseihrghnuggvgidrrhhunecuvehluhhsthgvrhfuihiivgeptd X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33992 Cc: 33992@debbugs.gnu.org, =?iso-8859-1?Q?Jo=E3o_T=E1vora?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>>> 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? A patch is proposed in a separate bug#35737. >>>> (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, Created a separate bug#35592. > 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). Yes, it should change its behavior depending on xref--original-command. >>>> (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. Created a separate bug#35702. From debbugs-submit-bounces@debbugs.gnu.org Wed May 15 18:38:06 2019 Received: (at 33992) by debbugs.gnu.org; 15 May 2019 22:38:07 +0000 Received: from localhost ([127.0.0.1]:53587 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hR2XG-000478-Mi for submit@debbugs.gnu.org; Wed, 15 May 2019 18:38:06 -0400 Received: from mail-lf1-f54.google.com ([209.85.167.54]:37378) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hR2XE-00046c-LF for 33992@debbugs.gnu.org; Wed, 15 May 2019 18:38:05 -0400 Received: by mail-lf1-f54.google.com with SMTP id q17so1058546lfo.4 for <33992@debbugs.gnu.org>; Wed, 15 May 2019 15:38: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=kYpHP6USArkGc4GLRHtjZDrjsH5YM4gquXXrBO7RXBU=; b=HS5035z4f1JOUMaFAKhxNhUu0GrEyj1N/FcP/LbXdGFQ7Oe6XaUuMTZPbDzUrpWpYL CsE+lvQYZoo/mms9E9POnyMV2uJ4ldr2v+dcRk178aXsFnrdd6uZhx0M7Y6DRs2jjrzw tksQ7OR5SQsnRBuuoiVNWSZi1206VWKHmpmgRVreJ86JYNWlNCgYuJm1SsySXRjtjIkO gMGB7r4Jg30aUXVjle4OR2JPouYhQly0rFqKFsr8Lmjl4hNtlv9sR0qcYl1Ml2l6qRLQ 9Sa3g1SAaYBP1Eu9C34HTn6Jq2AAg879cpgLZzwsfrTkLSetzclXtD6b/RHIAQbd02Lw jT5Q== 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=kYpHP6USArkGc4GLRHtjZDrjsH5YM4gquXXrBO7RXBU=; b=qJpaecl4rLtsoWPcdTx0V1+rxALk44/Kla1ODRdCpWUooA/eI3sbWtS9a8WgNhEgNZ b957RVIPNxCYWOSZbyLK8BL0Gci9c1yxHcnf5uqXhWPYUBy93jiAtBh5Ywvdaxcfmpa0 hNrnGLjLpRoTxfhn6XfogCSye38Mgr3UKbdHMcS+9eDyM2/aRYqVRnoQaAM69liNoiIv eo+ptV/sMw1g8AADaNrHXk/AzhCrPd3JJisJbKg1QWChJAhCo6kP+I4JO3R2moXsFKk/ +tJNodwPS4qrrrbZI0hML5Rzr5CurGtjBxrqyk8t47TFcQsl2/3JhkUA9VTqHsIfb0W4 rqTA== X-Gm-Message-State: APjAAAXAmZoGgEtRRx1gs2ONPU3PsSRTWBCrlkeCAokFZBaycJaFQPO/ nnxQMmeMqWraPOoK46hJJ0Y= X-Google-Smtp-Source: APXvYqzfZY+brBgOQdCnyQEnbFYLi24j0bvEGFWPXE8AiWd4AbSbnwSLCwbQos0U50m43X9+QdmNkg== X-Received: by 2002:ac2:434a:: with SMTP id o10mr16945634lfl.122.1557959877703; Wed, 15 May 2019 15:37:57 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id g14sm612375lfb.20.2019.05.15.15.37.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 May 2019 15:37:56 -0700 (PDT) Subject: Re: bug#33992: 27.0.50; xref-find-definitions wastes too much space To: Juri Linkov 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> <87ftpfqvvg.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <437558cf-3bd5-a6c7-e9d7-d22a87064d78@yandex.ru> Date: Thu, 16 May 2019 01:37:53 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <87ftpfqvvg.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33992 Cc: 33992@debbugs.gnu.org, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 15.05.2019 23:57, Juri Linkov wrote: >>>>> (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? > > A patch is proposed in a separate bug#35737. I don't see display-buffer-condition-from-xref used in that patch either, but it's not hugely important, really. > Created a separate bug#35592. Thanks. > Created a separate bug#35702. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue May 28 16:47:25 2019 Received: (at 33992-done) by debbugs.gnu.org; 28 May 2019 20:47:25 +0000 Received: from localhost ([127.0.0.1]:57320 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hVj0H-0006HE-7b for submit@debbugs.gnu.org; Tue, 28 May 2019 16:47:25 -0400 Received: from common.maple.relay.mailchannels.net ([23.83.214.38]:2820) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hVj0D-0006Gv-5H for 33992-done@debbugs.gnu.org; Tue, 28 May 2019 16:47:21 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 0E2CC1438A3; Tue, 28 May 2019 20:47:20 +0000 (UTC) Received: from pdx1-sub0-mail-a6.g.dreamhost.com (100-96-87-96.trex.outbound.svc.cluster.local [100.96.87.96]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 66A321437D1; Tue, 28 May 2019 20:47:19 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a6.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Tue, 28 May 2019 20:47:20 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Celery-Spicy: 31484798411821f4_1559076439887_426017321 X-MC-Loop-Signature: 1559076439887:3310718220 X-MC-Ingress-Time: 1559076439886 Received: from pdx1-sub0-mail-a6.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a6.g.dreamhost.com (Postfix) with ESMTP id 0C7B7801A1; Tue, 28 May 2019 13:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=wVDPGe4RfknWI3be/oTrUWJJbO0=; b= ckqdpojEnJb0MnNrbIYD8C0oUWOFNuFNlwPRtcnj+b5DUvC2UOnfPQdIk4tbudz0 IuUig4N3GqXXaYdsLXOsBIVhoOoUjrU2u6/wP+fqMeXkdWTctJXJsWzaokJrFiLr thNiBhZocBekHuUCpRP01nb9+C1ocpOATuUo2ZIBt2M= Received: from mail.jurta.org (m91-129-96-73.cust.tele2.ee [91.129.96.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a6.g.dreamhost.com (Postfix) with ESMTPSA id B84E08019B; Tue, 28 May 2019 13:47:09 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a6 From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#33992: 27.0.50; xref-find-definitions wastes too much space Organization: LINKOV.NET 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> <87ftpfqvvg.fsf@mail.linkov.net> <437558cf-3bd5-a6c7-e9d7-d22a87064d78@yandex.ru> Date: Tue, 28 May 2019 23:35:16 +0300 In-Reply-To: <437558cf-3bd5-a6c7-e9d7-d22a87064d78@yandex.ru> (Dmitry Gutov's message of "Thu, 16 May 2019 01:37:53 +0300") Message-ID: <871s0ifj1k.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddruddvhedgudehfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffuohhfffgjkfgfgggtsehttdertddtredtnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledrleeirdejfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepmhgrihhlrdhjuhhrthgrrdhorhhgpdhinhgvthepledurdduvdelrdeliedrjeefpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepughguhhtohhvseihrghnuggvgidrrhhunecuvehluhhsthgvrhfuihiivgepvd X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33992-done Cc: 33992-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> A patch is proposed in a separate bug#35737. I'm closing this request because now xref is customizable enough. And we have no more opinions for changing the default behavior. FWIW, this is what I currently use to customize xref-find-definitions to act more like Completions: (custom-set-variables '(display-buffer-alist '((display-buffer-to-xref-p display-buffer-in-direction (direction . below) (window-height . fit-window-to-buffer))))) (defun display-buffer-to-xref-p (buffer-name _action) (and (string-match-p "\\`\\*\\(xref\\)\\*\\(\\|<[0-9]+>\\)\\'" buffer-name) (memq this-command '(xref-find-definitions)))) (with-eval-after-load 'xref (defvar xref--original-command nil) (advice-add 'xref-find-definitions :after (lambda (&rest _args) (with-current-buffer (window-buffer) (setq-local xref--original-command 'xref-find-definitions)))) (define-key xref--button-map [(control ?m)] (lambda () (interactive) (if (memq xref--original-command '(xref-find-definitions)) (call-interactively 'xref-quit-and-goto-xref) (setq xref--original-window nil) (call-interactively 'xref-goto-xref))))) From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 09 20:35:47 2019 Received: (at 33992-done) by debbugs.gnu.org; 10 Jun 2019 00:35:47 +0000 Received: from localhost ([127.0.0.1]:55654 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ha8Hr-0000Cd-8b for submit@debbugs.gnu.org; Sun, 09 Jun 2019 20:35:47 -0400 Received: from mail-wr1-f43.google.com ([209.85.221.43]:39725) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ha8Hp-0000CP-4I for 33992-done@debbugs.gnu.org; Sun, 09 Jun 2019 20:35:46 -0400 Received: by mail-wr1-f43.google.com with SMTP id x4so4713376wrt.6 for <33992-done@debbugs.gnu.org>; Sun, 09 Jun 2019 17:35:45 -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=KaOtDSPN7vXLJDD5zctb7dfUmkvVzvyG/ZDOlD8kItc=; b=E1CgD20CFlKBzudQdKxj99p+Bo05o/hRVW/CIuV795hC/shpkOcJhY45NW5+6hnTq0 JSEkKmGDejBtcTqt5uX1jY3jZBh60AssznwIk0WBlJy9zn/M0rWzmtxluP4MNNytN4va RF76zf+Omoli7+c/K/DsPSMJfOdLwHI2fsTaPMEdHoW2+sRsguFpQkjiGtJdQlovsRpD 4TMdkuuDam08bvtV/QCKVfxOlwlRUfd6R1Wr8mXXSpIRf8pP6JevHcT5IL8v8juplyHc VOstaqw6BMDXPOVkfNOIDE8SmUgL8ADKSL5qJrwiWAx0J+Qjvwea2HbbpPt9Yi541GTm QgNg== 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=KaOtDSPN7vXLJDD5zctb7dfUmkvVzvyG/ZDOlD8kItc=; b=S6zS5NTZtYqGKijIv3j8kPBWsGsRJsy+MYUWeHMTjqu3fSHfS5yy8+Ypr/TyuE6/Lf HypK2RW85tQRgWWi8YthrFR4hE9jHnooiUdRc0jc+0shilwm9WaSx7ZrfhNrcNw4hvCh YbXLgZE1WypN5NRXfeJJN5mhvzMpQ24ltDvc1Vx9f1Z02AWJL26p3qpmp95If8LIqGwQ IOcxXFK/cn/1+0Kkc4INVCFZTCNRS02PNr4mTgXi8LhU/B59HP4j7ecPI2Paa72Ipcs1 lNNBl7HFGKNBcM9ahQzJCFs38rZNE6SDAGeqPvsHRDjmbTbs439e9R1p0TncrokysPZk tmOQ== X-Gm-Message-State: APjAAAU1yWkAjUs7IMr0cYWzxWaxkBz0qRJqAS4Rj1ynsy+72oTTd7vW 6f9FQUDJBfwDPH+I4M5xZHI= X-Google-Smtp-Source: APXvYqySOExqPxz2t0nJTGCbj9nMG79k4RXdxCfNJTgEsv0Tb1cX1HBPTJ6MmkgReahrUW3qIIOF4w== X-Received: by 2002:a5d:5446:: with SMTP id w6mr29893150wrv.164.1560126939197; Sun, 09 Jun 2019 17:35:39 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id l190sm7013099wml.25.2019.06.09.17.35.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Jun 2019 17:35:38 -0700 (PDT) Subject: Re: bug#33992: 27.0.50; xref-find-definitions wastes too much space To: Juri Linkov 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> <87ftpfqvvg.fsf@mail.linkov.net> <437558cf-3bd5-a6c7-e9d7-d22a87064d78@yandex.ru> <871s0ifj1k.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: Date: Mon, 10 Jun 2019 03:35:36 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <871s0ifj1k.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 33992-done Cc: 33992-done@debbugs.gnu.org, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) Hi Juri, On 28.05.2019 23:35, Juri Linkov wrote: > FWIW, this is what I currently use to customize xref-find-definitions > to act more like Completions: > > (custom-set-variables > '(display-buffer-alist > '((display-buffer-to-xref-p display-buffer-in-direction > (direction . below) > (window-height . fit-window-to-buffer))))) > > (defun display-buffer-to-xref-p (buffer-name _action) > (and (string-match-p "\\`\\*\\(xref\\)\\*\\(\\|<[0-9]+>\\)\\'" > buffer-name) > (memq this-command '(xref-find-definitions)))) > > (with-eval-after-load 'xref > (defvar xref--original-command nil) > (advice-add 'xref-find-definitions :after > (lambda (&rest _args) > (with-current-buffer (window-buffer) > (setq-local xref--original-command 'xref-find-definitions)))) > (define-key xref--button-map [(control ?m)] > (lambda () > (interactive) > (if (memq xref--original-command '(xref-find-definitions)) > (call-interactively 'xref-quit-and-goto-xref) > (setq xref--original-window nil) > (call-interactively 'xref-goto-xref))))) JFYI, one of the changes I've pushed yesterday was the patch I've shown before, and it should let you have the same behavior with one line: (setq xref-show-definitions-function 'xref--show-defs-buffer-at-bottom) It doesn't seem like xref-quit-and-goto-xref works well, though. It doesn't always honor the intention to open the location in the window the command was called from. It can show the location in a different window, and then if I press M-, from there, Emacs does not return to the previous window configuration. I've tracked this down to xref--show-pos-in-buf. Apparently, calling display-buffer with `((display-buffer-in-previous-window) (previous-window . ,xref--original-window)) as its second argument doesn't do the trick. Looking at it, it contains logic where when (eq window (selected-window)), it sets best-window to something else (in particular, it can favor a window where this buffer had been displayed previously). So, should some other action function be used? I can trace this choice back to your commit 94b320849e9 where this bug was apparently introduced. From unknown Wed Jun 18 23:03:10 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 08 Jul 2019 11:24:07 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator