[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#32790: 27.0.50; point jumps unexpectedly after delete-window
From: |
Juri Linkov |
Subject: |
bug#32790: 27.0.50; point jumps unexpectedly after delete-window |
Date: |
Wed, 14 Nov 2018 01:20:53 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) |
>>> (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.
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, (continued)
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/08
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/11/09
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/10
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/11/11
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/12
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/11/13
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window,
Juri Linkov <=
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/11/14
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/14
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/11/15
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/15
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/11/16
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/17
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/11/18
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/18
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, martin rudalics, 2018/11/19
- bug#32790: 27.0.50; point jumps unexpectedly after delete-window, Juri Linkov, 2018/11/19