From: Eli Zaretskii <eliz@gnu.org>
To: rudalics@gmx.at
Cc: enometh@meer.net, 31695@debbugs.gnu.org
Subject: bug#31695: bug-gnu-emacs@gnu.org
Date: Mon, 04 Jun 2018 19:29:12 +0300 [thread overview]
Message-ID: <83tvqibjmv.fsf@gnu.org> (raw)
In-Reply-To: <83h8mjddvk.fsf@gnu.org> (message from Eli Zaretskii on Sun, 03 Jun 2018 19:38:23 +0300)
> Date: Sun, 03 Jun 2018 19:38:23 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: enometh@meer.net, 31695@debbugs.gnu.org
>
> > Date: Sun, 03 Jun 2018 14:21:58 +0200
> > From: martin rudalics <rudalics@gmx.at>
> >
> > This works correctly here in Emacs 23.4.1 and is broken in 24.5.50.1.
>
> It became broken in Emacs 24.3, according to my testing.
>
> > If Eli doesn't come up with a clue, could someone with a fast machine
> > please try to bisect this.
>
> Right.
>
> If no one comes up with the culprit, I will look into this tomorrow.
I took a look, but as expected, got lost among twisted little
passages, all alike. It looks like the problem might be with the
insane dance we perform when entering recursive edit in the
minibuffer, where we save and restore the window configuration of the
selected frame, and also of the frame that serves as the minibuffer
frame for the selected frame. Another potential culprit is
select_window_1, which added the call to set_point_from_marker at its
end, something that wasn't there in Emacs 24.2.
In any case, the immediate cause of the problem is that when redisplay
is entered the offending window is selected and has its point set at
BOB. So redisplays redraws it accordingly.
Btw, note that if you modify the recipe to do it from frame $a, the
problem doesn't happen. Which seems to imply that this is somehow
related to the order in which redisplay redraws frames. I think.
Let me know if I can help more.
next prev parent reply other threads:[~2018-06-04 16:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-03 4:47 bug#31695: bug-gnu-emacs@gnu.org Madhu
2018-06-03 12:21 ` martin rudalics
2018-06-03 16:38 ` Eli Zaretskii
2018-06-04 16:29 ` Eli Zaretskii [this message]
2018-06-05 13:36 ` martin rudalics
2018-06-04 20:40 ` Gemini Lasswell
2018-06-05 13:37 ` martin rudalics
2018-06-07 8:39 ` martin rudalics
2018-06-07 15:30 ` Eli Zaretskii
2018-06-08 8:00 ` martin rudalics
2018-06-08 8:18 ` Eli Zaretskii
[not found] ` <<83po11vghl.fsf@gnu.org>
2018-06-08 13:58 ` Drew Adams
2018-06-08 14:36 ` Eli Zaretskii
2018-06-08 14:38 ` Robert Pluim
[not found] ` <<<83po11vghl.fsf@gnu.org>
[not found] ` <<0b7a8176-03d2-4efd-bf60-e193e8433f85@default>
[not found] ` <<83a7s5uyzi.fsf@gnu.org>
2018-06-08 14:47 ` Drew Adams
2018-06-14 3:32 ` bug#31695: minibuffer command takes window-point from another frame displaying the same buffer Noam Postavsky
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=83tvqibjmv.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=31695@debbugs.gnu.org \
--cc=enometh@meer.net \
--cc=rudalics@gmx.at \
/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).