Re: set-window-point

[Nick Roberts]

Richard M. Stallman writes:
 >     I mean set-window-point doesn't change point and the cusor remains where
 >     it was (at the start of the buffer).
 > 
 > Whether that is a bug depends on the rest of the window configuration.
 > What was that configuration?  What windows did you have, and what
 > buffers did they display, and which one was selected, and which window
 > did you do this in?

Does it really depend on these things?  The docstring seems unequivocal,
although the manual is more circumspect about window-point:

     Strictly speaking, it would be more correct to return the
     "top-level" value of point, outside of any `save-excursion' forms.
     But that value is hard to find.

 > It is also possible that set-window-point did move point, but
 > something else moved point back afterward.  Such bugs do occur.

If set-window-point is in a function that has save-excursion, say, and that
function is called, then I agree.  If I step under Edebug, as below (in
gdb-assembler-custom) so that the cursor moves from the first caret to the
second, when

1) (get-buffer-window buffer 0) evaluates to a window with...
2) its hollow cursor position (point) at the start and
3) pos is a large number

then I can't see how the cursor position (point) can fail to move.

   (if (not (equal gdb-frame-address "main"))
        (set-window-point (get-buffer-window buffer 0) pos))))
                                                          ^^
even though it may move back later.

 > Stepping thru Fset_window_point would be the best way to investigate
 > this.

I'll explore this avenue but I expect that I will make slow progress.

Nick