The order input events are processed.

The order input events are processed.

[Michaël Cadilhac]

[-- Attachment #1.1.1: Type: text/plain, Size: 1087 bytes --]


Try the following:

(setq unread-post-input-method-events '(?a ?b ?c))
(sit-for 0.1)

 (Note: This is not a test for the test, this is an actual problem
  with input methods and sit-for)

It will result in the unexpected behavior that events are processed as
« bca ».  IIUC, this is how it happens :

- Sit-for takes the `a' with its `read-event'
- Sit-for stores it back in `unread-command-events' _and it seems normal_:
  I think that users are expected to use that var, especially because
  the docstring says this is the FIRST input var processed.
- read_char is made three times: for the two first times it will take
  events from post-input, then for the third, from
  unread-command-events, because post-input is processed BEFORE
  unread-command-events. 

I think Handa's changes 2006-08-21 (fixing the docstring of post-input
that indicated that it was processed AFTER unread-command-events,
whilst it was the contrary) wasn't the good one.

I propose to revert the docstring and make the code respect both this
one and unread-command-events' one.


[-- Attachment #1.1.2: keyboard.patch --]
[-- Type: text/x-patch, Size: 3226 bytes --]

Index: src/keyboard.c
===================================================================
RCS file: /sources/emacs/emacs/src/keyboard.c,v
retrieving revision 1.874
diff -c -r1.874 keyboard.c
*** src/keyboard.c	27 Aug 2006 07:09:06 -0000	1.874
--- src/keyboard.c	7 Sep 2006 11:19:24 -0000
***************
*** 2504,2526 ****
   retry:
  
    reread = 0;
-   if (CONSP (Vunread_post_input_method_events))
-     {
-       c = XCAR (Vunread_post_input_method_events);
-       Vunread_post_input_method_events
- 	= XCDR (Vunread_post_input_method_events);
- 
-       /* Undo what read_char_x_menu_prompt did when it unread
- 	 additional keys returned by Fx_popup_menu.  */
-       if (CONSP (c)
- 	  && (SYMBOLP (XCAR (c)) || INTEGERP (XCAR (c)))
- 	  && NILP (XCDR (c)))
- 	c = XCAR (c);
- 
-       reread = 1;
-       goto reread_first;
-     }
- 
    if (unread_command_char != -1)
      {
        XSETINT (c, unread_command_char);
--- 2504,2509 ----
***************
*** 2552,2557 ****
--- 2535,2557 ----
        goto reread_for_input_method;
      }
  
+   if (CONSP (Vunread_post_input_method_events))
+     {
+       c = XCAR (Vunread_post_input_method_events);
+       Vunread_post_input_method_events
+ 	= XCDR (Vunread_post_input_method_events);
+ 
+       /* Undo what read_char_x_menu_prompt did when it unread
+ 	 additional keys returned by Fx_popup_menu.  */
+       if (CONSP (c)
+ 	  && (SYMBOLP (XCAR (c)) || INTEGERP (XCAR (c)))
+ 	  && NILP (XCDR (c)))
+ 	c = XCAR (c);
+ 
+       reread = 1;
+       goto reread_first;
+     }
+ 
    if (CONSP (Vunread_input_method_events))
      {
        c = XCAR (Vunread_input_method_events);
***************
*** 11218,11225 ****
  
    DEFVAR_LISP ("unread-post-input-method-events", &Vunread_post_input_method_events,
  	       doc: /* List of events to be processed as input by input methods.
! These events are processed before `unread-command-events'
! and actual keyboard input without given to `input-method-function'.  */);
    Vunread_post_input_method_events = Qnil;
  
    DEFVAR_LISP ("unread-input-method-events", &Vunread_input_method_events,
--- 11218,11225 ----
  
    DEFVAR_LISP ("unread-post-input-method-events", &Vunread_post_input_method_events,
  	       doc: /* List of events to be processed as input by input methods.
! These events are processed after `unread-command-events', but
! before actual keyboard input without given to `input-method-function'.  */);
    Vunread_post_input_method_events = Qnil;
  
    DEFVAR_LISP ("unread-input-method-events", &Vunread_input_method_events,
Index: src/ChangeLog
===================================================================
RCS file: /sources/emacs/emacs/src/ChangeLog,v
retrieving revision 1.5270
diff -c -0 -r1.5270 ChangeLog
*** src/ChangeLog	6 Sep 2006 17:53:59 -0000	1.5270
--- src/ChangeLog	7 Sep 2006 11:19:34 -0000
***************
*** 0 ****
--- 1,6 ----
+ 2006-09-07  Michaël Cadilhac  <michael.cadilhac@lrde.org>
+ 
+ 	* keyboard.c (read_char): Read Vunread_post_input_method_events
+ 	after Vunread_command_events.
+ 	(syms_of_keyboard): Document it in `unread-post-input-method-events'.
+ 

[-- Attachment #1.1.3: Type: text/plain, Size: 334 bytes --]


Regards

-- 
 |      Michaël `Micha' Cadilhac   |  Pour les 35-40 ans, l'humour          |
 |         Epita/LRDE Promo 2007   |       c'est une plus-value.            |
 | http://www.lrde.org/~cadilh_m   |          -- Guillaume L.               |
 `--  -   JID: micha@amessage.be --'                                   -  --'

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: The order input events are processed.

[Richard Stallman]

The whole point of unread-post-input-method-events is to be processed
first.  Changing it to operate last will break it.  When an input method
runs and generates a sequence of several events, those events must
be processed before whatever is in unread-command-events.

We need to fix the bug, but not by changing the meaning of this feature.

One way to fix it is for sit_for to test these variables directly
so that it doesn't need to change them.  Does anyone see a problem
with that?  Would someone like to implement that?

Re: The order input events are processed.

[Michaël Cadilhac]

[-- Attachment #1.1: Type: text/plain, Size: 1563 bytes --]

Richard Stallman <rms@gnu.org> writes:

> The whole point of unread-post-input-method-events is to be processed
> first.  Changing it to operate last will break it.  When an input method
> runs and generates a sequence of several events, those events must
> be processed before whatever is in unread-command-events.

Ok, seems reasonable ;-)

> One way to fix it is for sit_for to test these variables directly
> so that it doesn't need to change them.  Does anyone see a problem
> with that?

Does it mean that sit-for will have to do active wait [1] ? I think
it's not a good way to go, or have we an alternative?

In a first place, I thought that `read-char' could store the var from
which the char read has been taken, so that a function `putback-char'
could but it back in the good list.  How about that ?

However,  I've   always  dreamt  about  an  unique   entry  point  for
unread-events: unread-command-events would  store direct events (u-c-e
= '(?a ?b))  or events as a cons, the cdr  telling if input-method has
to be used (u-c-e = '(?a (?b . nil) ?c)). Does it seems crazy? [2]

Footnotes: 
[1]  (while (not (or unread-command-events unread-*))
        )

[2]  Of course, _after_ the release ;-)

-- 
 |      Michaël `Micha' Cadilhac   |  La culture c'est comme la confiture,  |
 |         Epita/LRDE Promo 2007   |      c'est meilleur avec du pain.      |
 | http://www.lrde.org/~cadilh_m   |           -- MOI59                     |
 `--  -   JID: micha@amessage.be --'                                   -  --'

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: The order input events are processed.

[Richard Stallman]

    > One way to fix it is for sit_for to test these variables directly
    > so that it doesn't need to change them.  Does anyone see a problem
    > with that?

    Does it mean that sit-for will have to do active wait [1] ? 

I see no reason to think so.  It just has to check these variables
at the start.

    However,  I've   always  dreamt  about  an  unique   entry  point  for
    unread-events: unread-command-events would  store direct events (u-c-e
    =3D '(?a ?b))  or events as a cons, the cdr  telling if input-method has
    to be used (u-c-e =3D '(?a (?b . nil) ?c)). Does it seems crazy? [2]

It seems ugly and complex.  Not as good as the present scheme.


Here's the patch I have in mind.  If input methods use sit-for, we
might need to create a way to refrain from testing
unread-post-input-method-events in that case.


*** subr.el	27 Jul 2006 23:33:22 -0400	1.523
--- subr.el	10 Sep 2006 08:28:34 -0400	
***************
*** 1730,1745 ****
  floating point support.
  
  \(fn SECONDS &optional NODISP)"
!   (when (or obsolete (numberp nodisp))
!     (setq seconds (+ seconds (* 1e-3 nodisp)))
!     (setq nodisp obsolete))
!   (if noninteractive
!       (progn (sleep-for seconds) t)
!     (unless nodisp (redisplay))
!     (or (<= seconds 0)
! 	(let ((read (read-event nil nil seconds)))
! 	  (or (null read)
! 	      (progn (push read unread-command-events) nil))))))
  \f
  ;;; Atomic change groups.
  
--- 1730,1749 ----
  floating point support.
  
  \(fn SECONDS &optional NODISP)"
!   (unless (or unread-command-events
! 	      unread-post-input-method-events
! 	      unread-input-method-events
! 	      (>= unread-command-char 0))
!     (when (or obsolete (numberp nodisp))
!       (setq seconds (+ seconds (* 1e-3 nodisp)))
!       (setq nodisp obsolete))
!     (if noninteractive
! 	(progn (sleep-for seconds) t)
!       (unless nodisp (redisplay))
!       (or (<= seconds 0)
! 	  (let ((read (read-event nil nil seconds)))
! 	    (or (null read)
! 		(progn (push read unread-command-events) nil)))))))
  \f
  ;;; Atomic change groups.

Re: The order input events are processed.

[Michaël Cadilhac]

[-- Attachment #1.1: Type: text/plain, Size: 1610 bytes --]

Richard Stallman <rms@gnu.org> writes:

>     However,  I've   always  dreamt  about  an  unique   entry  point  for
>     unread-events: unread-command-events would  store direct events (u-c-e
>     =3D '(?a ?b))  or events as a cons, the cdr  telling if input-method has
>     to be used (u-c-e =3D '(?a (?b . nil) ?c)). Does it seems crazy? [2]
>
> It seems ugly and complex.  Not as good as the present scheme.

Okey.

>   \(fn SECONDS &optional NODISP)"
> !   (unless (or unread-command-events
> ! 	      unread-post-input-method-events
> ! 	      unread-input-method-events
> ! 	      (>= unread-command-char 0))

Isn't input-pending-p enough?

> !     (when (or obsolete (numberp nodisp))
> !       (setq seconds (+ seconds (* 1e-3 nodisp)))
> !       (setq nodisp obsolete))
> !     (if noninteractive
> ! 	(progn (sleep-for seconds) t)
> !       (unless nodisp (redisplay))
> !       (or (<= seconds 0)
> ! 	  (let ((read (read-event nil nil seconds)))
> ! 	    (or (null read)
> ! 		(progn (push read unread-command-events) nil)))))))

I was thinking of an active loop because I thought the test had to be
made here, replacing « read-event ».  If we're sure read-event will
not take an event from unread-input-method-events here, then it's ok.

-- 
 |      Michaël `Micha' Cadilhac   |  Si les religions etaient aussi tole-  |
 |         Epita/LRDE Promo 2007   |  rantes qu'elles le pretendent, il y   |
 | http://www.lrde.org/~cadilh_m   |  a longtemps qu'il n'y en aurait plus  |
 `--  -   JID: micha@amessage.be --'           -- Moustic              -  --'

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: The order input events are processed.

[Kim F. Storm]

michael.cadilhac@lrde.org (Michaël Cadilhac) writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     However,  I've   always  dreamt  about  an  unique   entry  point  for
>>     unread-events: unread-command-events would  store direct events (u-c-e
>>     =3D '(?a ?b))  or events as a cons, the cdr  telling if input-method has
>>     to be used (u-c-e =3D '(?a (?b . nil) ?c)). Does it seems crazy? [2]
>>
>> It seems ugly and complex.  Not as good as the present scheme.
>
> Okey.
>
>>   \(fn SECONDS &optional NODISP)"
>> !   (unless (or unread-command-events
>> ! 	      unread-post-input-method-events
>> ! 	      unread-input-method-events
>> ! 	      (>= unread-command-char 0))
>
> Isn't input-pending-p enough?
>
>> !     (when (or obsolete (numberp nodisp))
>> !       (setq seconds (+ seconds (* 1e-3 nodisp)))
>> !       (setq nodisp obsolete))
>> !     (if noninteractive
>> ! 	(progn (sleep-for seconds) t)
>> !       (unless nodisp (redisplay))
>> !       (or (<= seconds 0)
>> ! 	  (let ((read (read-event nil nil seconds)))
>> ! 	    (or (null read)
>> ! 		(progn (push read unread-command-events) nil)))))))
>
> I was thinking of an active loop because I thought the test had to be
> made here, replacing « read-event ».  If we're sure read-event will
> not take an event from unread-input-method-events here, then it's ok.


What about this version (using the fixed version of input-pending-p and
documented behaviour of redisplay, both just committed):

It used unread-post-input-method-events instead of unread-command-events
to ensure that the event is pushed back on the first list of events
processed by read-event.


(defun sit-for (seconds &optional nodisp obsolete)
  "..."
  (when (or obsolete (numberp nodisp))
    (setq seconds (+ seconds (* 1e-3 nodisp)))
    (setq nodisp obsolete))
  (cond
   (noninteractive
    (sleep-for seconds)
    t)
   ((input-pending-p)
    nil)
   ((<= seconds 0)
    (or nodisp (redisplay)))
   (t
    (or nodisp (redisplay))
    (let ((read (read-event nil nil seconds)))
      (or (null read)
	  (progn (push read unread-post-input-method-events)
		 nil))))))


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: The order input events are processed.

[Richard Stallman]

    >   \(fn SECONDS &optional NODISP)"
    > !   (unless (or unread-command-events
    > ! 	      unread-post-input-method-events
    > ! 	      unread-input-method-events
    > ! 	      (>=3D unread-command-char 0))

    Isn't input-pending-p enough?

input-pending-p does not check all of those variables.
Is that a bug?

    I was thinking of an active loop because I thought the test had to be
    made here, replacing =AB read-event =BB.  If we're sure read-event will
    not take an event from unread-input-method-events here, then it's ok.

If unread-input-method-events is empty, then nothing can be taken from
it.  So the only way this could happen is if something were to run
inside read-event which made unread-input-method-events nonempty.

That is not impossible; various things can call Lisp code from inside
read-event and they COULD put something on unread-input-method-events.
But that would be very strange usage.

So I think we are ok.

Re: The order input events are processed.

[Richard Stallman]

    It used unread-post-input-method-events instead of unread-command-events
    to ensure that the event is pushed back on the first list of events
    processed by read-event.

That change is not right, I think.  Using
unread-post-input-method-events instead of unread-command-events
alters the way the events are processed: it does goto reread_first
instead of goto reread_for_input_method.

With your change (or my change), we know that these lists are
empty when read-event is called.  That being so, I think it is fine
to put the event back in unread-command-events.

Re: The order input events are processed.

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     It used unread-post-input-method-events instead of unread-command-events
>     to ensure that the event is pushed back on the first list of events
>     processed by read-event.
>
> That change is not right, I think.  Using
> unread-post-input-method-events instead of unread-command-events
> alters the way the events are processed: it does goto reread_first
> instead of goto reread_for_input_method.

But since the event was returned by read-event, hasn't it been through
the "for_input_method" code already?  So passing through once more
seems like a bug to me.  

But I don't quite understand this input method stuff, so I suppose
you are right.

> With your change (or my change), we know that these lists are
> empty when read-event is called.  That being so, I think it is fine
> to put the event back in unread-command-events.

Ok.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: The order input events are processed.

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     >   \(fn SECONDS &optional NODISP)"
>     > !   (unless (or unread-command-events
>     > ! 	      unread-post-input-method-events
>     > ! 	      unread-input-method-events
>     > ! 	      (>=3D unread-command-char 0))
>
>     Isn't input-pending-p enough?
>
> input-pending-p does not check all of those variables.
> Is that a bug?

I definitely think so -- and I have installed a fix to remedy that.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk