GNU bug report logs -
#32790
27.0.50; point jumps unexpectedly after delete-window
Previous Next
Reported by: Juri Linkov <juri <at> linkov.net>
Date: Thu, 20 Sep 2018 23:57:01 UTC
Severity: minor
Found in version 27.0.50
Done: Juri Linkov <juri <at> linkov.net>
Bug is archived. No further changes may be made.
Full log
Message #230 received at 32790 <at> debbugs.gnu.org (full text, mbox):
>> With 'help-window-select' non-nil they should always select the help
>> window.
>
> This means that every package should provide own customization
> for the select/no-select choice for its windows, instead of
> a general solution like inhibit-window-select that I tried to do.
With help windows it was easy to do that because they never get
selected by default.
>> (1) The select/no-select choice always bound to one and the same
>> prefix key _regardless_ of the default behavior of the function (for
>> the buffer at hand), and
>
> This is implemented in a new version:
>
> (defun windmove-display-in-direction (dir &optional arg)
> "Display the next buffer in the window at direction DIR.
> Create a new window if there is no window in that direction.
> Without a prefix arg, select the window with a displayed buffer.
> If prefix ARG is `C-u', reselect a previously selected window."
I'd invert these: The "-display-" infix implies that the buffer is
displayed and not popped to. So with a prefix argumet I would select
the window in that direction and without it I'd leave the old window
selected.
>> Then (2) could be generalized via a global option to use/make a new
>> (child) frame in the indicated direction or whatever people want.
>
> But does windmove support frames in the first place?
No.
> Can you use e.g. S-left to select a frame on the left?
> Does window-in-direction currently return frames?
No, and it's a bit tricky to do that. A window that is not on the
right of a frame has always exactly one window directly at its right
regardless of the position of its buffer's (window-)point. The same
doesn't hold for a window that has a frame on the right. If there are
two or more overlapping frames, we'd probably choose a visible one
with the highest z-order value. If there is no frame directly on the
right of point, we'd have to choose the one geometrically nearest to
that position.
martin
This bug report was last modified 5 years and 235 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.