unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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





  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

  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=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 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).