GNU bug report logs - #32790
27.0.50; point jumps unexpectedly after delete-window

Previous Next

Package: emacs;

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


View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 32790 <at> debbugs.gnu.org
Subject: bug#32790: 27.0.50; point jumps unexpectedly after delete-window
Date: Wed, 14 Nov 2018 01:20:53 +0200
>>> (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.

Then easier just to rename it to windmove-pop-in-direction
because most commands use pop-to-buffer, so this should be
the default.

> So with a prefix argumet I would select the window in that direction
> and without it I'd leave the old window selected.

If you prefer the inverse, then a new option could be added with a name
windmove-display-pop-up.  And ‘C-u C-u’ will invert its value like for
‘diff-jump-to-old-file’.

>> 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.

Expect more fun with wrapping head around frame-based windmove-wrap-around :)

But currently I'm more concerned about inability to use switch-to-buffer,
i.e. trying to display a buffer in another window with ‘S-M-down C-x b RET’
doesn't work.  I tried to temporarily set dedicated-p to an old window,
but switch-to-buffer removes its dedicatedness.




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.