GNU bug report logs - #73446
29.1; Curious behaviour with with-current-buffer and read-string

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 73446 in the body.
You can then email your comments to 73446 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.1; Curious behaviour with with-current-buffer and read-string 
Date: Tue, 24 Sep 2024 09:19:56 +0100

Consider this code snippet:

,----
| (with-current-buffer (get-buffer "*scratch*")
|   (message "START point %S %S" (current-buffer) (point))
|   (goto-char 10)
|   (message "BEFORE point %S %S" (current-buffer) (point))
|   (with-current-buffer (get-buffer "*Messages*") ;; some random buffer
|     (read-string "Test: "))
|   (message "AFTER point %S %S" (current-buffer) (point)))
`----

Assuming that *scratch* has a point at something other than 10 and *is visible in a window*, I get this output in Messages

,----
| START point #<buffer *scratch*> 2952
| BEFORE point #<buffer *scratch*> 10
| AFTER point #<buffer *scratch*> 2952
`----

I was expecting (point) AFTER to be 100, as it was BEFORE.

This only happens when `read-string` is called and when `with-current-buffer` is nested, and only when *scratch* is visible in a window.

I can easily solve this issue with `save-excursion`, but I thought this might be an unintended behaviour worth reporting.

Best regards,
-- Al

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
Cc: 73446 <at> debbugs.gnu.org
Subject: Re: bug#73446: 29.1;
 Curious behaviour with with-current-buffer and read-string
Date: Tue, 24 Sep 2024 15:12:40 +0300

> From: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
> Date: Tue, 24 Sep 2024 09:19:56 +0100
> 
> 
> Consider this code snippet:
> 
> ,----
> | (with-current-buffer (get-buffer "*scratch*")
> |   (message "START point %S %S" (current-buffer) (point))
> |   (goto-char 10)
> |   (message "BEFORE point %S %S" (current-buffer) (point))
> |   (with-current-buffer (get-buffer "*Messages*") ;; some random buffer
> |     (read-string "Test: "))
> |   (message "AFTER point %S %S" (current-buffer) (point)))
> `----
> 
> Assuming that *scratch* has a point at something other than 10 and *is visible in a window*, I get this output in Messages
> 
> ,----
> | START point #<buffer *scratch*> 2952
> | BEFORE point #<buffer *scratch*> 10
> | AFTER point #<buffer *scratch*> 2952
> `----
> 
> I was expecting (point) AFTER to be 100, as it was BEFORE.
> 
> This only happens when `read-string` is called and when `with-current-buffer` is nested, and only when *scratch* is visible in a window.

I can't reproduce this, but see switch-to-buffer-preserve-window-point.

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

From: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 73446 <at> debbugs.gnu.org
Subject: Re: bug#73446: 29.1; Curious behaviour with with-current-buffer and
 read-string
Date: Tue, 24 Sep 2024 14:12:43 +0100

> I can't reproduce this, but see switch-to-buffer-preserve-window-point.

Oh, is it maybe emacsen specific?

I have `switch-to-buffer-preserve-window-point` set to t, but setting it to `nil` gives the same result. Here's how I can reproduce the problem:

1. Open 'emacs -Q'.
2. Paste the following into the scratch buffer

(progn  
  (defun test-bug-73446 nil    
    (let ((buf1 "test1")
          (buf2 "test2"))
      (switch-to-buffer (get-buffer-create buf1))
      (insert (make-string 20 ?H))
      (goto-char 1)
      (switch-to-buffer (get-buffer-create buf2))
    
      (let ((switch-to-buffer-preserve-window-point t)
            start before after)
        (display-buffer buf1 'display-buffer-use-some-window)
        
        (with-current-buffer (get-buffer buf1)
          (setq start (point))
          (goto-char 10)
          (setq before (point))
          (with-current-buffer (get-buffer buf2) ;; some random buffer
            (read-string "Test: "))
          (setq after (point)))
        (list start before after))))
  (message "%S" (test-bug-73446)))

3. Press `C-x c-e` (or call `eval-last-sexp`) 
3. Press return when the prompt "Test: " appears.
4. I see the output (1 10 1), instead of (1 10 10) as I would expect.

Best regards,
-- Al

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
Cc: 73446 <at> debbugs.gnu.org
Subject: Re: bug#73446: 29.1; Curious behaviour with with-current-buffer and
 read-string
Date: Tue, 24 Sep 2024 16:43:22 +0300

> From: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
> Cc: 73446 <at> debbugs.gnu.org
> Date: Tue, 24 Sep 2024 14:12:43 +0100
> 
> 
> 1. Open 'emacs -Q'.
> 2. Paste the following into the scratch buffer
> 
> (progn  
>   (defun test-bug-73446 nil    
>     (let ((buf1 "test1")
>           (buf2 "test2"))
>       (switch-to-buffer (get-buffer-create buf1))
>       (insert (make-string 20 ?H))
>       (goto-char 1)
>       (switch-to-buffer (get-buffer-create buf2))
>     
>       (let ((switch-to-buffer-preserve-window-point t)
>             start before after)
>         (display-buffer buf1 'display-buffer-use-some-window)
>         
>         (with-current-buffer (get-buffer buf1)
>           (setq start (point))
>           (goto-char 10)
>           (setq before (point))
>           (with-current-buffer (get-buffer buf2) ;; some random buffer
>             (read-string "Test: "))
>           (setq after (point)))
>         (list start before after))))
>   (message "%S" (test-bug-73446)))
> 
> 3. Press `C-x c-e` (or call `eval-last-sexp`) 
> 3. Press return when the prompt "Test: " appears.
> 4. I see the output (1 10 1), instead of (1 10 10) as I would expect.

If this is what you do, then it's the expected behavior: test1 is
displayed in another window, and so its window-point overrides what
you do.  See the node "Window Point" in the ELisp manual.

This is not a bug.

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

From: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 73446 <at> debbugs.gnu.org
Subject: Re: bug#73446: 29.1; Curious behaviour with with-current-buffer and
 read-string
Date: Tue, 24 Sep 2024 16:07:42 +0100

On 24/09/2024, Eli Zaretskii wrote:
> If this is what you do, then it's the expected behavior: test1 is
> displayed in another window, and so its window-point overrides what
> you do.  See the node "Window Point" in the ELisp manual.
>
> This is not a bug.

Ah I see. It is interesting that even if the window displaying the
buffer is shown but seemingly not selected (since the focus is on the
minibuffer during `read-string`), the point gets reset to the
window-point when Emacs waits for user input.

I vote to close this issue and apologies for the noise.

Best regards,
-- Al

Message #22 received at 73446-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
Cc: 73446-done <at> debbugs.gnu.org
Subject: Re: bug#73446: 29.1; Curious behaviour with with-current-buffer and
 read-string
Date: Tue, 24 Sep 2024 18:50:19 +0300

> From: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
> Cc: 73446 <at> debbugs.gnu.org
> Date: Tue, 24 Sep 2024 16:07:42 +0100
> 
> 
> On 24/09/2024, Eli Zaretskii wrote:
> > If this is what you do, then it's the expected behavior: test1 is
> > displayed in another window, and so its window-point overrides what
> > you do.  See the node "Window Point" in the ELisp manual.
> >
> > This is not a bug.
> 
> Ah I see. It is interesting that even if the window displaying the
> buffer is shown but seemingly not selected (since the focus is on the
> minibuffer during `read-string`), the point gets reset to the
> window-point when Emacs waits for user input.
> 
> I vote to close this issue and apologies for the noise.

Thanks, I'm closing it.  But there's no need to apologize: Emacs is a
very complex beast, and no one knows all of its subtleties by heart.

Previous Next

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