bug#8301: 24.0.50; non-interactive `yank' in another buffer leaves point before insertion

bug#8301: 24.0.50; non-interactive `yank' in another buffer leaves point before insertion

[Drew Adams]

Help me understand what I'm missing.  The behavior seems consistent
across Emacs releases, so I doubt that it represents a bug (?).
But perhaps there is a doc bug?  The behavior I see seems to
contradict the doc.
 
I cannot seem to find anything in the doc that explains what I see,
and even looking at the code and following it in the debugger I
don't understand.
 
`insert' seems to not be moving point after the inserted text when
`yank' is called non-interactively in another buffer.  After the
insertion, both point and the mark are at the insertion position (before
the inserted text).
 
emacs -Q
 
Double-click mouse-1 on a word in buffer *scratch*, then `M-w', to have
something in the kill ring.
 
Move point to, e.g., the end of buffer *scratch*.
 
C-x C-f foo.el
 
Type this in foo.el, then evaluate it (`C-x C-e').
 
(with-current-buffer "*scratch*" (yank))
 
The text is inserted at the end of buffer *scratch* (i.e. at point), but
point in that buffer remains before the inserted text.  It's not just a
difference of `window-point' or something; point is not advanced to be
after the insert.  Both point and mark are before the inserted text.
 
I don't see why this is the behavior, and I don't see why it should be.
Executing `yank' interactively with *scratch* current does as I would
expect, and evaling `yank' non-interactively with *scratch* already
current (i.e. without the `with-current-buffer') does similarly.
 
This has nothing to do with `with-current-buffer' per se.  Both
`save-current-buffer' and (progn (set-buffer...)...) behave likewise.
 
`insert' is coded in C, so I'm not sure just what is happening.  I find
nothing in the doc that would suggest this should be the behavior.  The
`yank' doc says that `yank' (with no prefix arg) puts point after the
inserted text.  And even with a prefix arg it is not supposed (per the
doc) to leave point and mark at the same position.  Similarly for the
`insert' doc.  What am I missing?

At one point I guessed that `insert' might be doing what I expect but
then something else moved point back to the original position.  But I
don't see this in the debugger: `insert' itself does not seem to move
point forward.
 
Please help me understand what's happening and why.  Also, please let me
know what I can/should use in my code to get the behavior that I
expected: with the other buffer (e.g. *scratch*) current, yank the head
of the kill ring at point in that buffer, putting mark at the insertion
point and point at the end of the insertion.

In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2011-03-07 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.5) --no-opt --cflags
-Ic:/imagesupport/include'
 

bug#8301: 24.0.50; non-interactive `yank' in another buffer leaves point beforeinsertion

[Drew Adams]

Sorry, I should have been clearer with my recipe. I meant `C-x 4 f foo.el', not
`C-x C-f foo.el'.

It seems that this makes a difference: If the buffer is visible then the
behavior I described occurs.  If the buffer is not visible (e.g. if you do `C-x
C-f foo.el*, so *scratch* is not visible when you eval the sexp), then it
behaves as I would expect (no bug).

So maybe this does have something to do with `window-point' after all?  Dunno.

Anyway, I would like to know how to code this so that it does what I expect
regardless of whether the target buffer is visible.  Thx.

bug#8301: 24.0.50; non-interactive `yank' in another buffer leaves point beforeinsertion

[Drew Adams]

I see that calling (set-window-point the-window (point)) after yanking fixes the
problem.  And I probably should have realized what was involved.  No bug,
including no doc bug, I believe.  I'll close the bug.

bug#8301: 24.0.50; non-interactive `yank' in another buffer leaves point beforeinsertion

[Stefan Monnier]

> So maybe this does have something to do with `window-point' after
> all?  Dunno.

Yup.  It's the same old issue of the fact that a buffer displayed in
N windows has N+1 different `point's.  Every time a command finishes,
every buffer's `point' may get reinitialized from the `point' of one of
the windows displaying the buffer.


        Stefan