From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Alan Mackenzie <acm@muc.de>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: Edebug corrupting point in buffers.
Date: Thu, 03 Nov 2022 16:35:09 -0400 [thread overview]
Message-ID: <jwvh6zfye6b.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <Y2QdOpsEKPqBoSrC@ACM> (Alan Mackenzie's message of "Thu, 3 Nov 2022 19:57:46 +0000")
>> 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.
This characterization is a bit too vague and open-ended to be
actionable, sadly. I was thinking of "the source of the problem" for
the specific case you described earlier in the bug-report (i.e. one we
can conveniently reproduce). Admittedly, fixing this one case may
not fix all cases, but will at least get us closer.
>> 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.
I was thinking that by limiting the saved&restored buffer-points to
those displayed in the saved windows, we'd make it more "automatic" than
your patch.
Stefan
prev parent reply other threads:[~2022-11-03 20:35 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
2022-11-03 20:35 ` Stefan Monnier [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvh6zfye6b.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=acm@muc.de \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.