GNU bug report logs - #33870
27.0.50; xref-goto-xref not configurable

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: João Távora <joaotavora <at> gmail.com>
Cc: 33870 <at> debbugs.gnu.org, dgutov <at> yandex.ru, juri <at> linkov.net
Subject: bug#33870: 27.0.50; xref-goto-xref not configurable
Date: Tue, 05 Feb 2019 20:12:05 +0200

> From: João Távora <joaotavora <at> gmail.com>
> Cc: juri <at> linkov.net,  dgutov <at> yandex.ru,  33870 <at> debbugs.gnu.org
> Date: Sun, 03 Feb 2019 20:22:17 +0000
> 
> Let me try one last time.  2 days ago, you decided to chime in very
> tersely: "No, I don't think so"
> 
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33870#380
> 
> , presumably saying that the default behaviour in Emacs 26.1 doesn't
> make sense for a specific edge case that I had been testing.  Because
> you may have been misunderstanding I replied with a detailed explanation
> of the reasoning for that particular behaviour in:
> 
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33870#383
> 
> , which you didn't reply to, but Dmitry accepted as sufficient
> validation for the current behaviour.  Meanwhile, Juri used this
> opportunity to insist that the current behaviour is sub-optimal.

The current behavior is somewhat sub-optimal, but so is IMO the
alternative that Juri suggests: the "tiny window below the original
one", as I understand it, will make M-. and fiends behave differently
from any other command which needs to use "the other window", like
"M-x compile", "M-x grep", etc.  So I think I like the current
behavior better.  The part of the current behavior where RET after
"C-x 4 ." makes a new window I don't like too much, I think it would
be better to reuse the window where *xref* is shown.  But I wouldn't
insist on such a change, mainly because I think "C-x 4 ." makes little
sense anyway, as we have "M-," to easily return to the buffer we were
in originally.

So on balance I think we don't need to change the current UI.

> Somewhere along the line we started miscommunicating that someone was
> asking the other for input, but for me this is very simple: let's
> install Juri's latest patch, which allows for configuring different
> behaviors and _then_ discuss which one, if any, of the set of new
> possibilities could become the new default.

If that patch doesn't change the default behavior, I have nothing
against installing it on master.

Thanks.

P.S. Sorry for a delay in responding, I had several urgent tasks that
ate up all my free time.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.