From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!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: Fri, 1 Feb 2019 08:19:40 +0000 Message-ID: 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> <87bm4qel4t.fsf@mail.linkov.net> <67c9abb5-f546-361f-04ca-da96ceaca4e2@yandex.ru> <87bm4le0tm.fsf@mail.linkov.net> <87imys6x5s.fsf@mail.linkov.net> <87d0osjtna.fsf@mail.linkov.net> <8ffaaddb-1d19-b9e9-83f1-83da89445eb8@yandex.ru> <87munmosx4.fsf@mail.linkov.net> <77b96dc5-a994-de78-64bb-40ba7625d40f@yandex.ru> <838sz0yni3.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a71fdf0580d0ced8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="217034"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 33870@debbugs.gnu.org, Dmitry Gutov , Juri Linkov To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 01 09:20:21 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gpU3e-000uJQ-Ju for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 Feb 2019 09:20:18 +0100 Original-Received: from localhost ([127.0.0.1]:40664 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gpU3d-00060A-AO for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 Feb 2019 03:20:17 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40636) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gpU3R-0005zp-7P for bug-gnu-emacs@gnu.org; Fri, 01 Feb 2019 03:20:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gpU3P-0006Tk-0p for bug-gnu-emacs@gnu.org; Fri, 01 Feb 2019 03:20:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54384) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gpU3O-0006Tb-UO for bug-gnu-emacs@gnu.org; Fri, 01 Feb 2019 03:20:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gpU3O-00028b-Je for bug-gnu-emacs@gnu.org; Fri, 01 Feb 2019 03:20: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: Fri, 01 Feb 2019 08:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33870 X-GNU-PR-Package: emacs Original-Received: via spool by 33870-submit@debbugs.gnu.org id=B33870.15490091998204 (code B ref 33870); Fri, 01 Feb 2019 08:20:02 +0000 Original-Received: (at 33870) by debbugs.gnu.org; 1 Feb 2019 08:19:59 +0000 Original-Received: from localhost ([127.0.0.1]:53665 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gpU3L-00028G-1t for submit@debbugs.gnu.org; Fri, 01 Feb 2019 03:19:59 -0500 Original-Received: from mail-qt1-f181.google.com ([209.85.160.181]:40387) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gpU3J-00027z-TA for 33870@debbugs.gnu.org; Fri, 01 Feb 2019 03:19:58 -0500 Original-Received: by mail-qt1-f181.google.com with SMTP id k12so6498135qtf.7 for <33870@debbugs.gnu.org>; Fri, 01 Feb 2019 00:19:57 -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=/CETa6lcu39S1fSPOVnqxVciRE1bQbfCCeGxuGLRKb4=; b=jlhIWm+bBE6RP5akZuGPA3FwS0CNHLEhwIj+NOc629yzOiRvG/XklHcB0cyK4l2EGF v7HthVK71CyzB7AN3MHDVJQgfYuWeRXoit3gO1Lcthv2h6KbgTtaNroD7OYnKvNtAV5X UZR2Cfz+QD0qaJFG+1uDV2q9ntY5xpHQr8XFQYkkrZSofewSctmjiGJuEbrQO/98fMyj YiBgR34x5xhd/yClCcsG1zKieEn1KCAVmCNdEV3li+J3Z9G2MaN/ic/pqknnztqpGvo8 VFPFLZ+IqSfFtdBzCT2fOLkTfKHBB3Zsu/oiqxoYyRf0TbDC1iWjIBrk4B8ehXdQtAsD AH9g== 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=/CETa6lcu39S1fSPOVnqxVciRE1bQbfCCeGxuGLRKb4=; b=fTBQXRy4Bw67P3Ytmk0GOQ3lhb+YNrRV9Itb0LslYMiJprV9fv9K96gUGIED9ngvnQ 58Te28ASyoCAr6KR8Oks3cbKtCfRwD09LaPOV45qSOhPsqSwugTasX8RmKQstM1GWDv6 yQ7u3xcg7fjYP/KMW39CLv638Aq4gFRBEkvlBxd+GxdAxpyVbQQISgLAVQ9XJW+pkRkl Ebd4zbL95rp2pRYNh2tUq2jh5Xumkr/2WrnFcg9C4haLc4vv8d+mmJbLxuVGLFgC6W6g 4p0ysDJd755ImJejnpgnEckeJdnhCht2DBqhgPWFUPuqJgkKLKLNsuk8WlJDqH0qbJfC y3yQ== X-Gm-Message-State: AJcUukemaUKo1UyqzDSlK3U268WJhtMZKFXOR6OCcBpj7cgh68oWsuzq k4BhGafCQpF1bUh9veDHOWQJsEsK7z/4t+D95GI= X-Google-Smtp-Source: ALg8bN4nJV/zBtDv4vyDjgx3qxSEplFrIhVilN+4+fQpbh9CvW0B7Ciw9E2qtlhTVNQ3uYUoeo5FcS7s9LzwdO0Rw+Y= X-Received: by 2002:a0c:b919:: with SMTP id u25mr35992676qvf.104.1549009192163; Fri, 01 Feb 2019 00:19:52 -0800 (PST) In-Reply-To: <838sz0yni3.fsf@gnu.org> 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:154956 Archived-At: --000000000000a71fdf0580d0ced8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 1, 2019, 07:30 Eli Zaretskii wrote: > > From: Dmitry Gutov > > Date: Fri, 1 Feb 2019 04:39:09 +0300 > > Cc: 33870@debbugs.gnu.org > > > > On 01.02.2019 03:17, Jo=C3=A3o T=C3=A1vora wrote: > > > emacs -Q > > > C-x 2 > > > C-x o > > > C-x 4 . xref-backend-definitions RET > > > n > > > > > > <...> in > > > your version, it works quite correctly. > > > > When I try this with the new patch, it results in a third window being > > created (the original window is being split, and the definition is show= n > > there). > > Is this the behavior we want? > No, I don't think so. > It might not be the behavior you want, but it was the behavior I designed it to have. You start with two windows, A and B. You ask to find definitions in another window from A, because you want to preserve its contents. The symbol you searched for happened to have multiple definitions so you decide to browse them from *xref* using bare 'n' and 'p' before settling on the definition you want. Those "prospects" can't be shown in A because that would break the original "other-window" contract/intention, and they can't be shown in B because that's where you're browsing from. They need a new window C which is not available. When the frame is relatively small (as it is with emacs -Q), C is created by splitting horizontally, which is kind of akward, but the decision where to create C changes with larger frames. For some reason, 26.1 sometimes decides to make another frame for C, but only if you start from B, i.e you add onde 'C-x o' to the beginning of the recipe, after splitting. This is a bug in the current xref.el or, more likely, in window.el's window-splitting heuristics. The bug goes away when you have larger frames, which explains why I didn't catch it earlier. Fortunately, the whole point of this bug report opened by Juri is to make this configurable. Later, we can decide on a better default, something Juri is also very much in favor of. If you add your voice to his and decide to change the default, and then give me a way to recover 26.1's behavior (minus the bug), I won't object (much). --000000000000a71fdf0580d0ced8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Feb 1, 2019, 07:30 Eli Zaretskii <eliz@gnu.org> wrote:
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 1 Feb 2019 04:39:09 +0300
> Cc: 33870@debbugs.gnu.org
>
> On 01.02.2019 03:17, Jo=C3=A3o T=C3=A1vora wrote:
> > emacs -Q
> > C-x 2
> > C-x o
> > C-x 4 . xref-backend-definitions RET
> > n
> >
> > <...> in
> > your version, it works quite correctly.
>
> When I try this with the new patch, it results in a third window being=
> created (the original window is being split, and the definition is sho= wn
> there).
> Is this the behavior we want?
No, I don't think so.
It might not be the behavior you want, but it was = the behavior I designed it to have.=C2=A0

=
You start with two windows, A and B. You ask to find defi= nitions in another window from A, because you want to preserve its contents= . The symbol you searched for happened to have multiple definitions so you = decide to browse them from *xref* using bare 'n' and 'p' be= fore settling on the definition you want. Those "prospects" can&#= 39;t be shown in A because that would break the original "other-window= " contract/intention, and they can't be shown in B because that= 9;s where you're browsing from. They need a new window C which is not a= vailable. When the frame is relatively small (as it is with emacs -Q), C is= created by splitting horizontally, which is kind of akward, but the decisi= on where to create C changes with larger frames.=C2=A0

For some reason, 26.1 sometimes decides to m= ake another frame for C, but only if you start from B, i.e you add onde = 9;C-x o' to the beginning of the recipe, after splitting. This is a bug= in the current xref.el or, more likely, in window.el's window-splittin= g heuristics. The bug goes away when you have larger frames, which explains= why I didn't catch it earlier.

Fortunately, the whole p= oint of this bug report opened by Juri is to make this configurable. Later,= we can decide on a better default, something Juri is also very much in fav= or of. If you add your voice to his and decide to change the default, and t= hen give me a way to recover 26.1's behavior (minus the bug), I won'= ;t object (much).

--000000000000a71fdf0580d0ced8--