bug#16728: 24.3.50; bug? (with-temp-buffer (insert "foo")) deactivates mark in current buffer

bug#16728: 24.3.50; bug? (with-temp-buffer (insert "foo")) deactivates mark in current buffer

[Oleh]

I'm not sure if it's a bug, that's why I'm asking.
To reproduce, in *scratch* `mark-whole-buffer` and `eval-expression`

    (with-temp-buffer (insert "foo"))

it deactivates mark, although this doesn't:

    (with-temp-buffer (forward-char 1))

and this doesn't (assuming there are two windows with different
buffers):

    (progn (other-window 1) (insert "foo"))

although this does:

    (progn (other-window 1) (insert "foo") (other-window 1))

although this doesn't:

    (progn (other-window 1) (forward-char 1) (other-window 1))

I realize that there's the `deactivate-mark` variable, but I think
it would be better if operations on other buffers would be
consistent in not modifying the mark in current buffer.

regards,
Oleh

bug#16728: 24.3.50; bug? (with-temp-buffer (insert "foo")) deactivates mark in current buffer

[Helmut Eller]

On Wed, Feb 12 2014, Oleh wrote:

> I'm not sure if it's a bug, that's why I'm asking.
> To reproduce, in *scratch* `mark-whole-buffer` and `eval-expression`
>
>     (with-temp-buffer (insert "foo"))

I would also like to know why

 (list (with-temp-buffer
 	(set (make-local-variable 'deactivate-mark) nil)
 	(insert "foo")
        (let (deactivate-mark)
 	  (with-temp-buffer
 	    (insert "bar"))))
       deactivate-mark)

returns (nil t) instead of (nil nil).

Helmut

bug#16728: 24.3.50; bug? (with-temp-buffer (insert "foo")) deactivates mark in current buffer

[Stefan Monnier]

>  (list (with-temp-buffer
>         (set (make-local-variable 'deactivate-mark) nil)
>         (insert "foo")
>           (let (deactivate-mark)
>             (with-temp-buffer
>               (insert "bar"))))
>        deactivate-mark)

The `let' above dynamically binds the `deactivate-mark' of the first
temp-buffer.  The (insert "bar") then set the deactivate-mark in the
second temp-buffer, which did not make it buffer-local, so it really
sets the global deactivate-mark.  Try:

   (with-temp-buffer
     (let ((a 3)
           (buf (current-buffer)))
       (make-local-variable 'a)
       (let ((a 4))
         (with-temp-buffer
           (message "a=%S but a=%S" (list a (local-variable-p 'a))
                                    (with-current-buffer buf
                                      (list a (local-variable-p 'a))))))))

Interaction between let-bindings and buffer-local bindings is tricky.


        Stefan

bug#16728: 24.3.50; bug? (with-temp-buffer (insert "foo")) deactivates mark in current buffer

[Helmut Eller]

On Fri, Feb 14 2014, Stefan Monnier wrote:

>>  (list (with-temp-buffer
>>         (set (make-local-variable 'deactivate-mark) nil)
>>         (insert "foo")
>>           (let (deactivate-mark)
>>             (with-temp-buffer
>>               (insert "bar"))))
>>        deactivate-mark)
>
> The `let' above dynamically binds the `deactivate-mark' of the first
> temp-buffer.  The (insert "bar") then set the deactivate-mark in the
> second temp-buffer, which did not make it buffer-local, so it really
> sets the global deactivate-mark.  Try:
>
>    (with-temp-buffer
>      (let ((a 3)
>            (buf (current-buffer)))
>        (make-local-variable 'a)
>        (let ((a 4))
>          (with-temp-buffer
>            (message "a=%S but a=%S" (list a (local-variable-p 'a))
>                                     (with-current-buffer buf
>                                       (list a (local-variable-p 'a))))))))
>
> Interaction between let-bindings and buffer-local bindings is tricky.

This prints "a=(3 nil) but a=(4 t)". "a=(4 nil) but a=(3 t)" would be
less surprising.

Why is it this way?  This behavior of let seems non-intuitive and
rather useless to me.  I don't suppose that there is a variant of let
that does what I want?

Helmut