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).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4