Re: Edebug corrupting point in buffers.

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> > Why does set-window-configuration overwrite the buffer-points?
>> > The window configuration does not contain them.  The code just
>> > assumes that the buffer-point should be set to the window point.
>> > Of course, we have a race condition if a buffer is displayed in
>> > several windows.  So this would appear to be a bug, the root cause
>> > of the bug in this thread.
>
>> This suggests the patch below, right?
>> I note that this only changes the buffer-point for `current-buffer`,
>> not for all the buffers displayed in the window-config, right?
>
> Not quite.  It changes the buffer-point for every buffer except the
> "current buffer".

Really?  My reading of the code:

	      /* As documented in Fcurrent_window_configuration, don't
		 restore the location of point in the buffer which was
		 current when the window configuration was recorded.  */
	      if (!EQ (p->buffer, new_current_buffer)
		  && XBUFFER (p->buffer) == current_buffer)
		Fgoto_char (w->pointm);

is that it's done only for the current buffer and only if it's different
from the "to be current buffer".

Am I missing something?

>> Yup.  We could start by providing some way to tell
>> `set-window-configuration` not to change buffer-points (and use that in
>> Edebug)?  This way we fix the problem for Edebug without risking
>> changes elsewhere?
> An &optional parameter, you mean?  I'd thought of that, but it feels
> ugly.

Agreed.  Especially since I get the feeling that it's just a plain bug.

That piece of code dates back to the initial revision of window.c back
in 1991, tho.  That function had some serious bugs in the handling of
buffer points which stayed unnoticed for years (I remember the one
I fixed with in 2005 with e67a1dea3e622d61024b2dc17c36831d048bb271), so
I wouldn't be surprised that this one is also a mistake.

> I've tried it, and the patch doesn't fix the bug.  :-(

Why didn't you say so at the beginning of your message?
Now I look like fool!  :-)


        Stefan