Re: Edebug corrupting point in buffers.

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Tue, Nov 01, 2022 at 15:47: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".

> There's still a "race condition", of course.

> > Maybe set-window-configuration should be amended not to write the
> > buffer-points?  That might cause problems in other areas, though.  The
> > window configuration is one of the few areas where the documentation is
> > poor enough that you need to read the C source to find out what it's
> > really doing.

> 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.

> We can try and run out own Emacs with the patch installed, to see if we
> notice any regression.

Indeed, yes.  I count 89 occurrences of '(set-window-configuration' in
our Lisp sources.  That's not really a comfortable number to check by
looking at the code.  :-(

> If we do, that might help us understand what we should do.  If we
> don't, maybe it's hint that it was really just a bug.

It feels like a bug for the reasons already given, and the fact that the
"current buffer"'s buffer-point is spared.  If there's something wrong
with overwriting that buffer's buffer-point, why is it OK for all the
other buffers in windows in the window-configuration?

I'm going to try out your patch and see if it, by itself, fixes the bug,
now that I've got a reproducible test case.

<...later...>

I've tried it, and the patch doesn't fix the bug.  :-(  Something else
is clearly overwriting the buffer-point.

>         Stefan


> diff --git a/src/window.c b/src/window.c
> index b858d145415..382d3cbdc6a 100644
> --- a/src/window.c
> +++ b/src/window.c
> @@ -7270,12 +7270,6 @@ DEFUN ("set-window-configuration", Fset_window_configuration,
>  	      set_marker_restricted (w->start, p->start, w->contents);
>  	      set_marker_restricted (w->pointm, p->pointm, w->contents);
>  	      set_marker_restricted (w->old_pointm, p->old_pointm, w->contents);
> -	      /* 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);
>  	    }
>  	  else if (BUFFERP (w->contents) && BUFFER_LIVE_P (XBUFFER (w->contents)))
>  	    /* Keep window's old buffer; make sure the markers are real.  */

-- 
Alan Mackenzie (Nuremberg, Germany).