[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#14810: 24.3.50; bothersome case where `input-pending' returns t but

From: Drew Adams
Subject: bug#14810: 24.3.50; bothersome case where `input-pending' returns t but should return nil
Date: Sat, 6 Jul 2013 20:10:31 -0700 (PDT)

Not sure what the best Subject line is for this bug.

I'm having some trouble with `minibuffer-message' in the context of a
standalone minibuffer frame.  Messages that should appear and remain
displayed for the full `minibuffer-message-timeout' period (2 sec)
are shown and then immediately erased.

emacs -Q

Load the attached file.

The code for `min-msg' is a stripped-down version of the code for
`minibuffer-message'.  The code for `my-sit-for' is essentially the code
for `sit-for'.

M-x <pause> <pause> <pause>...

That is, hit the Pause key multiple times, waiting 2 sec or more between
each key press.

You _should_ see an alternating message each time <pause> is pressed:



Each message _should_ remain displayed for 2 sec, unless you hit another
key (or use the mouse etc.).  Instead, each message appears and then is
erased so quickly that it is hard to even notice that it was displayed.

If you remove the (redisplay 'FORCE) from the code then you will not
even see the messages at all.

If you replace the call to `my-sit-for' by the commented lines following
it (in `min-msg') then you can see that the `sit-for' never returns
non-nil (except the first time).

Or if you uncomment the commented lines in `my-sit-for' you will see that
`input-pending-p' always returns t.

I am even interested in knowing a workaround.  And in understanding the
problem better.

At one point I thought the problem might have to do with `sit-for'
receiving a `switch-frame' event from `select-frame-set-focus' and
(mistakenly) handling it like user input, but this does not seem to be
the case.

If you uncomment the commented lines in `my-sit-for' you will see that
the event that causes the `input-pending' to return t is apparently
`pause', i.e., hitting the Pause key.

That seems wrong to me (a bug?).  If you wait more than 2 sec before
hitting <pause> then I do not see how `sit-for' can see the `pause'
event.  Unless perhaps there is some additional `sit-for' somewhere
(not in the attached code).

I do understand that `input-pending' does not _guarantee_ to return
nil when there is no pending input.  But I would like some way to
control the behavior in this scenario. 


In GNU Emacs (i686-pc-mingw32)
 of 2013-07-01 on LEG570
Bzr revision: 113246 address@hidden
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/usr --enable-checking CFLAGS='-O0 -g3'
 CPPFLAGS='-DGLYPH_DEBUG=1 -I/c/usr/include''

Attachment: throw-bug-sit-for.el
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]