In article <[EMAIL PROTECTED]>, "Richard M. Stallman" <[EMAIL PROTECTED]>
writes:
> Would you please look at this, and ack? (We have no maintainer for
> flyspell now.)
> ------- Start of forwarded message -------
> To: emacs-pretest-bug@gnu.org
> From: Michael Cadilhac <[EMAIL PROTECTED]>
> Subject: sit-for (detect_input_pending ?) and postfix input methods.
[...]
> For a test-case :
> (defun test-case-after-change (a b c)
> (if (sit-for 3)
> (message "sit-for: t")
> (message "sit-for: nil")))
> (defun test-case ()
> (interactive)
> (set (make-local-variable 'after-change-functions)
> '(test-case-after-change)))
> With a buffer `foo', M-x test-case RET and then with no input method
> specified, just hit repeatedly (but don't stay on the touch), let's
> say, `u'.
> You'll have something like
> sit-for: nil [14 times]
> sit-for: t
> in your *Messages* buffer. This result is expected : sit-for is
> interrupted and return nil, then the last `u' produce a successful
> sit-for.
> Now, clear `foo', and M-x set-input-method RET latin-1-postfix RET
> Now do the same (with `u', as it has suffix options), and it'll result
> in:
> sit-for: t [14 times]
> Outch ! `sit-for' exits with `t', what a mess !
> I think this is a bug of the C function `detect_input_pending' or the
> way input-method are managed, can you reproduce it ?
This is because sit-for instantly returns t if
unread-command-events is not nil, and the currrent input
method mechanism uses unread-command-events in the following
way:
To make the explanation clear, I'll right the first `u'
event as `u1' and the second `u' event as `u2'.
When you turn on latin-1-postfix, type `u1', `u1' is given
to the function quail-input-method (and the callees). This
binds inhibit-modification-hooks to t and insert "u" with
underline, then wait for another key sequence. This
insertion doesn't activate test-case-after-change.
When `u2' is typed, quail-input-method at first delete the
underlined "u", and returns that character `u' as an event
to be processed later. But, before returning, it set `u2'
in unread-command-events so that it is processed again by
the input method.
Then, the returned event `u' is handled in the normal
command loop and self-insert-command is called, and
test-case-after-change is called. At this time, as
unread-command-events is not nil, sit-for returns t.
Then, why does sit-for return t if unread-command-events is not
nil?
sit_for does something like this:
...
wait_reading_process_output ()
return detect_input_pending () ? Qnil : Qt;
}
wait_reading_process_output () returns instantly when
unread-command-events, but detect_input_pending () returns 0
because no input event is pending.
I don't know which is bad, but I found this suspicious
comment for requeued_events_pending_p which is called by
wait_reading_process_output.
/* Return nonzero if there are pending requeued events.
This isn't used yet. The hope is to make wait_reading_process_output
call it, and return if it runs Lisp code that unreads something.
The problem is, kbd_buffer_get_event needs to be fixed to know what
to do in that case. It isn't trivial. */
At least that comment should be fixed because it's actually
used now.
This is the first time I read these codes, and I don't know
how those functions are used in the other places. So I'd
like to ask someone else to fix this problem if you think
this is the problem to be fixed.
As for the original problem of flyspell, how about this
workaround?
*** flyspell.el 23 Sep 2005 10:59:25 +0900 1.75
--- flyspell.el 05 Oct 2005 16:19:56 +0900
***************
*** 770,776 ****
((get this-command 'flyspell-delayed)
;; the current command is not delayed, that
;; is that we must check the word now
! (sit-for flyspell-delay))
(t t)))
(t t)))
--- 770,777 ----
((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)))
(t t)))
---
Kenichi Handa
[EMAIL PROTECTED]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
