From: Eli Zaretskii <eliz@gnu.org>
To: Amai Kinono <amaikinono@gmail.com>
Cc: 44448@debbugs.gnu.org
Subject: bug#44448: Fwd: bug#44448:
Date: Thu, 12 Aug 2021 15:44:34 +0300 [thread overview]
Message-ID: <83wnoqde8d.fsf@gnu.org> (raw)
In-Reply-To: <CAPu3fz19AhXRMqtRuKwRnwGc593TE7PXLsdeV7qY-f4Hjvgmaw@mail.gmail.com> (message from Amai Kinono on Wed, 11 Aug 2021 20:18:36 +0800)
> From: Amai Kinono <amaikinono@gmail.com>
> Date: Wed, 11 Aug 2021 20:18:36 +0800
>
> > Some code in paren.el probably moves point without unwind-protect, or
> something like that.
>
> It's not. To answer you, I've created a new recipe that only moves overlay, and
> triggers the problem:
>
> 1. emacs -Q
>
> 2. M-x find-library RET paren
>
> 3. M-x split-window-horizontally
>
> 4. Go to the bottom of the file
>
> 5. M-x read-only-mode to turn off read-only-mode so we can write things here.
> Also M-x auto-save-mode to stop Emacs from auto saving it.
>
> 6. Paste and eval this:
>
> (defvar test-overlay (make-overlay (point-min) (1+ (point-min))))
> (overlay-put test-overlay 'face 'isearch)
> (run-with-timer 0 0.05 (lambda ()
> (let ((beg (random 5)))
> (move-overlay test-overlay beg (1+ beg)))))
> (defvar test-overlay2 (make-overlay (1- (point-max)) (point-max)))
> (overlay-put test-overlay2 'face 'isearch)
> (run-with-timer 0 0.05 (lambda ()
> (let ((beg (- (point-max) (random 5))))
> (move-overlay test-overlay beg (1+ beg)))))
>
> Now we have 2 overlays dancing at the beginning and end of buffer.
>
> 7. Go to the end of ther buffer, holding C-g for several secs. You may need to
> do this several times, but there are chances that the cursor goes to the
> beginning of the buffer.
Thanks. I see the cause of it: it's the :eval forms that we execute
when we redisplay the mode line, as part of redisplaying a window.
When more than one window displays the same buffer at different buffer
positions, when Emacs redisplays a non-selected window, it temporarily
moves point to the place where it is displayed in that non-selected
window. If C-g is processed while those :eval forms run, with the
buffer's point temporarily moved, you will see point in the selected
window "inherit" the position of point from the other window showing
the same buffer. As evidence, after this happens, you should be able
to see this in *Messages*:
Error during redisplay: (mode-line-default-help-echo #<window 3 on paren.el>) signaled (quit)
We could prevent this jumping of point in these cases by running the
:eval forms in the mode line with inhibit-quit bound to t, but then it
will be impossible to interrupt :eval forms that run amok for some
reason, which is a real danger, since the mode-line format is very
frequently customized to include more or less arbitrary Lisp. So I'm
not sure that inhibiting quitting would be a good idea here: the cure
could be worse than the disease.
Ideas for fixing this are welcome.
next prev parent reply other threads:[~2021-08-12 12:44 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-04 16:48 bug#44448: 27.1; Strange inteference between timer, modeline/header-line and buffer position in window Amai Kinono
2020-11-04 20:12 ` Eli Zaretskii
2020-12-07 16:45 ` Lars Ingebrigtsen
2021-02-05 13:42 ` bug#44448: Amai Kinono
2021-02-05 13:44 ` bug#44448: Lars Ingebrigtsen
2021-08-11 5:49 ` bug#44448: Amai Kinono
2021-08-11 11:20 ` bug#44448: Lars Ingebrigtsen
[not found] ` <CAPu3fz0cn0NjjSdZ34KYCw0ZweaR3tBCaRTxwe3fccTQL=Gq5g@mail.gmail.com>
2021-08-11 12:18 ` bug#44448: Fwd: bug#44448: Amai Kinono
2021-08-11 11:43 ` bug#44448: Eli Zaretskii
[not found] ` <CAPu3fz1HwaXCztR05vjXO19_6oWXOPgG7LKV2t7isV6J9KMMCQ@mail.gmail.com>
2021-08-11 12:18 ` bug#44448: Fwd: bug#44448: Amai Kinono
2021-08-12 12:44 ` Eli Zaretskii [this message]
2021-08-12 14:07 ` Eli Zaretskii
[not found] ` <CAPu3fz1YHXqAdN+0B-45J+geEwC70QTuAZLe1vuwmq+gTq64NA@mail.gmail.com>
2021-08-13 9:49 ` bug#44448: Fwd: " Amai Kinono
2021-08-14 9:25 ` Eli Zaretskii
2021-08-15 11:21 ` Eli Zaretskii
2021-08-15 12:12 ` Amai Kinono
2021-08-15 14:15 ` Eli Zaretskii
2021-08-15 18:10 ` Amai Kinono
2021-08-15 18:29 ` Eli Zaretskii
2021-08-16 18:28 ` Amai Kinono
2021-08-16 19:09 ` Eli Zaretskii
2021-08-17 18:09 ` Amai Kinono
2021-08-17 18:31 ` Eli Zaretskii
2021-08-18 12:05 ` Amai Kinono
2021-08-18 13:16 ` Eli Zaretskii
2021-08-18 14:00 ` Amai Kinono
2021-08-18 15:47 ` Eli Zaretskii
2021-12-04 6:13 ` Amai Kinono
2021-12-04 8:38 ` Eli Zaretskii
2021-12-04 11:42 ` Amai Kinono
2021-12-04 16:07 ` Eli Zaretskii
2021-08-11 12:22 ` bug#44448: [Amai Kinono] bug#44448: Lars Ingebrigtsen
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=83wnoqde8d.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=44448@debbugs.gnu.org \
--cc=amaikinono@gmail.com \
/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).