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

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 32790 <at> debbugs.gnu.org
Subject: Re: bug#32790: 27.0.50; point jumps unexpectedly after delete-window
Date: Wed, 24 Oct 2018 11:45:49 +0200

>> It would indeed be nice to fix that there in some way.
>
> There are not too many options that can be supported to make
> Emacs window management more manageable.  I see at least these:
>
> 1. If the user knows beforehand in which window to display some
>     particular buffer, then it's possible to customize display-buffer-alist.
>     For example, instead of displaying *Backtrace* in a random window
>     to make its placement more predictable:
>
>     (custom-set-variables
>      '(display-buffer-alist
>        '(("\\`\\*Backtrace.*" display-buffer-below-selected))))

That's the status quo, I suppose.

> 2. based on display-buffer-alist, implement some more declarative
>     definitions of window layouts, i.e. allow the user to describe
>     the used windows in which buffers should be displayed in them.

I'd need to see a proposal how that can be done.  In a way it's
orthogonal to how 'window-state-put' tries to reconstruct a window
configuration and it's no entirely trivial to do that.

> 3. in some cases there is an one-off need to point out explicitly
>     where to display the result of the next display-buffer command.
>     If this will require only short code addition then better to have
>     this feature in window.el.

I think that 'display-buffer-directionally' is supposed do that.  But
this should rather go to windmove.el because directional key bindings
are already in use there.

>> Good idea.  But IIUC we can't use 'hyper' in Emacs because it is not
>> supposed to be generally present and must be bound to a key first.  So
>> we'd need some other mechanism.
>
> This is the same mechanism as already used by windmove-default-keybindings.

'windmove-default-keybindings' binds only the 'shift' modifier which
is "standard" so to say.  Binding the 'hyper' modifier is not standard
to my knowledge.  We could bind any combination of 'shift', 'control'
and 'meta' though.

But I think that putting a function on
'window-configuration-change-hook' can be dangerous when a window
showing the buffer in question already exists and gets reused.  In
such case 'window-configuration-change-hook' is not run and the
changed value of 'display-buffer-overriding-action' will persist.  So
we probably need a 'display-buffer-functions' hook to remove it
reliably.  Basically, however, I think that using an overriding action
is justified here.

martin

Previous Next

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