Re: Edebug corrupting point in buffers.

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Tue, Nov 01, 2022 at 19:57:11 +0200, Eli Zaretskii wrote:
> > Date: Tue, 1 Nov 2022 17:24:26 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > >   (defcustom edebug-save-displayed-buffer-points nil
> > >     "If non-nil, save and restore point in all displayed buffers.

> > > What am I missing?

> > The troublesome behaviour is controlled by edebug-save-windows, not
> > edebug-save-displayed-buffer-points.  edebug-save-windows is enabled by
> > default.  Sorry for not reading your post more carefully.

> This now gets me back to the inability to reproduce the problem with
> your recipe.  If that depends on edebug-save-windows, not on
> edebug-save-displayed-buffer-points, and since edebug-save-windows is
> t by default, why wasn't I able to reproduce the problem?

I don't know.  Have you tried again?

> Anyway, the documentation of edebug-save-windows says:


>    -- User Option: edebug-save-windows
>        If this is non-‘nil’, Edebug saves and restores the window
>        configuration.  That takes some time, so if your program does not
>        care what happens to the window configurations, it is better to set
>        this variable to ‘nil’.

>        If the value is a list, only the listed windows are saved and
>        restored.

> So I'm now asking whether setting edebug-save-windows to nil would
> have solved your problem, and if so, whether we really need some
> bugfix and a new varaiable?

Well, it seems at the moment that my problem was caused by
set-window-configuration, in that not only does it restore the stored
window configuration, it also overwrites the buffer-points for all but
the current buffer.  That is the mechanism of the corruption of the
buffer-points, which I detailed earlier.

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.

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.

To come back to your two questions, I honestly don't know if setting
edebug-save-windows to nil would have prevented the problem.  I think
so, but I'm not sure.  The original bug is an arduous bug to set up.

Whether we need a bugfix, I would say definitely yes.  There is no way
that a user faced with this corruption of a buffer-point would somehow
say "Ah, window configurations!  That's what's going wrong".  Maybe we
could fix it by documenting the precise situation in the Elisp manual,
possibly combined with making edebug-save-windows nil by default.

Or maybe the patch to the code is a safer, more direct fix.  After all,
edebug is the system debugger, the tool of last resort.  It should not
fail at all.

-- 
Alan Mackenzie (Nuremberg, Germany).