From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>
Cc: enometh@meer.net, 31695@debbugs.gnu.org
Subject: bug#31695: bug-gnu-emacs@gnu.org
Date: Tue, 05 Jun 2018 15:36:48 +0200 [thread overview]
Message-ID: <5B1691F0.3070704@gmx.at> (raw)
In-Reply-To: <83tvqibjmv.fsf@gnu.org>
> 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.
This is indeed a very troublesome aspect because we restore the
current buffer (which is per se not related to window configurations)
twice. Basically, it should suffice to save/restore selected frame
and current buffer around saving/restoring the configuration of the
minibuffer frame, but I'm afraid that this might lead to subtle
changes that would go undetected for another six years.
The real problem is described in this comment
/* BUF_PT (XBUFFER (new_current_buffer)) gives us the position of
point in new_current_buffer as of the last time this buffer was
used. This can be non-deterministic since it can be changed by
things like jit-lock by mere temporary selection of some random
window that happens to show this buffer.
So if possible we want this arbitrary choice of "which point" to
be the one from the to-be-selected-window so as to prevent this
window's cursor from being copied from another window. */
and indeed my change which causes the current bug executes
old_point = BUF_PT (XBUFFER (new_current_buffer));
and later does
if (!EQ (XWINDOW (data->current_window)->contents, new_current_buffer))
Fgoto_char (make_number (old_point));
where old_point is BUF_PT obtained from the other frame showing NEWS -
the one at BOB. And it does this when restoring the configuration of
the minibuffer frame. When restoring the NEWS frame the wrong setting
is already cast. Replacing the last two lines with
if (!EQ (XWINDOW (selected_window)->contents, new_current_buffer))
Fgoto_char (make_number (old_point));
fixes both the present bug and the behavior from Bug#12208 so if I do
not find a better solution I intend to use that. IMHO the idea behind
new_current_buffer = data->f_current_buffer;
is inherently botched when restoring a frame where that buffer appears
on another 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.
This might be related but I have not found any impact yet.
> 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.
I'm quite sure this is the case. To make it happen from $a you have
to set the window point of $b first, then in $a choose another window
point and then start the minibuffer rigmarole.
martin
next prev parent reply other threads:[~2018-06-05 13:36 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
2018-06-05 13:36 ` martin rudalics [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5B1691F0.3070704@gmx.at \
--to=rudalics@gmx.at \
--cc=31695@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=enometh@meer.net \
/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.