GNU bug report logs - #28814
26.0.90; When *xref* window is needed, original window-switching intent is lost

Previous Next

Package: emacs;

Reported by: joaotavora <at> gmail.com (João Távora)

Date: Fri, 13 Oct 2017 16:08:02 UTC

Severity: minor

Tags: patch

Found in version 26.0.90

Done: joaotavora <at> gmail.com (João Távora)

Bug is archived. No further changes may be made.

Full log


Message #28 received at 28814 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: João Távora <joaotavora <at> gmail.com>
Cc: 28814 <at> debbugs.gnu.org
Subject: Re: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed,
 original window-switching intent is lost )
Date: Wed, 25 Oct 2017 03:07:56 +0300
On 10/23/17 11:23 AM, João Távora wrote:

> The cause of this problem is that split-window-sensibly refuses to split
> a window whose dimensions are below those of split-height-threshold and
> split-width-threshold. The reason you don't see frames popping up every
> time you do C-x 4 b on a small frame is that this function contains a
> safety net for these cases: if the window to be split is the only one
> available in the frame, it disregards the dimension threshholds and
> splits anyway. The attached window.el patch is a correct way to
> generalize this to account for dedicated windows.

OK, but is it the correct thing to do? The thresholds are there for a 
reason, and having a window that's only a few lines tall (which could 
happen in some example) will hardly be more helpful than showing it in a 
different window, even if the user expected xref to use the "other window".

This stuff is difficult, and personally I don't like either of the 
easily reachable solutions.

> I see and I will try to answer. I proposed two patches previously:
> 
> * a first one to fix the non-determinism of window popping/selecting
> behaviour;
> * a second one to make the *xref* buffer less obstrusive.
> * (now there is the third one that fixes the frame-popping glitch)
> 
> IIUC it is the second one that clashes with "the dissapearing *xref*
> problem" that I have yet to read up on. If we don't come up with a
> solution for that, I would be OK with a solution that leaves it unsolved
> but adds some customization point (hook) for the user to put this
> behaviour in.

Indeed, but there's also a matter of consistency, and of making the 
overall design work in a predictable fashion. More in the follow-up email.




This bug report was last modified 7 years and 260 days ago.

Previous Next


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