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: Wed, 26 Dec 2018 14:48:31 +0000 Message-ID: References: <87a7ktqqx7.fsf@mail.linkov.net> <9215183d-0a44-88b5-5b3c-d0da31f749ad@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000002a7b68057deded2d" X-Trace: blaine.gmane.org 1545835632 25412 195.159.176.226 (26 Dec 2018 14:47:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Dec 2018 14:47:12 +0000 (UTC) Cc: 33870@debbugs.gnu.org, Juri Linkov To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Dec 26 15:47:08 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gcASh-0006RJ-Dh for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Dec 2018 15:47:07 +0100 Original-Received: from localhost ([127.0.0.1]:46683 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gcAUn-0003mm-Uf for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Dec 2018 09:49:17 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:45944) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gcAUd-0003mc-62 for bug-gnu-emacs@gnu.org; Wed, 26 Dec 2018 09:49:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gcAUY-0002Gs-LK for bug-gnu-emacs@gnu.org; Wed, 26 Dec 2018 09:49:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38970) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gcAUY-0002Gj-GL for bug-gnu-emacs@gnu.org; Wed, 26 Dec 2018 09:49:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gcAUY-0007Gj-At for bug-gnu-emacs@gnu.org; Wed, 26 Dec 2018 09:49: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: Wed, 26 Dec 2018 14:49: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.154583573127925 (code B ref 33870); Wed, 26 Dec 2018 14:49:02 +0000 Original-Received: (at 33870) by debbugs.gnu.org; 26 Dec 2018 14:48:51 +0000 Original-Received: from localhost ([127.0.0.1]:36633 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gcAUN-0007GK-7p for submit@debbugs.gnu.org; Wed, 26 Dec 2018 09:48:51 -0500 Original-Received: from mail-qt1-f171.google.com ([209.85.160.171]:39823) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gcAUK-0007G7-Rf for 33870@debbugs.gnu.org; Wed, 26 Dec 2018 09:48:49 -0500 Original-Received: by mail-qt1-f171.google.com with SMTP id u47so12842395qtj.6 for <33870@debbugs.gnu.org>; Wed, 26 Dec 2018 06:48:48 -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=xeaub/VXzeTGJvo5mXx9usq5+1eJYxSBZcDvrzrAk9E=; b=h2BKC/lJJJn4sxdE0tQKGs5CzxdbT6wA2x7zNCPcFULM9a+Upcjp5mGG31imQobqIl VgOU4axm3b6nHI4JZOapBcUiBJ1YAjoQur6Tvo5Tnme+4qpyHhxLMSxBFDdGBz59vXan vHwiwhMzEd614V/Foa4Lxcpjkakkfj0PjnnGTVqSk8VIeHbebTg4enpBJdfKWPM1Vfyu aSnLd06gvgzCqt1cwKocvEk0uBqaYvPpmLUgs53LO2+9oX1TyFGLm+PE0UfXy5zQKE2c zTEWweUQRztlhfgQAivVp2DWn7aPzGVJsQt7N0u/tVi2b7/Q8dSpKMCGsNWif8c/kBEJ E02A== 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=xeaub/VXzeTGJvo5mXx9usq5+1eJYxSBZcDvrzrAk9E=; b=tMjXdT6mRTMzrWL6m9ztqa/m0V1mdbO2al3WX1KyiYO60jXwe916CvcZSomdk+wd35 pqw+1wktJcdetuVTYodgBrbdIXno6LBzOlsYA7zlrpg0BGegxfvjnn//QgDlAL7qdufR Fv1uS4hviZ0l2LDc9Dw1gQ6jXh2nGuMU2/B54B9Gfxi8XFdAB174W9+DlBgdoMYIkXfH KNrsi6Au8u8UGNP5Ebdp+tA18BFZ9LI+7excbW9CjcWXX/VkFgDDWwUg55njuAzkgD0N n3HZO6ZDJ6cuF9FukwE6STb5Bhg0DcYQfPvunxVdxqb6blhL955iynlB8vUsLZjV4RKU r7gQ== X-Gm-Message-State: AJcUukdVEdozd3LwzuZuNV+E12oqq4sFPadPsARYx7Zpj8KwxCXkLwZ9 OWbUAKZhqG4xqqhJX7jHomebEP9ftxeggrxyJBk= X-Google-Smtp-Source: ALg8bN4KlQealAHMJaNmRMhNId7zNY4NSAJy4iMUQxxLa+yWrglqo8RhH8MqfRAboR9FOJn0L6iwoSw7So/Q8GCTAGk= X-Received: by 2002:a0c:d4a7:: with SMTP id u36mr18360521qvh.38.1545835723257; Wed, 26 Dec 2018 06:48:43 -0800 (PST) In-Reply-To: <9215183d-0a44-88b5-5b3c-d0da31f749ad@yandex.ru> 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: 208.118.235.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:153866 Archived-At: --0000000000002a7b68057deded2d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Juri and Dmitry Any simplification to the implementation that keeps the "keep original window intent" behavior across xref intermediate buffers is very welcome. Juri, do you understand what that particular sub-feature is about? I wish I had written some tests to go with it but testing window code is tricky. I will still try, that way you needn't worry about understanding it and can program "against the rails". However here's a tangent that might affect the decision. Is there any impediment to making xref.el a core ELPA package? I can see some advantages... The reason I bring this up here is that using very new elisp in a file can reduce the usefulness of that goal, which in this case would be to bring new xref features to users of Emacs 26.1/26.2. Perhaps it is already using post-26 features in which case the ship has sailed. In that case, disregard this tangent. Jo=C3=A3o On Wed, Dec 26, 2018, 02:10 Dmitry Gutov Hi Juri, > > On 25.12.2018 22:42, Juri Linkov wrote: > > X-Debbugs-CC: Dmitry Gutov > > > > There is no more need to replace switch-to-buffer with > > pop-to-buffer-same-window in xref--pop-to-location > > like was asked in https://debbugs.gnu.org/32790#206 > > because now a new option switch-to-buffer-obey-display-actions > > can be customized to t. > > Sorry I never responded, see the message in that other thread. > > > But still there is one xref command, namely `xref-goto-xref' bound to > > RET in the *xref* buffer that always displays the buffer in the > > predefined window, and there is no way to change this behavior. > > > > Is it possible to change it to use either pop-to-buffer-same-window > > or at least switch-to-buffer? > > IIUC you want to change xref--show-pos-in-buf to use > pop-to-buffer-same-window or switch-to-buffer instead of display-buffer. > > Would you like to propose a patch that would still honor the 'action' > argument (or the values of xref--original-window* directly)? > > Also pinging Jo=C3=A3o who wrote that code. > --0000000000002a7b68057deded2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Juri and Dmitry

Any simplification to the implementation= that keeps the
"keep original window inte= nt" behavior across xref
intermediate buff= ers is very welcome.

Jur= i, do you understand what that particular sub-feature
is about? I wish I had written some tests to go with it
bu= t testing window code is tricky. I will still try, that way
you n= eedn't worry about understanding it and can program
&quo= t;against the rails".

However here's a tangent that might affect the decision.
Is there any impediment to making xref.el a core ELPA
<= /div>
package? I can see some advantages... The reason I b= ring
this up here is that using very new elisp = in a file can reduce
the usefulness of that goal, which in t= his case would be
to bring new xref features to users of Emacs 26= .1/26.2.=C2=A0
Perhaps it is already using post-26 features = in which case
the ship has sailed.=C2=A0 In that case, disre= gard this tangent.

Jo=C3=A3o



On Wed, Dec 26, 2018, 02:10 Dmitry Gutov &= lt;dgutov@yandex.ru wrote:
Hi Juri,

On 25.12.2018 22:42, Juri Linkov wrote:
> X-Debbugs-CC: Dmitry Gutov <dgutov@yandex.ru>
>
> There is no more need to replace switch-to-buffer with
> pop-to-buffer-same-window in xref--pop-to-location
> like was asked in https://debbugs.gnu.org/32790#206=
> because now a new option switch-to-buffer-obey-display-actions
> can be customized to t.

Sorry I never responded, see the message in that other thread.

> But still there is one xref command, namely `xref-goto-xref' bound= to
> RET in the *xref* buffer that always displays the buffer in the
> predefined window, and there is no way to change this behavior.
>
> Is it possible to change it to use either pop-to-buffer-same-window > or at least switch-to-buffer?

IIUC you want to change xref--show-pos-in-buf to use
pop-to-buffer-same-window or switch-to-buffer instead of display-buffer.
Would you like to propose a patch that would still honor the 'action= 9;
argument (or the values of xref--original-window* directly)?

Also pinging Jo=C3=A3o who wrote that code.
--0000000000002a7b68057deded2d--