GNU bug report logs - #14810
24.3.50; bothersome case where `input-pending' returns t but should return nil

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14810 in the body.
You can then email your comments to 14810 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; bothersome case where `input-pending' returns t but should
 return nil
Date: Sat, 6 Jul 2013 20:10:31 -0700 (PDT)

[Message part 1 (text/plain, inline)]

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:

-------------------
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
-------------------
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
-------------------
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

etc.

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. 

Thx.



In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-07-01 on LEG570
Bzr revision: 113246 lekktu <at> gmail.com-20130701165437-ea20s94hqwp3ttaj
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''

[throw-bug-sit-for.el (application/octet-stream, attachment)]

Message #8 received at 14810 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 14810 <at> debbugs.gnu.org
Subject: Re: bug#14810: 24.3.50; bothersome case where `input-pending'
 returns t but should return nil
Date: Wed, 20 Jan 2021 03:59:22 +0100

Drew Adams <drew.adams <at> oracle.com> writes:

> 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.

(I'm going through old bug reports that unfortunately got no response at
the time.)

The code in this area has been substantially reworked in the years since
you've reported this problem.  Are you still seeing this in more recent
Emacs versions?  If so, do you have a simpler recipe to reproduce it?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #13 received at 14810 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 14810 <at> debbugs.gnu.org
Subject: Re: bug#14810: 24.3.50; bothersome case where `input-pending'
 returns t but should return nil
Date: Mon, 22 Feb 2021 16:16:53 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> The code in this area has been substantially reworked in the years since
> you've reported this problem.  Are you still seeing this in more recent
> Emacs versions?  If so, do you have a simpler recipe to reproduce it?

More information was requested, but no response was given within a
month, so I'm closing this bug report.  If the problem still exists,
please respond to this email and we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.