GNU bug report logs - #67993
Selecting buffer automatically

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 67993 <at> debbugs.gnu.org
Subject: Re: bug#67993: Selecting buffer automatically
Date: Mon, 8 Jan 2024 09:55:58 +0100

>> In 'display-buffer' first save the selected window as
>> old-selected-window, display the buffer and in your code select
>> old-selected-window instead of (old-selected-window).
>
> Unfortunately, this is not so easy to do.  'old-selected-window'
> should be reinitialized before the next command is executed.

Why?  As I imagine it, it would be let-bound in 'display-buffer'.

> So by definition 'old-selected-window' should contain
> the window that was selected before the current command
> was executed.  I have no idea how to do this without hooks.

Hmmm... I have problems to see what the "current command" is.  One and
the same command may contain multiple invocations of 'display-buffer'.
I thought you wanted a 'select-window' entry to be handled separately by
each of them.  Otherwise, IIUC the entry provided by the last invocation
would prevail any entries provided by previous invocations.  How would
you explain that to a user?

If you want 'old-selected-window' to denote "some" state before the
"current command", the function 'old-selected-window' might be a better
choice than a variable you bind in 'display-buffer' (but note that
redisplay may occur in the middle of executing a command).

But if you want to interpret "current command" more strictly, you need a
separate variable, say 'pre-command-selected-window' that you always set
in 'pre-command-hook' and consult (and maybe reset) in
'post-command-hook'.

> 'pop-to-buffer' can't be changed because (select-window . t)
> should be handled only at the end of the current command.

Are your sure that you do not somewhat arbitrarily restrict the scope of
this feature?  What if (select-window . t) were to be handled in a call
from within a timer?  Would you ignore it?

> So this also need to run 'select-frame' in post-command-hook.

'select-frame-set-input-focus' maybe.  Or, what's worse, undo the
consequences of a preceding 'select-frame-set-input-focus' call
triggered by 'pop-to-buffer'.  That's why any such 'select-window' call
(or its avoidance) you propose would be better handled within
'display-buffer' and not later in a 'post-command-hook'.

martin

Previous Next

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