followup on "window configuration bug"

followup on "window configuration bug"

[John H Palmieri]

I submitted a bug report about window configurations changing the
position of the point, rms sent me a potential bug fix, and I
responded saying that while the patch fixed my bug, it introduced new
problems.  This was at the end of May, and I haven't heard anything
since.  Is this still being worked on, or did it slip through the
cracks?


Initial bug report:

palmieri@math.washington.edu (John H Palmieri) writes:

> I start Emacs with 'emacs -q'.  I define this function (by typing it
> into the *scratch* buffer and hitting C-j):
>
> (defun test ()
>   (interactive)
>   (let ((config (current-window-configuration)))
>     (insert "hello")
>     (set-window-configuration config)))
>
> I type 'M-x test', and "hello" gets inserted into the buffer, with the
> point after the "o".  Good.
>
> I type 'C-x 2 M-x test', and "hello" gets inserted into the buffer,
> with the point at the "h".  Bad: the documentation for
> current-window-configuration says
>
>    An exception is made for point in the current buffer:
>    its value is -not- saved.
>
> I interpret this to mean that the function set-window-configuration
> should not alter the point.  It does, and that's a bug.
>
> It's almost as if, even though the point in the current buffer is not
> saved, the point in the other window (which contains the same buffer)
> *is* saved, and this is messing up the position of the point.
> However, the value of the variable split-window-keep-point appears to
> be irrelevant: toggling this variable, hitting C-x 2, and running
> 'M-x test' still causes the misplaced point.  Hitting C-x 2 and
> switching between the windows, (in case one of them is viewed as the
> "current buffer" and the other is something else in which the point
> deserves to be saved) still results in the misplaced point.


response from rms:

rms@gnu.org (Richard Stallman) writes:

>     It's almost as if, even though the point in the current buffer is not
>     saved, the point in the other window (which contains the same buffer)
>     *is* saved, and this is messing up the position of the point.
>
> Yes, the position of point in other windows is supposed to be saved.
> There is a special exception for point in the current buffer--that is not
> supposed to be saved or restored.
>
> It looks like the bug is that point in the current buffer IS being
> restored.
>
> Please try this patch:
>
>
> *** window.c.~1.415.~	Sun May 26 14:30:50 2002
> --- window.c	Thu May 30 11:58:23 2002
> ***************

[patch omitted]


my response to that (dated May 30):

palmieri@math.washington.edu (John H Palmieri) writes:

> Your patch fixes my problem, but introduces another one: 
>
> (defun test ()
>   (interactive)
>   (let ((config (current-window-configuration)))
>     (insert "hello")
>     (set-window-configuration config)))
>
> Hit 'C-x 2', then 'M-x test', and "hello" gets inserted, with the
> point after the "o".  This is a fix of the bug I reported.
>
> However, hit 'C-x 2 C-x o', so that I'm in the second window associated
> to this buffer.  Move the point around and do 'M-x test': "hello" gets
> inserted, but it gets inserted in the wrong place: not at the current
> point, but instead at the point in the first buffer.  It appears that
> the point is getting repositioned before the function is executed:
> if I do 'M-x debug-on-entry test' in this situation, move the point
> around and run 'M-x test', then as soon as the backtrace buffer
> appears, the point has been moved.  In fact, if I do lots of things,
> the point in the second buffer gets changed to the point in the first
> buffer.  For example, if I type 'M-x debug-on-entry', then by the time
> the prompt "Debug on entry (to function):" appears, the point has been
> moved.

-- 
J. H. Palmieri
Dept of Mathematics, Box 354350    mailto:palmieri@math.washington.edu
University of Washington           http://www.math.washington.edu/~palmieri/
Seattle, WA 98195-4350