display-buffer vs. current-buffer vs. post-command-hook

display-buffer vs. current-buffer vs. post-command-hook

[Ami Fischman]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

current-buffer returns a stale value immediately after display-buffer
returns.

The following snippet (saved in x.el), when loaded in 25.1.1 using
[google-emacs -Q -l x.el], generates the message:
*scratch* *scratch* *Help*
demonstrating that (current-buffer) has a stale value after describe-key
returns (I expect post to match the [run-at-time 0] value, not the pre
value).

(progn
  (setq display-buffer-alist '(("." (lambda (buffer alist)
(switch-to-buffer buffer)))))
  (setq pre (current-buffer))
  (describe-key (kbd "SPC"))
  (setq post (current-buffer))
  (run-at-time 0 nil (lambda () (message "%s %s %s" pre post
(current-buffer)))))

This is an extremely reduced test case that reproduces the problem that is
causing https://github.com/mina86/auto-dim-other-buffers.el/issues/10
 (AFAICT).

Cheers,
-a

[-- Attachment #2: Type: text/html, Size: 1153 bytes --]

Re: display-buffer vs. current-buffer vs. post-command-hook

[Stefan Monnier]

> The following snippet (saved in x.el), when loaded in 25.1.1 using
> [google-emacs -Q -l x.el], generates the message:
> *scratch* *scratch* *Help*
> demonstrating that (current-buffer) has a stale value after describe-key
> returns (I expect post to match the [run-at-time 0] value, not the pre
> value).

You're confusing current-buffer and selected-window, I think.


        Stefan

Re: display-buffer vs. current-buffer vs. post-command-hook

[martin rudalics]

 > The following snippet (saved in x.el), when loaded in 25.1.1 using
 > [google-emacs -Q -l x.el], generates the message:
 > *scratch* *scratch* *Help*
 > demonstrating that (current-buffer) has a stale value after describe-key
 > returns (I expect post to match the [run-at-time 0] value, not the pre
 > value).
 >
 > (progn
 >    (setq display-buffer-alist '(("." (lambda (buffer alist)
 > (switch-to-buffer buffer)))))

The preferred way to use the selected window for displaying a buffer is
the action function ‘display-buffer-same-window’.

 >    (setq pre (current-buffer))
 >    (describe-key (kbd "SPC"))
 >    (setq post (current-buffer))
 >    (run-at-time 0 nil (lambda () (message "%s %s %s" pre post
 > (current-buffer)))))

‘describe-key’ is based on ‘with-temp-buffer-window’ which tries very
hard to restore the current buffer after doing its work.  So what you
see here is not a stale value but one that has been correctly preserved.

Please tell us what you want to accomplish.  Then we might be able to
tell you how to do that.

martin

Re: display-buffer vs. current-buffer vs. post-command-hook

[Ami Fischman]

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

>
> ‘describe-key’ is based on ‘with-temp-buffer-window’ which tries very
> hard to restore the current buffer after doing its work.  So what you
> see here is not a stale value but one that has been correctly preserved.
>

I'm sorry but I don't understand your statement.  Should there not be an
expectation that (current-buffer)'s return value does not change between
the second and third call in my original snippet?
Put another way, under what circumstances should one expect
current-buffer's return value to be stable in user-written elisp?
Put a third way, what about describe-keys documentation should lead an
elisp author to understand that current-buffer will not reflect its effect
until after a [run-at-time 0]?
(sorry for the barrage of questions; I feel there's a fundamental something
I'm missing in play here and trying to see if you know what it is :))

Please tell us what you want to accomplish.  Then we might be able to
> tell you how to do that.


My original goal was to resolve a bug in the interaction between two add-on
libraries (see the link in my original email).  That bug has been fixed by
replacing the uses of current-buffer with window-buffer so my original goal
is now moot.  Now my goal is to understand the intended semantics of
interaction between current-buffer and describe-key (and its impl).

Cheers,
-a

[-- Attachment #2: Type: text/html, Size: 1868 bytes --]

Re: display-buffer vs. current-buffer vs. post-command-hook

[Ami Fischman]

[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]

Ah, just saw Stefan's reply on the mailing list archive (I'm not subscribed
to emacs-devel anymore).  Yes, I think you're right that I was confusing
current-buffer and selected-window.
I'm still a bit curious about the expected semantics of current-buffer, in
particular which built-in commands should I expect to cause c-b to change
asynchronously, in case that's easy to explain.

Cheers,
-a


On Tue, Oct 4, 2016 at 8:45 AM Ami Fischman <ami@fischman.org> wrote:

> ‘describe-key’ is based on ‘with-temp-buffer-window’ which tries very
> hard to restore the current buffer after doing its work.  So what you
> see here is not a stale value but one that has been correctly preserved.
>
>
> I'm sorry but I don't understand your statement.  Should there not be an
> expectation that (current-buffer)'s return value does not change between
> the second and third call in my original snippet?
> Put another way, under what circumstances should one expect
> current-buffer's return value to be stable in user-written elisp?
> Put a third way, what about describe-keys documentation should lead an
> elisp author to understand that current-buffer will not reflect its effect
> until after a [run-at-time 0]?
> (sorry for the barrage of questions; I feel there's a fundamental
> something I'm missing in play here and trying to see if you know what it is
> :))
>
> Please tell us what you want to accomplish.  Then we might be able to
> tell you how to do that.
>
>
> My original goal was to resolve a bug in the interaction between two
> add-on libraries (see the link in my original email).  That bug has been
> fixed by replacing the uses of current-buffer with window-buffer so my
> original goal is now moot.  Now my goal is to understand the intended
> semantics of interaction between current-buffer and describe-key (and its
> impl).
>
> Cheers,
> -a
>

[-- Attachment #2: Type: text/html, Size: 3212 bytes --]

Re: display-buffer vs. current-buffer vs. post-command-hook

[martin rudalics]

 > I'm sorry but I don't understand your statement.  Should there not be an
 > expectation that (current-buffer)'s return value does not change between
 > the second and third call in my original snippet?

No.  The primary concern is that the current buffer must not be changed
by `describe-key' or any other function that uses a temporary buffer to
display its results.

 > Put another way, under what circumstances should one expect
 > current-buffer's return value to be stable in user-written elisp?

The current buffer should never be changed by any function, unless it is
a purpose of that function to change the current buffer.

 > Put a third way, what about describe-keys documentation should lead an
 > elisp author to understand that current-buffer will not reflect its effect
 > until after a [run-at-time 0]?
 > (sorry for the barrage of questions; I feel there's a fundamental something
 > I'm missing in play here and trying to see if you know what it is :))

I suppose you missed the following aspect described in section 26.2 of
the Elisp manual entitled "The Current Buffer":

   When an editing command returns to the editor command loop, Emacs
   automatically calls `set-buffer' on the buffer shown in the selected
   window.

[run-at-time 0] clearly runs after that.

martin

Re: display-buffer vs. current-buffer vs. post-command-hook

[Ami Fischman]

[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]

Thanks Martin!  That's exactly the thing I was missing.
https://www.gnu.org/software/emacs/manual/html_node/elisp/Current-Buffer.html#Current-Buffer


On Tue, Oct 4, 2016 at 9:07 AM martin rudalics <rudalics@gmx.at> wrote:

>  > I'm sorry but I don't understand your statement.  Should there not be an
>  > expectation that (current-buffer)'s return value does not change between
>  > the second and third call in my original snippet?
>
> No.  The primary concern is that the current buffer must not be changed
> by `describe-key' or any other function that uses a temporary buffer to
> display its results.
>
>  > Put another way, under what circumstances should one expect
>  > current-buffer's return value to be stable in user-written elisp?
>
> The current buffer should never be changed by any function, unless it is
> a purpose of that function to change the current buffer.
>
>  > Put a third way, what about describe-keys documentation should lead an
>  > elisp author to understand that current-buffer will not reflect its
> effect
>  > until after a [run-at-time 0]?
>  > (sorry for the barrage of questions; I feel there's a fundamental
> something
>  > I'm missing in play here and trying to see if you know what it is :))
>
> I suppose you missed the following aspect described in section 26.2 of
> the Elisp manual entitled "The Current Buffer":
>
>    When an editing command returns to the editor command loop, Emacs
>    automatically calls `set-buffer' on the buffer shown in the selected
>    window.
>
> [run-at-time 0] clearly runs after that.
>
> martin
>

[-- Attachment #2: Type: text/html, Size: 2667 bytes --]