Re: Edebug corrupting point in buffers.

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Tue, Nov 01, 2022 at 17:51:45 -0400, Stefan Monnier wrote:
> >> > 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?

Hmm.  I spent a great deal of yesterday asserting false things, then
apologising for them.  The above was the last such false thing, for which
I also apologise.

I think I was influenced by the doc string of
current-window-configuration, which seems to imply what I wrote above.

> >> 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!  :-)

The fundamental problem is a conceptual one:- so many bits of code
wrongly take the liberty of writing to buffer point when they have no
business doing so.  The only code which should transfer window point to
buffer point is the command loop (or maybe redisplay) when the window is
about to become the one that the user will edit in.  Or something like
that.  There's clearly been a lot of confusion about window/buffer point
over the decades which shows in the number of places such changes in
buffer point occur, and the bugs which have sometimes resulted, like the
one you cite above.

However, even I can see that it is impracticable to try to fix this now.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).