bug#16702: 24.3.50; flyspell in message mode messes up latin prefix input

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 12 Feb 2014 16:36:31 -0500
> Cc: Ivan Kanis <ivan@tao.kanis.fr>, 16702@debbugs.gnu.org
> 
>     emacs -Q
>     C-\ latin-prefix RET
>     d'
>       -> now displayed in the buffer "d" followed by "'" with underline.
>          Echo area displays stuff you can input next.
> 
> 
> Repeat with
>     emacs -Q -f flyspell-mode
> 
> and just see "d" followed by nothing in the buffer, and one extra
> element at the front of the echo area list.
> 
> 
> It seems to be just a display issue, because the input method still
> works (eg if you type "d'y", you get "d" followed by an accented "y".)

I see the same symptoms, but I don't think it's a display issue.  I
think it's an issue with how we read events in sit-for.

The problem seems to be with this code in flyspell (part of
flyspell-check-word-p):

      (cond
       ((get this-command 'flyspell-deplacement)
        (not (eq flyspell-previous-command this-command)))
       ((get this-command 'flyspell-delayed)
        ;; The current command is not delayed, that
        ;; is that we must check the word now.
        (and (not unread-command-events) <<<<<<<<<<<<<<<<<<<
             (sit-for flyspell-delay)))  <<<<<<<<<<<<<<<<<<<
       (t t)))

This is Flyspell giving the user a chance to take a short break while
typing a word, and avoid spell-checking incomplete words.  If you
customize flyspell-delay to zero, the problem goes away.

The change that introduced this bug is the following portion of
revision 113293:

  -    (let ((read (read-event nil nil seconds)))
  +    ;; FIXME: we should not read-event here at all, because it's much too
  +    ;; difficult to reliably "undo" a read-event by pushing it onto
  +    ;; unread-command-events.
  +    (let ((read (read-event nil t seconds)))

We now call read-event with 2nd arg t instead of nil.  If I revert
this single change, the problem goes away even without zeroing out
flyspell-delay.

Of course, I'm not saying we should actually revert this change: it
was done for a reason.  But hopefully, Stefan, who made that change,
will know how to fix this problem, which is that asking sit-for to
read events while inheriting the input method sometimes isn't TRT.