all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Kenichi Handa <handa@m17n.org>
Cc: michael.cadilhac-@t-lrde.epita.fr, emacs-devel@gnu.org
Subject: Re: [michael.cadilhac-@t-lrde.epita.fr: sit-for (detect_input_pending ?) and postfix input methods.]
Date: Wed, 05 Oct 2005 16:26:35 +0900	[thread overview]
Message-ID: <E1EN3ff-0002eS-00@etlken> (raw)
In-Reply-To: <E1EMIa9-0005hI-PX@fencepost.gnu.org> (rms@gnu.org)

In article <E1EMIa9-0005hI-PX@fencepost.gnu.org>, "Richard M. Stallman" <rms@gnu.org> 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 <michael.cadilhac-@t-lrde.epita.fr>
> 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
handa@m17n.org

       reply	other threads:[~2005-10-05  7:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1EMIa9-0005hI-PX@fencepost.gnu.org>
2005-10-05  7:26 ` Kenichi Handa [this message]
2005-10-05 16:27   ` [michael.cadilhac-@t-lrde.epita.fr: sit-for (detect_input_pending ?) and postfix input methods.] Michael Cadilhac
2005-10-06  1:01     ` Kenichi Handa
2005-10-06 12:36       ` Michael Cadilhac
2005-10-06 12:45         ` Kenichi Handa
2005-10-05 17:42   ` Stefan Monnier
2005-10-06  1:17     ` Kenichi Handa
2005-10-10  4:15   ` Richard M. Stallman
2005-10-10  9:46     ` Kim F. Storm
2005-10-10 10:53       ` David Kastrup

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=E1EN3ff-0002eS-00@etlken \
    --to=handa@m17n.org \
    --cc=emacs-devel@gnu.org \
    --cc=michael.cadilhac-@t-lrde.epita.fr \
    /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.