From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: Edebug corrupting point in buffers.
Date: Thu, 3 Nov 2022 19:57:46 +0000 [thread overview]
Message-ID: <Y2QdOpsEKPqBoSrC@ACM> (raw)
In-Reply-To: <jwvy1sryhb3.fsf-monnier+emacs@gnu.org>
Hello, Stefan.
On Thu, Nov 03, 2022 at 15:29:38 -0400, Stefan Monnier wrote:
> Eli Zaretskii [2022-11-02 16:00:52] wrote:
> >> Date: Wed, 2 Nov 2022 11:34:37 +0000
> >> Cc: emacs-devel@gnu.org
> >> From: Alan Mackenzie <acm@muc.de>
> >> (i) Emacs -Q.
> >> (ii) On a single frame, arrange buffers *scratch*, test-edebug.el, and
> >> some other substantial buffer, that I call emacs.README.
> >> (iii) Put point in emacs.README somewhere other than point-max.
> >> (iv) Instrument test-edebug for edebug with C-u C-M-x.
> >> (iv)a Put point into window *scratch*.
> >> (v) M-: (test-edebug).
> >> (vi) Step through test-edebug using the space key.
> >> (vii) Note that the second text insertion happens where point was in the
> >> window, not at point-max. This is the bug.
> > Yes, I see the problem, but setting edebug-save-windows to nil
> > eliminates it. So I think we already have a solution for the rare
> > situations where this is an issue.
> I wish Someone™ could dig into the problem further and find the source
> of the problem and an actual fix, but indeed, this seems like a fair
> workaround in the mean time.
I think I said something about this earlier on in the thread. The cause
seems to be that random bits of software wrongly consider it their
business to overwrite the buffer point with a window point.
Amongst these bits of software are select-window,
set-window-configuration, and our very own edebug-set-buffer-points
(triggered by the option edebug-save-displayed-buffer-points). I think
there are many more.
The solution, were it practicable, would be to have only the command
loop or maybe redisplay copying WP to BP, and only just before the
window becomes the current place where the user might edit.
> Maybe a good short term "fix/workaround" is to change the implementation
> of `edebug-save-windows` so that in addition to the windows's info it
> also saves&restores the buffer-point of those buffers displayed in the
> saved windows.
My first patch did something like this. It saved the buffer points of
all buffers, then restored it in buffers selected by the user. This
patch was rejected (and I think rightly so) for being too clumsy to use.
> Stefan
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2022-11-03 19:57 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-31 11:43 Edebug corrupting point in buffers; we need buffer-point and set-buffer-point, perhaps Alan Mackenzie
2022-10-31 13:16 ` Eli Zaretskii
2022-10-31 14:32 ` Alan Mackenzie
2022-10-31 14:50 ` Eli Zaretskii
2022-10-31 15:46 ` Alan Mackenzie
2022-10-31 17:33 ` Stefan Monnier
2022-10-31 17:55 ` Eli Zaretskii
2022-10-31 20:46 ` Alan Mackenzie
2022-11-01 6:21 ` Eli Zaretskii
2022-10-31 17:19 ` Stefan Monnier
2022-10-31 18:09 ` Eli Zaretskii
2022-10-31 20:35 ` Stefan Monnier
2022-10-31 17:21 ` Stefan Monnier
2022-10-31 18:10 ` Eli Zaretskii
2022-10-31 23:14 ` Stefan Monnier
2022-11-01 7:06 ` Eli Zaretskii
2022-10-31 21:25 ` Alan Mackenzie
2022-11-01 6:45 ` Eli Zaretskii
2022-11-01 11:41 ` Edebug corrupting point in buffers Alan Mackenzie
2022-11-01 11:53 ` Eli Zaretskii
2022-11-01 13:42 ` Alan Mackenzie
2022-11-01 14:42 ` Eli Zaretskii
2022-11-01 17:06 ` Alan Mackenzie
2022-11-01 17:12 ` Eli Zaretskii
2022-11-01 17:24 ` Alan Mackenzie
2022-11-01 17:57 ` Eli Zaretskii
2022-11-01 19:02 ` Alan Mackenzie
2022-11-01 19:47 ` Stefan Monnier
2022-11-01 20:53 ` Alan Mackenzie
2022-11-01 21:51 ` Stefan Monnier
2022-11-02 10:40 ` Alan Mackenzie
2022-11-02 13:12 ` Stefan Monnier
2022-11-02 13:28 ` Eli Zaretskii
2022-11-02 3:28 ` Eli Zaretskii
2022-11-02 12:53 ` Stefan Monnier
2022-11-02 17:40 ` Juri Linkov
2022-11-02 18:26 ` Eli Zaretskii
2022-11-02 18:36 ` Juri Linkov
2022-11-02 18:52 ` Eli Zaretskii
2022-11-03 17:25 ` Juri Linkov
2022-11-03 18:06 ` Eli Zaretskii
2022-11-03 18:31 ` Juri Linkov
2022-11-02 11:34 ` Alan Mackenzie
2022-11-02 14:00 ` Eli Zaretskii
2022-11-02 16:18 ` Alan Mackenzie
2022-11-02 16:57 ` Eli Zaretskii
2022-11-03 11:32 ` Alan Mackenzie
2022-11-03 13:29 ` Eli Zaretskii
2022-11-03 18:07 ` Alan Mackenzie
2022-11-03 18:15 ` Eli Zaretskii
2022-11-03 20:25 ` Alan Mackenzie
2022-11-05 11:24 ` Eli Zaretskii
2022-11-05 16:50 ` Alan Mackenzie
2022-11-06 8:10 ` Eli Zaretskii
2022-11-06 14:40 ` Alan Mackenzie
2022-11-03 19:29 ` Stefan Monnier
2022-11-03 19:36 ` Eli Zaretskii
2022-11-03 20:39 ` Stefan Monnier
2022-11-04 6:34 ` Eli Zaretskii
2022-11-04 6:37 ` Eli Zaretskii
2022-11-03 19:57 ` Alan Mackenzie [this message]
2022-11-03 20:35 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y2QdOpsEKPqBoSrC@ACM \
--to=acm@muc.de \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).