Possibly incorrect non-deactivation of mark from kbd macro

Possibly incorrect non-deactivation of mark from kbd macro

[Ben North]

A cut-down version of something I recently found with

   GNU Emacs 22.0.93.1
   (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)

which I think might be a bug:

Define

   (defun insert-X-as-if-from-kbd-macro ()
     (interactive)
     (save-excursion (execute-kbd-macro "X")))

Turn on `transient-mark-mode'.  In, say, the start-up scratch buffer,
set mark to be the start of the buffer, move forward a word, then do
`M-x insert-X-as-if-from-kbd-macro'.  The mark is not deactivated even
though the buffer has been modified.  If you try

   (defun insert-X-using-insert ()
     (interactive)
     (save-excursion (insert "X")))

then the mark is correctly deactivated.  I tried to dig into where the C
variable `Vdeactivate_mark' was getting cleared but didn't get very far,
sorry.  Hope the report is useful anyway.

Re: Possibly incorrect non-deactivation of mark from kbd macro

[Stuart D. Herring]

> Define
>
>    (defun insert-X-as-if-from-kbd-macro ()
>      (interactive)
>      (save-excursion (execute-kbd-macro "X")))
>
> Turn on `transient-mark-mode'.  In, say, the start-up scratch buffer,
> set mark to be the start of the buffer, move forward a word, then do
> `M-x insert-X-as-if-from-kbd-macro'.  The mark is not deactivated even
> though the buffer has been modified.  If you try
>
>    (defun insert-X-using-insert ()
>      (interactive)
>      (save-excursion (insert "X")))
>
> then the mark is correctly deactivated.  I tried to dig into where the C
> variable `Vdeactivate_mark' was getting cleared but didn't get very far,
> sorry.  Hope the report is useful anyway.

This is a case where the documentation must be read quite carefully.

 save-excursion is a special form.
 (save-excursion &rest BODY)

 Save point, mark, and current buffer; execute BODY; restore those things.
 Executes BODY just like `progn'.
 The values of point, mark and the current buffer are restored
 even in case of abnormal exit (throw or error).
 The state of activation of the mark is also restored.

 This construct does not save `deactivate-mark', and therefore
 functions that change the buffer will still cause deactivation
 of the mark at the end of the command.  To prevent that, bind
 `deactivate-mark' with `let'.

In your first example, the only buffer modification that occurs takes
place in a nested command -- one started by `execute-kbd-macro' (it calls
command_loop_1()).  When _it_ finishes, it does in fact deactivate the
mark.  But it finishes before `execute-kbd-macro' returns!  (After all,
`post-command-hook' must be run once for each command in a keyboard
macro.)  Then the macro finishes, and as you exit the `save-excursion' it
reactivates the mark.

In the second example, the (innermost) command that contains the buffer
modification _is_ your function, so `save-excursion' finishes before the
mark is deactivated and the mark stays deactivated.

Hope this helps,
Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Possibly incorrect non-deactivation of mark from kbd macro

[Ben North]

Stuart D. Herring wrote:
> [Ben North wrote:]
> >    (defun insert-X-as-if-from-kbd-macro ()
> >       (interactive)
> >       (save-excursion (execute-kbd-macro "X")))
> >
> > [...] The mark is not deactivated
>
> [...] the only buffer modification that occurs takes place in a nested
> command -- one started by `execute-kbd-macro' [...].  When _it_
> finishes, it does in fact deactivate the mark.  But it finishes before
> `execute-kbd-macro' returns!  [...]  Then the macro finishes, and as
> you exit the `save-excursion' it reactivates the mark.

Thanks for the explanation.  I see what's going on now.

Perhaps it would have been more useful for me to have given the
non-cut-down version of what I encountered: I had recorded a keyboard
macro, and then applied it to the lines in the region using `C-x C-k r'.
Despite many buffer modifications, the mark remained active.  This
struck me as counter-intuitive behaviour from a user level.

I wouldn't claim this is a huge problem, but if it could be fixed, I
think emacs' behaviour would be less surprising in this situation.