From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#33870: 27.0.50; xref-goto-xref not configurable Date: Wed, 09 Jan 2019 02:20:22 +0200 Organization: LINKOV.NET Message-ID: <87bm4qel4t.fsf@mail.linkov.net> References: <87a7ktqqx7.fsf@mail.linkov.net> <9215183d-0a44-88b5-5b3c-d0da31f749ad@yandex.ru> <878t02egph.fsf@mail.linkov.net> <874lak9kr0.fsf@mail.linkov.net> <87zhscklhq.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1546993731 15022 195.159.176.226 (9 Jan 2019 00:28:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 9 Jan 2019 00:28:51 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) Cc: 33870@debbugs.gnu.org, Dmitry Gutov To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 09 01:28:47 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 esmtp (Exim 4.84_2) (envelope-from ) id 1gh1ji-0003nB-FX for geb-bug-gnu-emacs@m.gmane.org; Wed, 09 Jan 2019 01:28:46 +0100 Original-Received: from localhost ([127.0.0.1]:42847 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gh1lp-0005Ad-Ci for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Jan 2019 19:30:57 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:55537) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gh1l0-0004Xk-IO for bug-gnu-emacs@gnu.org; Tue, 08 Jan 2019 19:30:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gh1ky-0006dl-ND for bug-gnu-emacs@gnu.org; Tue, 08 Jan 2019 19:30:06 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51398) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gh1kx-0006dL-Ja for bug-gnu-emacs@gnu.org; Tue, 08 Jan 2019 19:30:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gh1kx-0001QY-Ei for bug-gnu-emacs@gnu.org; Tue, 08 Jan 2019 19:30:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Jan 2019 00:30:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33870 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 33870-submit@debbugs.gnu.org id=B33870.15469937565322 (code B ref 33870); Wed, 09 Jan 2019 00:30:03 +0000 Original-Received: (at 33870) by debbugs.gnu.org; 9 Jan 2019 00:29:16 +0000 Original-Received: from localhost ([127.0.0.1]:50674 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gh1k9-0001Nk-UN for submit@debbugs.gnu.org; Tue, 08 Jan 2019 19:29:16 -0500 Original-Received: from indri.birch.relay.mailchannels.net ([23.83.209.92]:31070) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gh1k8-0001Na-1y for 33870@debbugs.gnu.org; Tue, 08 Jan 2019 19:29:12 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D7EFB502491; Wed, 9 Jan 2019 00:29:10 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a54.g.dreamhost.com (unknown [100.96.26.166]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 7A2785026C3; Wed, 9 Jan 2019 00:29:10 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from pdx1-sub0-mail-a54.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); Wed, 09 Jan 2019 00:29:10 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Shrill-Fearful: 425369c07cc0aa08_1546993750727_1380364570 X-MC-Loop-Signature: 1546993750727:1107268796 X-MC-Ingress-Time: 1546993750725 Original-Received: from pdx1-sub0-mail-a54.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a54.g.dreamhost.com (Postfix) with ESMTP id 25A1481339; Tue, 8 Jan 2019 16:29:10 -0800 (PST) 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=yAqZ7q edioUltIB2uHkOZwk/hF8=; b=17tB6LReBymayAkaO5K1itRWo3g9pbvQE+31q7 C2+BJDkVgkJDTJrO1xXutQMsK1oyzUWKxKk9EUA4+LgJ05GnemqU+ItdNreFhN17 pjdI+g8pDCCW5uCr8X2MQkxtRok/sZjBagGIPOmlTVssl533oTxcgXg8iiKLbd6s VSpUw= Original-Received: from mail.jurta.org (m91-129-101-91.cust.tele2.ee [91.129.101.91]) (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-a54.g.dreamhost.com (Postfix) with ESMTPSA id C069781350; Tue, 8 Jan 2019 16:29:06 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a54 In-Reply-To: <87zhscklhq.fsf@gmail.com> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Tue, 08 Jan 2019 01:04:49 +0000") X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtledrfedtgddvfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffuohhfffgjkfgfgggtgfesthekredttderjeenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucfkphepledurdduvdelrddutddurdeludenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepmhgrihhlrdhjuhhrthgrrdhorhhgpdhinhgvthepledurdduvdelrddutddurdeluddprhgvthhurhhnqdhprghthheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqedpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnrhgtphhtthhopehjohgrohhtrghvohhrrgesghhmrghilhdrtghomhenucevlhhushhtvghrufhiiigvpedu 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:154279 Archived-At: >> Of course, it doesn't work if you tried it only with part of my change= s. >> When I submitted my initial patch, I tested it in all your test cases, >> including the above test case that was not broken with my patch. > > You are correct. I was testing under the assumption that making > xref-goto-xref configurable didn't require the "tiny window" for > xref-find-definitions, which is something you stated that you wanted to > do for other xref.el commands like xref-find-references. Actually the xref window is not tiny at all if there are more results. It doesn't takes more space than needed, therefore there is no wasted spa= ce. >> My initial patch solved this problem gracefully by creating a new wind= ow >> for the xref buffer. > > You may well call this a problem, but it's not a bug. It's the defined > behaviour, it's like this by design. We are trying to create the > conditions that would enable you, or any other user, to create > alternative ways to present *xref* that have other advantages and > drawbacks. Let me reiterate the problem that prompted this report: please imagine a situation that you have two horizontally split windows with visited fil= es in each of them, and you happily browse xref definitions in the same wind= ow using M-. Then suddenly M-. replaces other half of the screen with empty space with only 2 lines at the top. This is because there is an ambiguity in findin= g definitions, and you need to resolve it. Then you start trying to reuse = some empty space it creates and trying to split the xref window. Instead of this, the split is applied to the original window. As a result, you have the original window split, and still half of the screen wasted with empty space. And most of all this mess is caused unexpectedly, i.e. you don't expect the xref window to break your windows when you type M-. Do you agree that we should respect user configuration, and use another window only when the user asks for it? If yes, then a good way to resolve this problem is to use a part of the original window to displa= y ambiguous results. This will keep the original window configuration. Now the question is what to do when the user asks to display a definition in another window using =E2=80=98C-x 4 .=E2=80=99 (xref-find-definitions-other-window). The most natural way is to immediately take the window pointed out by the user configuration (the user can configure to display it below/above/left/right etc.) and display the xref window in that window. Then visiting a definition still will remain in the same window preferred by the user. The same logic could also apply to xref-find-definitions-other-frame. This will allow xref-goto-xref to be configurable.