Problem with `while-no-input'

Problem with `while-no-input'

[klaus.berndl]

Hello,

A question to `while-no-input':

I tried this short test-code:

(defun klaus-test-input ()
  (interactive)
  (let ((result nil)
        (i 0))
    (setq result (while-no-input
                   (while t
                     (setq i (1+ i)))))
    (message "Klaus: %s" result)))

I expected this to being interrupted by any user-interaction (e.g. keypress etc..)
and setting result to t according to the docstring of `while-no-input':

   while-no-input is a Lisp macro in `subr.el'.
   (while-no-input &rest body)

   Execute body only as long as there's no pending input.
   If input arrives, that ends the execution of body,
   and `while-no-input' returns t.  Quitting makes it return nil.
   If body finishes, `while-no-input' returns whatever value body produced.

But only C-g interrupts this code but not pressing any key like 'a' etc...

Have i overlooked something or have i misunderstood the documentation of
`while-no-input'? Have i misinterpreted the sentence "If input arrives,
that ends the execution of body, and `while-no-input' returns t" or what
I'm doing wrong?

Thanks for your help!

I tried this with Emacs 22.0.50.1 compiled on 29.1.2006 for Windows....

Ciao,
Klaus

Re: Problem with `while-no-input'

[Kim F. Storm]

<klaus.berndl@sdm.de> writes:

> I tried this with Emacs 22.0.50.1 compiled on 29.1.2006 for Windows....

It works fine on 

GNU Emacs 22.0.50.69 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2006-03-08 on kfs-l.imdomain.dk

Maybe windoze doesn't have some form of async input processing, so maybe it cannot see if input arrives while it is running lisp code.

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

Re: Problem with `while-no-input'

[LENNART BORGMAN]

From: storm@cua.dk (Kim F. Storm)

> <klaus.berndl@sdm.de> writes:
> 
> > I tried this with Emacs 22.0.50.1 compiled on 29.1.2006 for 
> Windows....
> It works fine on 
> 
> GNU Emacs 22.0.50.69 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll 
> bars) of 2006-03-08 on kfs-l.imdomain.dk
> 
> Maybe windoze doesn't have some form of async input processing, so 
> maybe it cannot see if input arrives while it is running lisp code.

MS Windows is event driven. Maybe some input queue must be checked?

Re: Problem with `while-no-input'

[martin rudalics]

>>>I tried this with Emacs 22.0.50.1 compiled on 29.1.2006 for 
>>
>>Windows....
>>It works fine on 
>>
>>GNU Emacs 22.0.50.69 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll 
>>bars) of 2006-03-08 on kfs-l.imdomain.dk
>>
>>Maybe windoze doesn't have some form of async input processing, so 
>>maybe it cannot see if input arrives while it is running lisp code.
> 
> 
> MS Windows is event driven. Maybe some input queue must be checked?

GNU Emacs 22.0.50.1 (i386-mingw-windows98.3000) of 2006-02-18 handles
this instantaneously.

Re: Problem with `while-no-input'

[martin rudalics]

> GNU Emacs 22.0.50.1 (i386-mingw-windows98.3000) of 2006-02-18 handles
> this instantaneously.

I lied.  It hangs too.

Re: Problem with `while-no-input'

[Jason Rumney]

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

LENNART BORGMAN wrote:
> From: storm@cua.dk (Kim F. Storm)
>
>   
>> <klaus.berndl@sdm.de> writes:
>>
>>     
>>> I tried this with Emacs 22.0.50.1 compiled on 29.1.2006 for 
>>>       
>> Windows....
>> It works fine on 
>>
>> GNU Emacs 22.0.50.69 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll 
>> bars) of 2006-03-08 on kfs-l.imdomain.dk
>>
>> Maybe windoze doesn't have some form of async input processing, so 
>> maybe it cannot see if input arrives while it is running lisp code.
>>     
>
> MS Windows is event driven. Maybe some input queue must be checked?
>   
MS Windows is event driven, but something has to read those events, and 
this is done synchronously in the Lisp thread's main loop. Whatever code 
is doing the checking of the Lisp level event queue for `while-no-input' 
needs to also trigger a check of the Windows message queue in case there 
are input events there that need promoting to Lisp events.



[-- Attachment #1.2: Type: text/html, Size: 1559 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: Problem with `while-no-input'

[klaus.berndl]

Kim F. Storm wrote:
> <klaus.berndl@sdm.de> writes:
> 
>> I tried this with Emacs 22.0.50.1 compiled on 29.1.2006 for
>> Windows.... 
> 
> It works fine on
> 
> GNU Emacs 22.0.50.69 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll
> bars) of 2006-03-08 on kfs-l.imdomain.dk 
> 
> Maybe windoze doesn't have some form of async input processing, so
> maybe it cannot see if input arrives while it is running lisp code. 

Well - could be, do not know - but is the `while-no-input' not intended
to work on each os supported by Emacs? AFAIK Emacs supports Windows...;-)

I assume not while-no-input but the underlying `throw-on-input' mechanism
at c-level is the root of the problem, isn't it?

klaus

Re: Problem with `while-no-input'

[Stefan Monnier]

>> > I tried this with Emacs 22.0.50.1 compiled on 29.1.2006 for Windows....
>> It works fine on 
>> 
>> GNU Emacs 22.0.50.69 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll 
>> bars) of 2006-03-08 on kfs-l.imdomain.dk
>> 
>> Maybe windoze doesn't have some form of async input processing, so 
>> maybe it cannot see if input arrives while it is running lisp code.

> MS Windows is event driven.  Maybe some input queue must be checked?

Presumably, under w32, the QUIT macro somehow checks for the C-g key.
So hopefully the same mechanism should work for other keys.


        Stefan

Re: Problem with `while-no-input'

[Richard Stallman]

    Maybe windoze doesn't have some form of async input processing, so maybe it cannot see if input arrives while it is running lisp code.

If that is so, we should document the deficiency somehow.

RE: Problem with `while-no-input'

[klaus.berndl]

Richard Stallman wrote:
>     Maybe windoze doesn't have some form of async input processing,
> so maybe it cannot see if input arrives while it is running lisp
> code.  
> 
> If that is so, we should document the deficiency somehow.

Hmm, would it not better, to enable while-not-input also working with Windows? ;-)
(no, i have not the know-how to do this for myself, sorry - and it`s also only a plea from me if a developer with the needed knowhow could do it - i thought, some mails from Jason and lennard points to the right entry?!...)

IMHO this is a very important and helpful macro which enables Emacs and other nifty tools on top of Emacs to be much more user-friendly and -responsive! And IMHO a lot of windows-users want to use Emacs.......

Klaus

Re: Problem with `while-no-input'

[Richard Stallman]

    Hmm, would it not better, to enable while-not-input also working with Windows? ;-)

Yes, it would be better, but that may be very difficult.  (I don't
know.)  We should document it if we can't fix it.

Re: Problem with `while-no-input'

[Jason Rumney]

Richard Stallman <rms@gnu.org> writes:

>     Hmm, would it not better, to enable while-not-input also working with Windows? ;-)
>
> Yes, it would be better, but that may be very difficult.  (I don't
> know.)  We should document it if we can't fix it.

I think the relevant code is in keyboard.c in the POLL_FOR_INPUT
conditional blocks. Currently this code handles detection of C-g
according to the comments, I do not know why it manages to do that
without also handling general detection of input.

I don't know if this code is only used on Windows, or other systems
also use it (maybe old versions of X?). It doesn't appear to have
been written specifically for Windows.

Re: Problem with `while-no-input'

[Jason Rumney]

Jason Rumney <jasonr@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     Hmm, would it not better, to enable while-not-input also working with Windows? ;-)
>>
>> Yes, it would be better, but that may be very difficult.  (I don't
>> know.)  We should document it if we can't fix it.
>
> I think the relevant code is in keyboard.c in the POLL_FOR_INPUT
> conditional blocks.

After looking more closely, I now see that C-g is handled specially in
w32fns.c on windows in the function post_character_message. It may be
possible to do something in here to make while-not-input work.

Re: Problem with `while-no-input'

[Eli Zaretskii]

> Date: Wed, 08 Mar 2006 14:50:43 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: emacs-devel@gnu.org, klaus.berndl@sdm.de, "Kim F. Storm" <storm@cua.dk>
> 
> GNU Emacs 22.0.50.1 (i386-mingw-windows98.3000) of 2006-02-18 handles
> this instantaneously.

If this is indeed so, perhaps some difference between Windows 9x and
Windows XP, because on XP a version older than that behaves like the
latest CVS, i.e. while-no-input is not interrupted by input, only by
C-g.

Re: Problem with `while-no-input'

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Date: Sat, 11 Mar 2006 12:35:49 +0000
> Cc: emacs-devel@gnu.org, storm@cua.dk, klaus.berndl@sdm.de
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> >     Hmm, would it not better, to enable while-not-input also working with Windows? ;-)
> >
> > Yes, it would be better, but that may be very difficult.  (I don't
> > know.)  We should document it if we can't fix it.
> 
> I think the relevant code is in keyboard.c in the POLL_FOR_INPUT
> conditional blocks. Currently this code handles detection of C-g
> according to the comments, I do not know why it manages to do that
> without also handling general detection of input.

Jason, I'm looking at keyboard.c, and I don't understand what you are
saying.  Are you saying that POLL_FOR_INPUT code is used by Windows,
and that it should handle this case, but currently only handles C-g?
Or are you saying that the POLL_FOR_INPUT code detects both C-g and
any other sorts of input, but somehow, only on Windows, non-C-g input
goes undetected?

Anyway, I see in w32fns.c:post_character_message that C-g is handled
specially in this function.  When we detect C-g, we signal the special
interrupt_handle.  However, I'm not quite sure who and how sees that
this handle is signaled: sys_select isn't called while the body of
while-no-input runs in this case, since that body is pure Lisp code,
right?  What am I missing?

I also see in the debugger that, when the while-no-input form runs,
w32_read_socket is not called.  I think this explains why Emacs
doesn't see the input, and doesn't interrupt the form's body:
w32_read_socket is the only way to receive input on Windows, right?

I think we can arrange for _any_ input to interrupt a while-no-input
form, but this needs to be done from w32_wnd_proc (which is in another
thread, right?).  Do you think this is a good approach?

Re: Problem with `while-no-input'

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Date: Sat, 11 Mar 2006 15:29:16 +0000
> Cc: storm@cua.dk, klaus.berndl@sdm.de, emacs-devel@gnu.org
> 
> After looking more closely, I now see that C-g is handled specially in
> w32fns.c on windows in the function post_character_message. It may be
> possible to do something in here to make while-not-input work.

I thought about this as well.  It should be easy to do that for simple
keyboard keys, but what about the other input events?  Running too
much of what keyboard.c does from within post_character_message might
prove tricky, since post_character_message runs in a thread that is
different from where the Lisp code runs, right?

Btw, when we signal interrupt_handle from the window thread, what code
takes care that we notice this fact from the Lisp thread?

Re: Problem with `while-no-input'

[Jason Rumney]

Eli Zaretskii <eliz@gnu.org> writes:

> Anyway, I see in w32fns.c:post_character_message that C-g is handled
> specially in this function.  When we detect C-g, we signal the special
> interrupt_handle.  However, I'm not quite sure who and how sees that
> this handle is signaled: sys_select isn't called while the body of
> while-no-input runs in this case, since that body is pure Lisp code,
> right?  What am I missing?
>
> I also see in the debugger that, when the while-no-input form runs,
> w32_read_socket is not called.  I think this explains why Emacs
> doesn't see the input, and doesn't interrupt the form's body:
> w32_read_socket is the only way to receive input on Windows, right?
>
> I think we can arrange for _any_ input to interrupt a while-no-input
> form, but this needs to be done from w32_wnd_proc (which is in another
> thread, right?).  Do you think this is a good approach?

Yes. If async input can be handled on other platforms, then it should
be possible to handle input in w32_wnd_proc instead of passing it on
to be handled by w32_read_socket. But there may be a simpler fix of
setting a flag in post_character_message if noone has time to look at
that immediately.

Re: Problem with `while-no-input'

[Jason Rumney]

Eli Zaretskii <eliz@gnu.org> writes:

> Btw, when we signal interrupt_handle from the window thread, what code
> takes care that we notice this fact from the Lisp thread?

I think that just interrupts any select statements that are waiting
for input. The Lisp thread checks Vquit_flag, which is also set in
this function.

Re: Problem with `while-no-input'

[Richard Stallman]

POLL_FOR_INPUT seems to be defined always.
It is defined whenever HAVE_WINDOW_SYSTEM
if USE_ASYNC_EVENTS is not defined.
I cannot find any definition of USE_ASYNC_EVENTS.

Re: Problem with `while-no-input'

[Jason Rumney]

Eli Zaretskii <eliz@gnu.org> writes:

>> After looking more closely, I now see that C-g is handled specially in
>> w32fns.c on windows in the function post_character_message. It may be
>> possible to do something in here to make while-not-input work.
>
> I thought about this as well.  It should be easy to do that for simple
> keyboard keys, but what about the other input events?

I added the code from keyboard.c for handling Vthrow_on_input to
post_character_message and the mouse button and wheel events. I think
mouse movement should also throw if the mouse is being tracked, but
the code for handling mouse tracking is in w32_read_socket (which is
synchronous and already calls kbd_buffer_store_event_hold), so I have
left that for now.


> Running too much of what keyboard.c does from within
> post_character_message might prove tricky, since
> post_character_message runs in a thread that is different from where
> the Lisp code runs, right?

I think the change I made was safe, as it only touches staticpro'ed
variables. Since that code is called from signal handlers on other
platforms it has some of the same restrictions already, the only extra
thing we have to be careful of on Windows is that it might get part
way through before the time slice is up and the Lisp thread gets
another time slice before it completes (which may involve garbage
collection).

RE: Problem with `while-no-input'

[klaus.berndl]

after running a current build of CVS-Emacs with Windows NT and
testing the short test-snippet below with this current build i got
new results:

Now this code is also interrupted by any keypress (not only after C-g
as in a previous build) - Fine!

But pressing/releasing mouse-buttons does still not interrupt this
code! First after a keypress it is interrupted and then first the queued
mouse-click is performed before the pressed key is inserted in the buffer
(that key which has interrupted this code).

Is this behavior intended? If yes, why? Would it not better also
enabling mouse-interruption?

But nevertheless many thanks for your efforts to make it interruptable by key!

Ciao,
Klaus

> I tried this short test-code:
> 
> (defun klaus-test-input ()
>   (interactive)
>   (let ((result nil)
>         (i 0))
>     (setq result (while-no-input
>                    (while t
>                      (setq i (1+ i)))))
>     (message "Klaus: %s" result)))
> 
> I expected this to being interrupted by any user-interaction (e.g.
> keypress etc..) and setting result to t according to the docstring of
> `while-no-input': 
> 
>    while-no-input is a Lisp macro in `subr.el'.
>    (while-no-input &rest body)
> 
>    Execute body only as long as there's no pending input.
>    If input arrives, that ends the execution of body,
>    and `while-no-input' returns t.  Quitting makes it return nil.
>    If body finishes, `while-no-input' returns whatever value body
> produced. 
> 
> But only C-g interrupts this code but not pressing any key like 'a'
> etc... 
> 
> Have i overlooked something or have i misunderstood the documentation
> of `while-no-input'? Have i misinterpreted the sentence "If input
> arrives, 
> that ends the execution of body, and `while-no-input' returns t" or
> what 
> I'm doing wrong?
> 
> Thanks for your help!
> 
> I tried this with Emacs 22.0.50.1 compiled on 29.1.2006 for
> Windows.... 
> 
> Ciao,
> Klaus
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Problem with `while-no-input'

[Richard Stallman]

    Now this code is also interrupted by any keypress (not only after C-g
    as in a previous build) - Fine!

I note that you say "now".  Did someone make a fix?

    But pressing/releasing mouse-buttons does still not interrupt this
    code! First after a keypress it is interrupted and then first the queued
    mouse-click is performed before the pressed key is inserted in the buffer
    (that key which has interrupted this code).

I think that too is a bug which ought to be fixed.

RE: Problem with `while-no-input'

[klaus.berndl]

Richard Stallman wrote:
>     Now this code is also interrupted by any keypress (not only after
>     C-g as in a previous build) - Fine!
> 
> I note that you say "now".  Did someone make a fix?

If i correctly remember the discussion i tought Jason has applied a fix...?!

> 
>     But pressing/releasing mouse-buttons does still not interrupt this
>     code! First after a keypress it is interrupted and then first the
>     queued mouse-click is performed before the pressed key is
>     inserted in the buffer (that key which has interrupted this code).
> 
> I think that too is a bug which ought to be fixed.

Re: Problem with `while-no-input'

[Jason Rumney]

klaus.berndl@sdm.de wrote:
> But pressing/releasing mouse-buttons does still not interrupt this
> code! First after a keypress it is interrupted and then first the queued
> mouse-click is performed before the pressed key is inserted in the buffer
> (that key which has interrupted this code).
>
> Is this behavior intended? If yes, why? Would it not better also
> enabling mouse-interruption?
>   
No, it is not intended. I added the interruption code to mouse button
and wheel events as well as keyboard input, and in this works for me
with emacs -Q.

RE: Problem with `while-no-input'

[klaus.berndl]

Jason Rumney wrote:
> klaus.berndl@sdm.de wrote:
>> But pressing/releasing mouse-buttons does still not interrupt this
>> code! First after a keypress it is interrupted and then first the
>> queued mouse-click is performed before the pressed key is inserted
>> in the buffer (that key which has interrupted this code).
>> 
>> Is this behavior intended? If yes, why? Would it not better also
>> enabling mouse-interruption? 
>> 
> No, it is not intended. I added the interruption code to mouse button
> and wheel events as well as keyboard input, and in this works for me
> with emacs -Q.

I'm running a build from 22. April 2006 build for Windows (i386-mingw-nt5.1.2600).
With this build it runs (i.e. interrupts) via:
- all keys
- middle-mouse of a 3 button mouse 
- mouse-wheel

It interrupts *not* via left and right mouse-buttons...

> (defun klaus-test-input ()
>   (interactive)
>   (let ((result nil)
>         (i 0))
>     (setq result (while-no-input
>                    (while t
>                      (setq i (1+ i)))))
>     (message "Klaus: %s" result)))

Ciao,
Klaus

Re: Problem with `while-no-input'

[Jason Rumney]

klaus.berndl@sdm.de wrote:
> I'm running a build from 22. April 2006 build for Windows (i386-mingw-nt5.1.2600).
> With this build it runs (i.e. interrupts) via:
> - all keys
> - middle-mouse of a 3 button mouse 
> - mouse-wheel
>
> It interrupts *not* via left and right mouse-buttons...
>   
Is the value of w32-num-mouse-buttons 2?
It seems not to interrupt for me if I set w32-num-mouse-buttons explicitly
to 2 and press the left or right mouse button quickly. Probably related
to w32-mouse-button-tolerance.

So there is probably a case missing in the timeout for simulated middle
button clicks for two button mice.

RE: Problem with `while-no-input'

[klaus.berndl]

Jason Rumney wrote:
> klaus.berndl@sdm.de wrote:
>> I'm running a build from 22. April 2006 build for Windows
>> (i386-mingw-nt5.1.2600). With this build it runs (i.e. interrupts)
>> via: 
>> - all keys
>> - middle-mouse of a 3 button mouse
>> - mouse-wheel
>> 
>> It interrupts *not* via left and right mouse-buttons...
>> 
> Is the value of w32-num-mouse-buttons 2?

yes.

But i use a 3-button mouse! I didn't know that a user has explicitly
set this variable to 3 if he uses a 3-button mouse?! Is this documented
somewhere??

Anyway: If i set w32-num-mouse-buttons to 3 via setq than all works fine,
means the code is interrupted by every mouse-button...

Without this setting only button 2 interrupts, but not buttons 1 and 3...

> It seems not to interrupt for me if I set w32-num-mouse-buttons
> explicitly to 2 and press the left or right mouse button quickly.
> Probably related to w32-mouse-button-tolerance.
> 
> So there is probably a case missing in the timeout for simulated
> middle button clicks for two button mice.

Re: Problem with `while-no-input'

[Lennart Borgman]

klaus.berndl@sdm.de wrote:
> Jason Rumney wrote:
>   
>> klaus.berndl@sdm.de wrote:
>>     
>>> I'm running a build from 22. April 2006 build for Windows
>>> (i386-mingw-nt5.1.2600). With this build it runs (i.e. interrupts)
>>> via: 
>>> - all keys
>>> - middle-mouse of a 3 button mouse
>>> - mouse-wheel
>>>
>>> It interrupts *not* via left and right mouse-buttons...
>>>
>>>       
>> Is the value of w32-num-mouse-buttons 2?
>>     
>
> yes.
>
> But i use a 3-button mouse! I didn't know that a user has explicitly
> set this variable to 3 if he uses a 3-button mouse?! Is this documented
> somewhere??
>
> Anyway: If i set w32-num-mouse-buttons to 3 via setq than all works fine,
> means the code is interrupted by every mouse-button...
>
> Without this setting only button 2 interrupts, but not buttons 1 and 3...
>   
Why not set this information via GetSystemMetrics? There is a good 
example on

    
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/getting_hardware_information.asp

Note: In my MinGW installation SM_CMOUSEBUTTONS is defined (=43) but 
SM_MOUSEPRESENT (=19) is missing.

Re: Problem with `while-no-input'

[Jason Rumney]

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

klaus.berndl@sdm.de wrote:
> Jason Rumney wrote:
>   
>> Is the value of w32-num-mouse-buttons 2?
>>     
>
> yes.
>
> But i use a 3-button mouse! I didn't know that a user has explicitly
> set this variable to 3 if he uses a 3-button mouse?! Is this documented
> somewhere??
>   

It does no harm to have a 3 button mouse falsely detected as a 2-button 
mouse, since it only means the hack of pressing left and right buttons 
simultaneously to simulate a middle click is enabled when it does not 
need to be. Most likely your mouse drivers do not support querying the 
mouse for its capabilities so it is defaulting to the least common 
denominator case.


[-- Attachment #1.2: Type: text/html, Size: 1155 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: Problem with `while-no-input'

[klaus.berndl]

Thanks for explanation!
 
is not a big deal to set w32-num-mouse... in the emacs-setup...but nevertheless: It would be better if Emacs would detect this for itself ;-)
I can not judge, if Lennarts suggestion in his posting is a good approach because i do not have the needed knowhow - but maybe another guy on this list...?! ;-)
 
Ciao,
klaus

________________________________

From: Jason Rumney [mailto:jasonr@gnu.org] 
Sent: Wednesday, April 26, 2006 2:52 PM
To: Berndl, Klaus
Cc: emacs-devel@gnu.org
Subject: Re: Problem with `while-no-input'


klaus.berndl@sdm.de wrote: 

	Jason Rumney wrote:
	  

		Is the value of w32-num-mouse-buttons 2?
		    

	
	yes.
	
	But i use a 3-button mouse! I didn't know that a user has explicitly
	set this variable to 3 if he uses a 3-button mouse?! Is this documented
	somewhere??
	  


It does no harm to have a 3 button mouse falsely detected as a 2-button mouse, since it only means the hack of pressing left and right buttons simultaneously to simulate a middle click is enabled when it does not need to be. Most likely your mouse drivers do not support querying the mouse for its capabilities so it is defaulting to the least common denominator case.

Re: Problem with `while-no-input'

[Jason Rumney]

Lennart Borgman wrote:
> Why not set this information via GetSystemMetrics?
It is, in init_environment in w32.c.

Re: Problem with `while-no-input'

[Jason Rumney]

Jason Rumney <jasonr@gnu.org> writes:

> Is the value of w32-num-mouse-buttons 2?
> It seems not to interrupt for me if I set w32-num-mouse-buttons explicitly
> to 2 and press the left or right mouse button quickly. Probably related
> to w32-mouse-button-tolerance.
>
> So there is probably a case missing in the timeout for simulated middle
> button clicks for two button mice.

In fact, the timeout case was catered for already, but there were two
cases where we preempted the timer that weren't. I've fixed this now.

Re: Problem with `while-no-input'

[Richard Stallman]

    > I note that you say "now".  Did someone make a fix?

    If i correctly remember the discussion i tought Jason has applied a fix...?!

Ok, that is good.  (I don't remember at all.)

Would anyone like to work on this bug?

>     But pressing/releasing mouse-buttons does still not interrupt this
>     code! First after a keypress it is interrupted and then first the
>     queued mouse-click is performed before the pressed key is
>     inserted in the buffer (that key which has interrupted this code).

RE: Problem with `while-no-input'

[klaus.berndl]

Richard Stallman wrote:
>     > I note that you say "now".  Did someone make a fix?
> 
>     If i correctly remember the discussion i tought Jason has applied
> a fix...?! 
> 
> Ok, that is good.  (I don't remember at all.)
> 
> Would anyone like to work on this bug?

seems to be done already... see recent discussion...

> 
>>     But pressing/releasing mouse-buttons does still not interrupt
>>     this code! First after a keypress it is interrupted and then
>>     first the queued mouse-click is performed before the pressed key
>>     is inserted in the buffer (that key which has interrupted this
>> code). 

Re: Problem with `while-no-input'

[Richard Stallman]

    seems to be done already... see recent discussion...

That is good.