From: joaotavora@gmail.com (João Távora)
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: 28814@debbugs.gnu.org
Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost )
Date: Mon, 23 Oct 2017 09:23:05 +0100 [thread overview]
Message-ID: <87lgk22ryu.fsf@gmail.com> (raw)
In-Reply-To: <a1c778d1-d0a2-1b09-8732-c98597412bda@yandex.ru> (Dmitry Gutov's message of "Mon, 23 Oct 2017 05:06:37 +0300")
[-- Attachment #1: Type: text/plain, Size: 3931 bytes --]
Dmitry Gutov <dgutov@yandex.ru> writes:
> You are working on something that I agree is a real problem, but doing
> this would effectively revert commit
> 5698947ff9335cf150c73cca257a5e7e5951b045, which was based on a
> previous discussion (see the link in the commit message), and in
> particular, would bring back "disappearing *xref* buffer problem", as
> Eli put it.
> [...]
>
> I have a rough idea on how to fix the situation, but nothing even
> close to an implementation.
>
Thanks for the pointer. After I read that discussion I will probably ask
you about that.
>> emacs -Q
>> C-x 3 [split-window-right]
>> C-x 2 [split-window-below]
>> M-. xref-backend-definitions RET [xref-find-definitions]
>> C-n [next-line]
>> RET [xref-goto-xref]
>>
>> Expected the definition to be found in the original window where I
>> pressed M-. but instead it was found in another. Another case:
>>
>> emacs -Q
>> C-x 4 . xref-backend-definitions RET [xref-find-definitions-other-window]
>> C-n
>> RET
>>
>> Expected the definition to be found in some other window, different from
>> the one I pressed M-. on. Instead went to the same one.
>
> With your patches applied, this example pops a new frame for me if I
> press 'n' instead of 'C-n'. This is not hugely important in the light
> of the larger problems above, but demonstrated difficulties with
> window management when we try to pretend that the xref buffer "was
> never there".
You are absolutely right (and you don't have to tell me how hairy
window-management code is). This particular problem, which I had also
noticed, slipped through. I have a fix attached as a patch.
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.
If this is not accepted this local fix in xref.el will also work fine.
@@ -504,7 +504,8 @@ xref--show-location
(t
(save-selected-window
(xref--with-dedicated-window
- (xref--show-pos-in-buf marker buf))))))
+ (let ((split-height-threshold 0))
+ (xref--show-pos-in-buf marker buf)))))))
(user-error (message (error-message-string err)))))
(defun xref-show-location-at-point ()
>> Also, in both
>> situations, expected the window configuration to be the same as if I had
>> searched for, say xref-backend-functions.
>>
>> This is fixed by the patches that I reattach after minor tweaks. The
>> general idea is to have the *xref*, whose sudden appearance is hard to
>> predict, obtrude as little as possible on the user's window
>> configuration.p
>
> If we don't bring back the "disappearing *xref* buffer problem",
> *xref* has to stay obtrusive. Do you think the rest of your patch will
> make sense with that change?
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.
João
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0003-Allow-split-window-sensibly-to-split-threshold-in-fu.patch --]
[-- Type: text/x-diff, Size: 3151 bytes --]
From 47480926f328db5d840ba518125e0866d29f8665 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= <joaotavora@gmail.com>
Date: Mon, 23 Oct 2017 09:05:32 +0100
Subject: [PATCH 3/3] Allow split-window-sensibly to split threshold in further
edge case
As a fallback, and to avoid creating a frame, split-window-sensibly
would previously disregard split-height-threshold if the window to be
split is the frame's root window.
This change slightly expands on that: it disregards the threshold if
the window to be split is the frame's only usable window (it is either
the only one, as before, or all the other windows are dedicated to
some buffer and thus cannot be touched).
* lisp/window.el (split-height-threshold): Adjust doc to match
split-window-sensibly.
(split-window-sensibly): Also disregard threshold if all other
windows are dedicated.
---
lisp/window.el | 33 ++++++++++++++++++++++-----------
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/lisp/window.el b/lisp/window.el
index 5ba9a305f9..21271944c0 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -6449,8 +6449,9 @@ split-height-threshold
vertically only if it has at least this many lines. If this is
nil, `split-window-sensibly' is not allowed to split a window
vertically. If, however, a window is the only window on its
-frame, `split-window-sensibly' may split it vertically
-disregarding the value of this variable."
+frame, or all the other ones are dedicated,
+`split-window-sensibly' may split it vertically disregarding the
+value of this variable."
:type '(choice (const nil) (integer :tag "lines"))
:version "23.1"
:group 'windows)
@@ -6557,15 +6558,25 @@ split-window-sensibly
;; Split window horizontally.
(with-selected-window window
(split-window-right)))
- (and (eq window (frame-root-window (window-frame window)))
- (not (window-minibuffer-p window))
- ;; If WINDOW is the only window on its frame and is not the
- ;; minibuffer window, try to split it vertically disregarding
- ;; the value of `split-height-threshold'.
- (let ((split-height-threshold 0))
- (when (window-splittable-p window)
- (with-selected-window window
- (split-window-below))))))))
+ (and
+ (let ((frame (window-frame window)))
+ (or
+ (eq window (frame-root-window frame))
+ (let ((windows (delete window (window-list frame)))
+ w)
+ (while (and (setq w (pop windows))
+ (window-dedicated-p w)))
+ (not windows))))
+ (not (window-minibuffer-p window))
+ ;; If WINDOW is the only usable window on its frame (it is
+ ;; the only one or,not being the only one, all the other ones
+ ;; are dedicated) and is not the minibuffer window, try to
+ ;; split it vertically disregarding the value of
+ ;; `split-height-threshold'.
+ (let ((split-height-threshold 0))
+ (when (window-splittable-p window)
+ (with-selected-window window
+ (split-window-below))))))))
(defun window--try-to-split-window (window &optional alist)
"Try to split WINDOW.
--
2.14.2
next prev parent reply other threads:[~2017-10-23 8:23 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-13 16:07 bug#28814: 26.0.90; When *xref* window is needed, original window-switching intent is lost João Távora
[not found] ` <handler.28814.B.150791088020837.ack@debbugs.gnu.org>
2017-10-16 17:58 ` bug#28814: Acknowledgement (26.0.90; When *xref* window is needed, original window-switching intent is lost ) João Távora
2017-10-20 9:13 ` bug#28814: [BUMP, PATCH] " João Távora
2017-10-20 10:39 ` Dmitry Gutov
2017-10-23 2:06 ` Dmitry Gutov
2017-10-23 8:23 ` João Távora [this message]
2017-10-23 20:03 ` João Távora
2017-10-25 0:24 ` Dmitry Gutov
2017-10-25 7:43 ` João Távora
2017-10-25 10:24 ` Dmitry Gutov
2017-10-25 13:29 ` João Távora
2017-10-25 14:49 ` Dmitry Gutov
2017-10-25 15:35 ` João Távora
2017-10-25 15:46 ` Dmitry Gutov
2017-10-25 15:11 ` Eli Zaretskii
2017-10-25 15:27 ` João Távora
2017-10-25 15:39 ` Eli Zaretskii
2017-10-25 20:56 ` João Távora
2017-10-26 7:56 ` martin rudalics
2017-10-26 16:42 ` Eli Zaretskii
2017-10-26 22:40 ` Dmitry Gutov
2017-10-27 0:05 ` João Távora
2017-11-02 17:06 ` Dmitry Gutov
2017-10-26 23:59 ` João Távora
2017-10-28 9:41 ` Eli Zaretskii
2017-10-28 19:19 ` João Távora
2017-11-02 17:03 ` João Távora
2017-11-02 17:07 ` Eli Zaretskii
2017-11-02 19:07 ` João Távora
2017-11-02 19:32 ` Eli Zaretskii
2017-11-03 13:47 ` Eli Zaretskii
2017-11-03 16:18 ` João Távora
2017-11-03 19:06 ` Eli Zaretskii
2017-10-26 12:39 ` Dmitry Gutov
2017-10-25 7:46 ` martin rudalics
2017-10-25 13:19 ` João Távora
2017-10-26 7:56 ` martin rudalics
2017-10-25 0:07 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lgk22ryu.fsf@gmail.com \
--to=joaotavora@gmail.com \
--cc=28814@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.