From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#33870: 27.0.50; xref-goto-xref not configurable Date: Tue, 08 Jan 2019 01:04:49 +0000 Message-ID: <87zhscklhq.fsf@gmail.com> References: <87a7ktqqx7.fsf@mail.linkov.net> <9215183d-0a44-88b5-5b3c-d0da31f749ad@yandex.ru> <878t02egph.fsf@mail.linkov.net> <874lak9kr0.fsf@mail.linkov.net> 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 1546909450 6414 195.159.176.226 (8 Jan 2019 01:04:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 8 Jan 2019 01:04:10 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 33870@debbugs.gnu.org, Dmitry Gutov To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jan 08 02:04:06 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 1ggfoL-0001Yx-OH for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Jan 2019 02:04:05 +0100 Original-Received: from localhost ([127.0.0.1]:59484 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ggfqS-0001e1-Fc for geb-bug-gnu-emacs@m.gmane.org; Mon, 07 Jan 2019 20:06:16 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:56079) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ggfqH-0001ct-9W for bug-gnu-emacs@gnu.org; Mon, 07 Jan 2019 20:06:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ggfqG-0008Mw-FJ for bug-gnu-emacs@gnu.org; Mon, 07 Jan 2019 20:06:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49815) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ggfqG-0008MY-Be for bug-gnu-emacs@gnu.org; Mon, 07 Jan 2019 20:06:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ggfqE-0004fG-Bg for bug-gnu-emacs@gnu.org; Mon, 07 Jan 2019 20:06:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Jan 2019 01:06:02 +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.154690950117840 (code B ref 33870); Tue, 08 Jan 2019 01:06:02 +0000 Original-Received: (at 33870) by debbugs.gnu.org; 8 Jan 2019 01:05:01 +0000 Original-Received: from localhost ([127.0.0.1]:49095 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ggfpF-0004dc-C2 for submit@debbugs.gnu.org; Mon, 07 Jan 2019 20:05:01 -0500 Original-Received: from mail-wm1-f41.google.com ([209.85.128.41]:37484) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ggfpC-0004d1-Tb for 33870@debbugs.gnu.org; Mon, 07 Jan 2019 20:04:59 -0500 Original-Received: by mail-wm1-f41.google.com with SMTP id g67so2643679wmd.2 for <33870@debbugs.gnu.org>; Mon, 07 Jan 2019 17:04:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=h8KEXhIj6a9ETKU7SapZt1eREbfWhMsXcL+EcZO5m74=; b=SuUQXJ4yXs2ugMSO+RvZR/lT49ksx78mtSzYIyCPAy/UKUr7+nYGCBJZaaOHMQfEhF YZCC2Vt/ov9KAnJux1Z8hocq+zYKREDlCEP0tIBUqOGK5Z+0DJwv7sXDihowgC+SY0fc 9iTQ84deE3yFJ5DO0fKjn30mg7OWbA0A5Vzpo+tOy3cgEiW6TjDwbBRk5E47Bx+HN3+1 Vf+6W+FbL1HYVKDb+EXcAUmwzfsdeqPKEI3bz3BV/XF6ROVlPqAg4BkxOwwwT96Be2Lc 5oxAWIcPLrYdpktrObaZ3iSQattG+BVDjuQJCiLD6qA5ObnbiLLzz4yJlHyzux5Row29 lKOQ== 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:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=h8KEXhIj6a9ETKU7SapZt1eREbfWhMsXcL+EcZO5m74=; b=ORWGT5aLAxyauDC4vvuiu9Tk5RuoO4ijP7e/uimJEM8PAbdJAl9pTxSD/uYyJaOnei GuLvKAs0Xqgrw9ON0v+WRAye8JJSZTBZRv+MjL7PEhPmMjixwlFNzoj8OMzWXdbFuSwZ gMnsQ8LiekmPJlUrIOP1IasL6kbRPOZqOE/vHa/A0F764XMLiK450xDoTEMRgReQ9Obc D5Xm/99rVyaCwE/wQGuemnyNlUWoKH5OfBcyzLBG/Natido2LEnTWuD6aNUzzPYutprL HZ1TP6276qcx0cC8vmzObDlkZqdLvjQKwqiF2HmIJLYuN/J0bo0YKzXE/n16d2in8Mjk CyUQ== X-Gm-Message-State: AJcUukeOEaGCkTo34Z2RsceI7DQAtUYSiUb2VBnE7mGD1K/+RWx+Snf6 340fOYCrOtA7lTMb2pL2LnGE/KFu X-Google-Smtp-Source: ALg8bN4Ek/Nr8N5NqLgh1C6yvESBQg9vaCcTser0L2jpxuqkezYdPqfQ10HMxDyvX1PfBWPM46xj8g== X-Received: by 2002:a1c:b70b:: with SMTP id h11mr83776wmf.72.1546909492409; Mon, 07 Jan 2019 17:04:52 -0800 (PST) Original-Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id c13sm53661925wrb.38.2019.01.07.17.04.51 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 07 Jan 2019 17:04:51 -0800 (PST) In-Reply-To: <874lak9kr0.fsf@mail.linkov.net> (Juri Linkov's message of "Tue, 08 Jan 2019 00:16:19 +0200") 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:154243 Archived-At: Juri Linkov writes: > Of course, it doesn't work if you tried it only with part of my changes. > 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. Anyway, can't you add the tiny window xref-find-definitions and the other UI changes as an addon to *my* patch? > But you asked to break my patch to several pieces and submit them > separately to different bug reports. No wonder that each of them > doesn't do what the whole patch did. >> Expected xref.el to appear in the bottom window which was my original >> intent when I said "other window". > Then the xref buffer is obscured by another buffer visited in the same > window, and if the user wants to visit more hits from the xref buffer, > this is not easy to do. >> In the current master this works OK, in your patch it doesn't. > > My initial patch solved this problem gracefully by creating a new window > 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. >> I've also renamed window.el's window--display-buffer to >> window-display-buffer throughout Emacs (i.e. made it public). > You can't rename old functions lightly. This will break the existing > code. What other code? I renamed the uses in Emacs too: do you mean code outside Emacs? It shouldn't be using that internal function in the first place. But if it is, no reason to punish it: we can just provide a deprecated function alias, which will at most warn its developers of the imprudency. No. I can because they were internal functions that no-one was supposed to have been using in the first place. *That* is precisely why internal functions are useful, so you can decide when and if to make them public. You may argue that by making them public *now* we are going to have a more deprecation problem if we decide to rename them again *in the future*. I would agree with you there. >> After we merge this, we can continue the discussion about the changing >> the xref UI in the other bug you opened, bug#33992 > Better start with bug#33992 because it supports the above test case, > then we could finish this bug#33870. No. There is consensus on fixing the bug (xref.el doesn't respect display-buffer-alist et al) without changing the UI. There is no consensus on changing the UI. Also I think some would not really view this is a bug at all. It would seem Juri that you are trying to shoehorn a behaviour change into a bugfix. Both things have less chances to go into Emacs that way. I'm sure that: * you can implement the UI changes that you want on top of my patch; * you can make them optional; * we can then agree on a good default. Is that not so? Jo=C3=A3o