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

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

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 2764 bytes --]

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@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''

[-- Attachment #2: throw-bug-sit-for.el --]
[-- Type: application/octet-stream, Size: 2195 bytes --]

(defun foo ()
  (interactive)
  (cond ((eq (selected-window) (active-minibuffer-window))
         (switch-to-buffer-other-window "*Messages*")
         (min-msg "-------------------"))
        (t
         (select-frame-set-input-focus (window-frame (active-minibuffer-window)))
         (select-window (active-minibuffer-window))
         (min-msg "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"))))

(global-set-key (kbd "<pause>") 'foo)

(defun min-msg (message)
  (save-selected-window
    (select-window (minibuffer-window))
    (with-current-buffer (window-buffer (active-minibuffer-window))
      (message nil)
      (let ((ol (make-overlay (point-max) (point-max) nil t t))
            (inhibit-quit t))
        (unwind-protect
             (progn (unless (zerop (length message))
                      (put-text-property 0 1 'cursor t message))
                    (overlay-put ol 'after-string message)
                    (redisplay 'FORCE)
                    (my-sit-for (or minibuffer-message-timeout 1000000))
                    ;; (when (my-sit-for (or minibuffer-message-timeout 1000000))
                    ;;  (message "+++++++++++++++++")(sleep-for 2))
                    )
          (delete-overlay ol))))))

(defun my-sit-for (seconds &optional nodisp obsolete)
  (if (numberp nodisp)
      (setq seconds (+ seconds (* 1e-3 nodisp))
            nodisp obsolete)
    (if obsolete (setq nodisp obsolete)))
  (cond
   (noninteractive
    (sleep-for seconds)
    t)
   ((and (input-pending-p)
         ;; (progn (message "event: %S" last-input-event) (sleep-for 1)
         ;;        t
         )
    nil)
   ((<= seconds 0)
    (or nodisp (redisplay)))
   (t
    (or nodisp (redisplay))
    (let ((read (read-event nil nil seconds)))
      (or (null read)
          (progn
            (if (eq overriding-terminal-local-map universal-argument-map)
                (setq read (cons t read)))
            (push read unread-command-events)
            nil))))))

(setq minibuffer-frame-alist '((minibuffer . only)))
(setq default-minibuffer-frame  (make-frame minibuffer-frame-alist))
(setq default-frame-alist '((minibuffer)))

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

[Lars Ingebrigtsen]

Drew Adams <drew.adams@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

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@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