From: bojohan+news@dd.chalmers.se (Johan Bockgård)
To: bug-gnu-emacs@gnu.org
Subject: Re: appointment display during isearch replaces buffer contents with history-element
Date: Mon, 19 Nov 2007 01:37:28 +0100 [thread overview]
Message-ID: <yoijmytbul2v.fsf@remote4.student.chalmers.se> (raw)
In-Reply-To: 30sl3899pd.fsf@web.de
Martin Fischer <parozusa@web.de> writes:
> Start isearch-forward, type M-p and scroll the history buffer with
> <up> (previous-history-element).
>
> If at the same time emacs tries to display an appointment in the
> same frame, the contents of the buffer, where you wanted to isearch,
> is replaced by one of the history elements.
>
> The buffer may be restored by undo.
Ok. Here's a condensed recipe.
$ emacs -Q
(defun foo ()
(save-excursion
(other-window 1)))
(push "foo" extended-command-history)
(run-with-timer 5 nil 'foo)
M-x
Wait 5 seconds
Press <up>
The contents of the *scratch* buffer are replaced with "foo"; that is,
the key binding is looked up in the minibuffer's keymap but executed
in *scratch*.
In contrast, executing
emacsclient --eval '(save-excursion (other-window 1))'
while Emacs is waiting at the M-x prompt doesn't confuse the keymaps.
Using this definition for foo also works correctly
(defun foo ()
(interactive)
(other-window 1))
So the problem is when a timer changes the selected window, but not
the current buffer.
This is what I found
* read_process_output (and similar code in exec_sentinel); call
record_asynch_buffer_change unconditionally (processes):
#if 0 /* Call record_asynch_buffer_change unconditionally,
because we might have changed minor modes or other things
that affect key bindings. */
if (! EQ (Fcurrent_buffer (), obuffer)
|| ! EQ (current_buffer->keymap, okeymap))
#endif
/* But do it only if the caller is actually going to read events.
Otherwise there's no need to make him wake up, and it could
cause trouble (for example it would make sit_for return). */
if (waiting_for_user_input_p == -1)
record_asynch_buffer_change ();
* wait_reading_process_output; (2 places) call
record_asynch_buffer_change only if buffer has changed (timers):
/* If a timer has run, this might have changed buffers
an alike. Make read_key_sequence aware of that. */
if (timers_run != old_timers_run
&& waiting_for_user_input_p == -1
&& old_buffer != current_buffer)
record_asynch_buffer_change ();
* read_key_sequence; look for a BUFFER_SWITCH_EVENT (from
record_asynch_buffer_change):
if (BUFFERP (key))
{
timer_resume_idle ();
mock_input = t;
/* Reset the current buffer from the selected window
in case something changed the former and not the latter.
This is to be more consistent with the behavior
of the command_loop_1. */
if (fix_current_buffer)
{
if (! FRAME_LIVE_P (XFRAME (selected_frame)))
Fkill_emacs (Qnil);
if (XBUFFER (XWINDOW (selected_window)->buffer) != current_buffer)
Fset_buffer (XWINDOW (selected_window)->buffer);
}
orig_local_map = get_local_map (PT, current_buffer, Qlocal_map);
orig_keymap = get_local_map (PT, current_buffer, Qkeymap);
goto replay_sequence;
}
* command_loop_1; set selected window's buffer as current between
looking up and executing command:
/* Read next key sequence; i gets its length. */
i = read_key_sequence (keybuf, sizeof keybuf / sizeof keybuf[0],
Qnil, 0, 1, 1);
/* A filter may have run while we were reading the input. */
if (! FRAME_LIVE_P (XFRAME (selected_frame)))
Fkill_emacs (Qnil);
if (XBUFFER (XWINDOW (selected_window)->buffer) != current_buffer)
set_buffer_internal (XBUFFER (XWINDOW (selected_window)->buffer));
--
Johan Bockgård
next prev parent reply other threads:[~2007-11-19 0:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-14 14:35 appointment display during isearch replaces buffer contents with history-element Martin Fischer
2007-11-17 10:44 ` Johan Bockgård
2007-11-17 11:04 ` martin rudalics
2007-11-18 22:43 ` Johan Bockgård
[not found] ` <mailman.3706.1195296268.18990.bug-gnu-emacs@gnu.org>
2007-11-17 17:10 ` Martin Fischer
2007-11-19 0:37 ` Johan Bockgård [this message]
2008-01-02 14:36 ` Chong Yidong
2008-01-10 4:10 ` Glenn Morris
2008-01-10 11:36 ` Johan Bockgård
2008-02-26 11:53 ` Johan Bockgård
2008-02-26 21:31 ` Chong Yidong
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=yoijmytbul2v.fsf@remote4.student.chalmers.se \
--to=bojohan+news@dd.chalmers.se \
--cc=bug-gnu-emacs@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.