GNU bug report logs - #5923
23.1.95; minibuffer-message discards input events

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 5923 in the body.
You can then email your comments to 5923 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: 23.1.95; minibuffer-message discards input events
Date: Sat, 10 Apr 2010 09:52:20 -0700

Sorry, I don't have the time to try to track this down further.
 
Suffice it to say that starting with Emacs 23 `minibuffer-message'
discards input events during its `sit-for', that is while it displays
its message.

Dunno if this is a general `sit-for' bug or a `minibuffer-message'
bug. In effect, the `sit-for' is not interrupted by an input event
- it acts like `sleep-for'. Starting with Emacs 23,
`minibuffer-message' is coded differently (in Lisp, not C); dunno
about `sit-for'.
 
In my application, I have a key, `C-RET', bound in the minibuffer
completion maps. It performs an action, and the behavior of that
action can change if you give it a prefix arg: `C-u C-RET'. When
you give a prefix arg in this context, I call `minibuffer-message'
to echo `[prefix (4)]' (or whatever current-prefix-arg is).
 
Prior to Emacs 23, a user can hit `C-RET' after `C-u' and while
`[prefix (4)]' is displayed, and the `sit-for' is interrupted and
the action is executed immediately. Starting with Emacs 23, the
`C-RET' is ignored. A `C-RET' doesn't take effect until the
`sit-for' timeout is finished (as if it were `sleep-for').
 
I hope this is enough info for you to find and fix the bug.
I don't have time to try to track this down further.
 

In GNU Emacs 23.1.95.1 (i386-mingw-nt5.1.2600)
 of 2010-04-03 on G41R2F1
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags
-Ic:/imagesupport/include'
 

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 5923 <at> debbugs.gnu.org
Subject: Re: bug#5923: 23.1.95; minibuffer-message discards input events
Date: Sat, 10 Apr 2010 15:15:21 -0400

> Prior to Emacs 23, a user can hit `C-RET' after `C-u' and while
> `[prefix (4)]' is displayed, and the `sit-for' is interrupted and
> the action is executed immediately. Starting with Emacs 23, the
> `C-RET' is ignored. A `C-RET' doesn't take effect until the
> `sit-for' timeout is finished (as if it were `sleep-for').

I can't reproduce exactly your test case because I don't know what code
is run by your C-u (and because I'm on GNU/Linux, ...), but at least
when I start "emacs23 -Q" and do C-x C-f TAB TAB, the first tab outputs
a minibuffer-message but the second TAB is executed immediately
(interrupts the minibuffer-message).  So I don't see that problematic
behavior you're seeing.

Can you check whether my test case works for you as well?


        Stefan

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 5923 <at> debbugs.gnu.org
Subject: RE: bug#5923: 23.1.95; minibuffer-message discards input events
Date: Sat, 10 Apr 2010 12:59:48 -0700

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

> > Prior to Emacs 23, a user can hit `C-RET' after `C-u' and while
> > `[prefix (4)]' is displayed, and the `sit-for' is interrupted and
> > the action is executed immediately. Starting with Emacs 23, the
> > `C-RET' is ignored. A `C-RET' doesn't take effect until the
> > `sit-for' timeout is finished (as if it were `sleep-for').
> 
> I can't reproduce exactly your test case because I don't know 
> what code is run by your C-u (and because I'm on GNU/Linux,
> ...), but at least when I start "emacs23 -Q" and do C-x C-f
> TAB TAB, the first tab outputs a minibuffer-message but the
> second TAB is executed immediately (interrupts the
> minibuffer-message).  So I don't see that problematic
> behavior you're seeing.
> 
> Can you check whether my test case works for you as well?

I confirm that your test case works for me also.
The second tab has its effect - it is not lost.

[However, the minibuffer message remains displayed for the full timeout period.
That seems wrong - why not stop displaying the msg as soon as the tab event
arrives? Unless `Complete but not unique' is perhaps redisplayed by another call
or something?

IOW, after the second tab, *Completions* is shown, indicating that the tab did
take effect, and the message `Complete but not unique' is briefly removed -
replaced by the message `Making completion list...'. But the `Complete but not
unique' message then reappears for the duration of the `minibuffer-message'
timeout. Is this the behavior you see also?

Anyway, this is not the problematic behavior I get with my code, and which this
bug report is about.]


Attached is the code I use for `C-u' in the minibuffer. I hope it helps.

I should have mentioned that the same problem occurs when I use `C-u' in the
minibuffer at any time, not just in the scenario where I follow it by `C-RET'.
IOW, it has nothing to do with the particular user event that follows.

And as I said, in Emacs 22 and before there is no such problem: any user event
immediately interrupts the message display and its timeout, and no such event is
lost (so you don't need to hit the key multiple times).

[bug-5923-emacs.el (application/octet-stream, attachment)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 5923 <at> debbugs.gnu.org
Subject: Re: bug#5923: 23.1.95; minibuffer-message discards input events
Date: Tue, 13 Apr 2010 22:19:05 -0400

> Attached is the code I use for `C-u' in the minibuffer. I hope it helps.

It does.

But to tell you the truth the handling of this-command-keys and
universal-argument prefix is much too delicate for me to understand it,
so I'm not surprised it doesn't work quite right if you mess with it in
any non-trivial way.


        Stefan

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 5923 <at> debbugs.gnu.org
Subject: RE: bug#5923: 23.1.95; minibuffer-message discards input events
Date: Tue, 13 Apr 2010 22:06:10 -0700

> > Attached is the code I use for `C-u' in the minibuffer. I 
> > hope it helps.
> 
> It does.
> 
> But to tell you the truth the handling of this-command-keys and
> universal-argument prefix is much too delicate for me to 
> understand it, so I'm not surprised it doesn't work quite right
> if you mess with it in any non-trivial way.

Compare Emacs 22 (and earlier), where there is no bug.

The code was changed (C to Lisp, at least), and that introduced the regression.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 5923 <at> debbugs.gnu.org
Subject: RE: bug#5923: 23.1.95; minibuffer-message discards input events
Date: Sun, 18 Apr 2010 22:38:51 -0700

> > > Attached is the code I use for `C-u' in the minibuffer. I 
> > > hope it helps.
> > 
> > It does.
> > 
> > But to tell you the truth the handling of this-command-keys and
> > universal-argument prefix is much too delicate for me to 
> > understand it, so I'm not surprised it doesn't work quite right
> > if you mess with it in any non-trivial way.
> 
> Compare Emacs 22 (and earlier), where there is no bug.
> 
> The code was changed (C to Lisp, at least), and that 
> introduced the regression.

Also, the code I use is _identical_ to the original code in simple.el (Emacs 22
version), except that it also calls `minibuffer-message'. Is that really a
"non-trivial" change?

(And in Emacs 23, `last-command-event' is used instead of `last-command-char' -
that is the only difference I can see from the Emacs 22 code.)

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 5923 <at> debbugs.gnu.org
Subject: RE: bug#5923: 23.1.95; minibuffer-message discards input events
Date: Sun, 18 Apr 2010 23:09:31 -0700

> > > > Attached is the code I use for `C-u' in the minibuffer. I 
> > > > hope it helps.
> > > 
> > > It does.
> > > 
> > > But to tell you the truth the handling of this-command-keys and
> > > universal-argument prefix is much too delicate for me to 
> > > understand it, so I'm not surprised it doesn't work quite right
> > > if you mess with it in any non-trivial way.
> > 
> > Compare Emacs 22 (and earlier), where there is no bug.
> > 
> > The code was changed (C to Lisp, at least), and that 
> > introduced the regression.
> 
> Also, the code I use is _identical_ to the original code in 
> simple.el (Emacs 22
> version), except that it also calls `minibuffer-message'. Is 
> that really a
> "non-trivial" change?
> 
> (And in Emacs 23, `last-command-event' is used instead of 
> `last-command-char' - that is the only difference I can see
> from the Emacs 22 code.)

And changing `last-command-char' in the code to `last-command-event', for Emacs
23, does not fix the problem. It seems that the problem was introduced in the
translation from C to Lisp for the vanilla Emacs code for `minibuffer-message'.

Here is enough of the rest of the code I use to let you execute it and reproduce
the bug without doing anything extra:

(defun icicle-remap (old new map &optional oldmap)
  (define-key map (vector 'remap old) new))

(icicle-remap 'universal-argument 'icicle-universal-argument ; `C-u'
              minibuffer-local-completion-map (current-global-map))
(icicle-remap 'negative-argument  'icicle-negative-argument  ; `M--'
              minibuffer-local-completion-map (current-global-map))
(icicle-remap 'digit-argument     'icicle-digit-argument     ; `C-9'
              minibuffer-local-completion-map (current-global-map))

(defvar icicle-minibuffer-message-ok-p t)

Together with the code I sent before, this provides a full test case. It works
in Emacs 22 and doesn't work in Emacs 23.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 5923 <at> debbugs.gnu.org
Subject: RE: bug#5923: 23.1.95; minibuffer-message discards input events
Date: Tue, 20 Apr 2010 09:18:28 -0700

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

The problem appears to be with `sit-for', not with `minibuffer-message'. More
specifically, the call to `input-pending-p' in `sit-for' does not act as it
should. Dunno if `input-pending-p' is the problem generally, or just in this
context.

Attached is a small, simple, self-contained file that reproduces the problem.
Just load it, then `M-x C-u sssss'. The `s' keystrokes are ignored while the
`sit-for' delay is waited for.

In all cases except `icicle-universal-argument', the original command is called,
followed by a call to `message' and then `sit-for'.

`icicle-universal-argument' is identical to `universal-argument' except:

* It too calls `message' followed by `sit-for'.
* It uses `icicle-ensure-overriding-map-is-bound', not
`ensure-overriding-map-is-bound'. The difference is that the former sets
`overriding-terminal-local-map' to `icicle-universal-argument-map', not
`universal-argument-map'.

The difference between those two maps is that the `icicle-*' commands are used
in place of the originals (and each `icicle-*' command calls `message' followed
by `sit-for').

So all of the changes from the vanilla Emacs code amount to the same trivial
change: Add a call to `message' and `sit-for' after the vanilla command behavior
is finished. There are no other changes.

`sit-for' seems to be the problem, but there is no change in the code for
`sit-for' from Emacs 22 and Emacs 23 (where the bug first appears). Perhaps
there is a relevant change elsewhere that has to do with these keymaps or with
input events? 

Debugging `sit-for' a bit indicates that `input-pending-p' does indeed return
nil when it should return non-nil in this context (after user input). The final
`cond' branch is taken in the `sit-for' code, instead of the `input-pending-p'
branch.

There is no change in the C source code for `input-pending-p' itself, between
Emacs 22 and 23. But it tests several global vars in order to do its thing, so
perhaps the bug was introduced by changing the value of one of those vars. The
vars are `unread-command-events', `unread-command-char',
`unread-post-input-method-events', and `unread-input-method-events'. That seems
likely.

Note this in the doc string of `input-pending-p': "Actually, the value is nil
only if we can be ***sure*** that no input is available; if there is a doubt,
the value is t."

Obviously, we are by no means respecting that declared conservative behavior. It
is returning nil (in this case) even when we should not be sure that no input is
available - even when input is in fact available.

I hope this bug will be fixed. Thx.

[bug-5923-emacs-4.el (application/octet-stream, attachment)]

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 5923 <at> debbugs.gnu.org
Subject: RE: bug#5923: 23.1.95; minibuffer-message discards input events
Date: Tue, 20 Apr 2010 16:45:45 -0700

> Debugging `sit-for' a bit indicates that `input-pending-p' 
> does indeed return nil when it should return non-nil in this
> context (after user input). The final `cond' branch is taken
> in the `sit-for' code, instead of the `input-pending-p' branch.

Actually, the problem is here in `sit-for':

(let ((read (read-event nil nil seconds)))
      (or (null read)
	  (progn
	    ;; If last command was a prefix arg, e.g. C-u, push this event onto
	    ;; unread-command-events as (t . EVENT) so it will be added to
	    ;; this-command-keys by read-key-sequence.
	    (if (eq overriding-terminal-local-map universal-argument-map)
		(setq read (cons t read)))
	    (push read unread-command-events)
	    nil))))))

Since the value of `overriding-terminal-local-map' is not
`universal-argument-map' in my case, it fails to treat any input received
properly.

Since this needs to span several commands (digit-argument etc.), I can't just
bind `overriding-terminal-local-map' instead of setting it. I guess my options
are to either set it to my map and later unset it or just redefine `sit-for' so
that it uses a test like this instead:

(if (memq overriding-terminal-local-map
          '(universal-argument-map icicle-universal-argument-map))
    (setq read (cons t read)))

Or redefine `universal-argument-map' to use commands that act differently
depending on the mode etc.

Better suggestions are welcome. None that I've thought of so far are appealing.

How about using a different kind of test in the vanilla code, one that would
give users some flexibility here, instead of hard-coding an eq test against a
specific keymap?

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Drew Adams'" <drew.adams <at> oracle.com>,
	"'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 5923 <at> debbugs.gnu.org
Subject: RE: bug#5923: 23.1.95; minibuffer-message discards input events
Date: Tue, 20 Apr 2010 17:05:26 -0700

> Actually, the problem is here in `sit-for':
>
> (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))))))
> 
> Since the value of `overriding-terminal-local-map' is not
> `universal-argument-map' in my case, it fails to treat any 
> input received properly.

However, something else must be going on also, because the sit-for code is
identical for Emacs 22, and I don't see the bug in Emacs 22.

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 5923 <at> debbugs.gnu.org
Subject: Re: bug#5923: 23.1.95; minibuffer-message discards input events
Date: Sat, 24 Jul 2010 00:26:19 +0200

>> Actually, the problem is here in `sit-for':
>> 
>> (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))))))
>> 
>> Since the value of `overriding-terminal-local-map' is not
>> `universal-argument-map' in my case, it fails to treat any 
>> input received properly.

> However, something else must be going on also, because the sit-for code is
> identical for Emacs 22, and I don't see the bug in Emacs 22.

Thank you for your efforts digging into this bug.  I must say I know
even less than you do about those parts of the code.  It's clearly too
intricate for its own good, but I don't know how to streamline it.


        Stefan

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> IRO.UMontreal.CA>
Cc: 5923 <at> debbugs.gnu.org
Subject: RE: bug#5923: 23.1.95; minibuffer-message discards input events
Date: Wed, 28 Jul 2010 08:24:09 -0700

> >> Actually, the problem is here in `sit-for':
> >> (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))))))
> >> 
> >> Since the value of `overriding-terminal-local-map' is not
> >> `universal-argument-map' in my case, it fails to treat any 
> >> input received properly.
> 
> > However, something else must be going on also, because the 
> > sit-for code is identical for Emacs 22, and I don't see the
> > bug in Emacs 22.
> 
> Thank you for your efforts digging into this bug.  I must say I know
> even less than you do about those parts of the code.  It's clearly too
> intricate for its own good, but I don't know how to streamline it.

Bummer; I'm sorry to hear that, as I had hoped for a fix.

Who wrote the code?  Richard perhaps?
Can't we get someone to understand it and DTRT?

This is after all a regression from Emacs 22.
Can't someone investigate to find out what change
really introduced the regression?

It doesn't seem right that development can break things and then just say that
they can't be fixed because the code is too hard to understand.  I understand
that development of new features and fixing of bugs can sometimes introduce
bugs, including regressions.  But I was hoping this could be fixed (restored).

C-u is a pretty basic part of Emacs.  Seems like this should be fixed before we
worry about adding more bells and whistles to Emacs.

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

From: npostavs <at> users.sourceforge.net
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 5923 <at> debbugs.gnu.org, 'Stefan Monnier' <monnier <at> iro.umontreal.ca>,
 3938 <at> debbugs.gnu.org
Subject: Re: bug#5923: 23.1.95; minibuffer-message discards input events
Date: Tue, 05 Jul 2016 00:06:20 -0400

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

>> Actually, the problem is here in `sit-for':
>>
>> (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))))))
>> 
>> Since the value of `overriding-terminal-local-map' is not
>> `universal-argument-map' in my case, it fails to treat any 
>> input received properly.
>
> However, something else must be going on also, because the sit-for code is
> identical for Emacs 22, and I don't see the bug in Emacs 22.

Is this bug fixed?  The special casing of this in `sit-for' has been
removed meanwhile, but also the overriding-map-is-bound and
universal-argument-other-key have been removed, so it's hard to run the
code examples in current (version 25) Emacs.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: npostavs <at> users.sourceforge.net
Cc: 5923 <at> debbugs.gnu.org, 3938 <at> debbugs.gnu.org
Subject: RE: bug#5923: 23.1.95; minibuffer-message discards input events
Date: Tue, 5 Jul 2016 14:19:28 +0000 (UTC)

> >> Actually, the problem is here in `sit-for':
> >>
> >> (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))))))
> >>
> >> Since the value of `overriding-terminal-local-map' is not
> >> `universal-argument-map' in my case, it fails to treat any
> >> input received properly.
> >
> > However, something else must be going on also, because the sit-for code is
> > identical for Emacs 22, and I don't see the bug in Emacs 22.
> 
> Is this bug fixed?  The special casing of this in `sit-for' has been
> removed meanwhile, but also the overriding-map-is-bound and
> universal-argument-other-key have been removed, so it's hard to run the
> code examples in current (version 25) Emacs.

I don't know if it is fixed, and I don't have the time to dig into
this again.  (What you quoted was by no means the last part of this
bug thread, BTW.)  I would _not_ assume that this bug has been fixed.
I think someone would need to dig into this, to debug it.

I provided a self-contained repro recipe based on the code at
the time, but it is no longer sufficient because variable
`overriding-map-is-bound' no longer exists, and the underlying
code has changed.

You can close the bug, but I'm not confident it has been fixed.

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 5923 <at> debbugs.gnu.org
Subject: Re: bug#5923: 23.1.95; minibuffer-message discards input events
Date: Wed, 6 Jul 2016 09:11:57 -0400

On Tue, Jul 5, 2016 at 10:19 AM, Drew Adams <drew.adams <at> oracle.com> wrote:
> I don't know if it is fixed, and I don't have the time to dig into
> this again.  (What you quoted was by no means the last part of this
> bug thread, BTW.)  I would _not_ assume that this bug has been fixed.
> I think someone would need to dig into this, to debug it.
>
> I provided a self-contained repro recipe based on the code at
> the time, but it is no longer sufficient because variable
> `overriding-map-is-bound' no longer exists, and the underlying
> code has changed.

It looks like the examples are reductions from icicles code. Do you
still have problems with this in icicles? A repro recipe along the
lines of "load icicles-foo.el and icicles-bar.el then M-x C-u <etc
etc>..." would be useful. Otherwise I would propose to close the bug
as unreproducible.

PS Removing bug #3938 from cc list, as it seems to cause duplicated
emails (I hadn't noticed that I had sent my previous message to both
merged bugs, seems to be a misfeature of gnus' ephemeral bug groups)

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 5923 <at> debbugs.gnu.org
Subject: RE: bug#5923: 23.1.95; minibuffer-message discards input events
Date: Wed, 6 Jul 2016 13:59:00 +0000 (UTC)

> > I don't know if it is fixed, and I don't have the time to dig into
> > this again.  (What you quoted was by no means the last part of this
> > bug thread, BTW.)  I would _not_ assume that this bug has been fixed.
> > I think someone would need to dig into this, to debug it.
> >
> > I provided a self-contained repro recipe based on the code at
> > the time, but it is no longer sufficient because variable
> > `overriding-map-is-bound' no longer exists, and the underlying
> > code has changed.
> 
> It looks like the examples are reductions from icicles code. Do you
> still have problems with this in icicles?  A repro recipe along the
> lines of "load icicles-foo.el and icicles-bar.el then M-x C-u <etc
> etc>..." would be useful. Otherwise I would propose to close the bug
> as unreproducible.

The repro example I gave was self-contained.  It had nothing to
do with Icicles, in spite of some of the function names.

And as I said:

> > I don't know if it is fixed, and I don't have the time to dig
> > into this again.

As I said:

> > I would _not_ assume that this bug has been fixed.  I think
> > someone would need to dig into this, to debug it.
> > You can close the bug, but I'm not confident it has been fixed.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 3938 <at> debbugs.gnu.org, 5923 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#3938: bug#5923: 23.1.95;
 minibuffer-message discards input events
Date: Wed, 06 Jul 2016 17:25:03 +0300

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

> Date: Tue, 5 Jul 2016 14:19:28 +0000 (UTC)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 5923 <at> debbugs.gnu.org, 3938 <at> debbugs.gnu.org
> 
> > >> Actually, the problem is here in `sit-for':
> > >>
> > >> (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))))))
> > >>
> > >> Since the value of `overriding-terminal-local-map' is not
> > >> `universal-argument-map' in my case, it fails to treat any
> > >> input received properly.
> > >
> > > However, something else must be going on also, because the sit-for code is
> > > identical for Emacs 22, and I don't see the bug in Emacs 22.
> > 
> > Is this bug fixed?  The special casing of this in `sit-for' has been
> > removed meanwhile, but also the overriding-map-is-bound and
> > universal-argument-other-key have been removed, so it's hard to run the
> > code examples in current (version 25) Emacs.
> 
> I don't know if it is fixed, and I don't have the time to dig into
> this again.  (What you quoted was by no means the last part of this
> bug thread, BTW.)  I would _not_ assume that this bug has been fixed.
> I think someone would need to dig into this, to debug it.

One could hope for a more cooperative response, I think.  It took me
all of 5 minutes, without knowing anything about icicles and very
little about the new implementation of universal-argument, to convert
your test file to the current sources (see the attached).  With it, I
convinced myself that the bug is indeed fixed: typing the first 's'
interrupts the wait immediately, and displays "ssss" in the echo area.

Please verify that my changes to the test file are valid and the bug
is indeed fixed.

Thanks.

[bug-5923-emacs-25.el (application/emacs-lisp, attachment)]

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 5923 <at> debbugs.gnu.org
Subject: Re: bug#5923: 23.1.95; minibuffer-message discards input events
Date: Wed, 6 Jul 2016 10:55:38 -0400

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

tag 5923 + confirmed
found 5923 25.0.95
quit

On Wed, Jul 6, 2016 at 9:59 AM, Drew Adams <drew.adams <at> oracle.com> wrote:
>
> The repro example I gave was self-contained.  It had nothing to
> do with Icicles, in spite of some of the function names.

Ok, had another look, it's actually not so hard to update it for newer
Emacs. Seems the bug is still existing.

emacs -Q -l bug-5923-emacs-25.el
M-x C-u C-f
See that "prefix (4)" is displayed for 2 seconds until
`describe-function' finally gets executed.

[bug-5923-emacs-25.el (text/x-emacs-lisp, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 5923 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#5923: 23.1.95; minibuffer-message discards input events
Date: Wed, 06 Jul 2016 18:05:10 +0300

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Wed, 6 Jul 2016 10:55:38 -0400
> Cc: 5923 <at> debbugs.gnu.org
> 
> Ok, had another look, it's actually not so hard to update it for newer
> Emacs. Seems the bug is still existing.
> 
> emacs -Q -l bug-5923-emacs-25.el
> M-x C-u C-f
> See that "prefix (4)" is displayed for 2 seconds until
> `describe-function' finally gets executed.

And I arrived at the exactly opposite conclusion, see my other
message.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 3938 <at> debbugs.gnu.org, 5923 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: RE: bug#3938: bug#5923: 23.1.95; minibuffer-message discards input
 events
Date: Wed, 6 Jul 2016 15:10:35 +0000 (UTC)

> > > Is this bug fixed?  The special casing of this in `sit-for' has been
> > > removed meanwhile, but also the overriding-map-is-bound and
> > > universal-argument-other-key have been removed, so it's hard to run the
> > > code examples in current (version 25) Emacs.
> >
> > I don't know if it is fixed, and I don't have the time to dig into
> > this again.  (What you quoted was by no means the last part of this
> > bug thread, BTW.)  I would _not_ assume that this bug has been fixed.
> > I think someone would need to dig into this, to debug it.
> 
> One could hope for a more cooperative response, I think. 

Ditto.  Time passes...

> It took me all of 5 minutes, without knowing anything about icicles and very
> little about the new implementation of universal-argument, to convert
> your test file to the current sources (see the attached).  With it, I
> convinced myself that the bug is indeed fixed: typing the first 's'
> interrupts the wait immediately, and displays "ssss" in the echo area.

I had already done similarly, FWIW.  To me it does not constitute a proof
that the bug is fixed.  If it convinces you, fine; close the bug, as I said.

> Please verify that my changes to the test file are valid and the bug
> is indeed fixed.

Sorry, I don't have the time to do that.  And as I said, IMO this
alone doesn't convince me that the bug is fixed.  It might be fixed;
I don't know.  I hope it is.

If you can convince yourself in 5 minutes that it is fixed, great.

The bug (#3938) was filed almost exactly 7 years ago, with a very short
recipe to reproduce, starting from `emacs -Q'.  Likewise, for the merged
bug (#5923) - 6 years ago, with other emacs -Q recipes
(http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5923#23, http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5923#26).

Responses from Stefan at the time:

 But to tell you the truth the handling of this-command-keys and
 universal-argument prefix is much too delicate for me to understand it...

 Thank you for your efforts digging into this bug.  I must say I know
 even less than you do about those parts of the code.  It's clearly too
 intricate for its own good, but I don't know how to streamline it.

That was it.  It died on the vine in 2010.  If it somehow got fixed
accidentally in the interim, great.

"One could _hope_ for a more cooperative response, I think."
But all's well that ends well.  (Assuming it is ended, and well.)

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 5923 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#5923: 23.1.95; minibuffer-message discards input events
Date: Wed, 6 Jul 2016 11:30:16 -0400

tag 5923 - confirmed
notfound 5932 25.0.95
fixed 5932
quit

On Wed, Jul 6, 2016 at 11:05 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
>> Date: Wed, 6 Jul 2016 10:55:38 -0400
>> Cc: 5923 <at> debbugs.gnu.org
>>
>> Ok, had another look, it's actually not so hard to update it for newer
>> Emacs. Seems the bug is still existing.
>>
>> emacs -Q -l bug-5923-emacs-25.el
>> M-x C-u C-f
>> See that "prefix (4)" is displayed for 2 seconds until
>> `describe-function' finally gets executed.
>
> And I arrived at the exactly opposite conclusion, see my other
> message.

Yes, your version works. Probably I made a mistake in my updates,
tentatively marking bug as fixed.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 5923 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#3938: bug#5923: 23.1.95; minibuffer-message discards input
 events
Date: Wed, 06 Jul 2016 18:32:03 +0300

> Date: Wed, 6 Jul 2016 15:10:35 +0000 (UTC)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: npostavs <at> users.sourceforge.net, 5923 <at> debbugs.gnu.org, 3938 <at> debbugs.gnu.org
> 
> > It took me all of 5 minutes, without knowing anything about icicles and very
> > little about the new implementation of universal-argument, to convert
> > your test file to the current sources (see the attached).  With it, I
> > convinced myself that the bug is indeed fixed: typing the first 's'
> > interrupts the wait immediately, and displays "ssss" in the echo area.
> 
> I had already done similarly, FWIW.  To me it does not constitute a proof
> that the bug is fixed.

??? Are you saying that the recipe doesn't exhibit the bug?  If it
does, and now the recipe behaves correctly, what else could be there
that prevents us from concluding the bug is fixed?

> If you can convince yourself in 5 minutes that it is fixed, great.

The behavior which was incorrect when you reported it, is correct
now.  What else do we need to examine?

I will close the bug, unless Noam convinces me that my testing is
incorrect, while his is.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 5923 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#5923: 23.1.95; minibuffer-message discards input events
Date: Wed, 06 Jul 2016 18:38:12 +0300

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Wed, 6 Jul 2016 11:30:16 -0400
> Cc: Drew Adams <drew.adams <at> oracle.com>, 5923 <at> debbugs.gnu.org
> 
> >> emacs -Q -l bug-5923-emacs-25.el
> >> M-x C-u C-f
> >> See that "prefix (4)" is displayed for 2 seconds until
> >> `describe-function' finally gets executed.
> >
> > And I arrived at the exactly opposite conclusion, see my other
> > message.
> 
> Yes, your version works. Probably I made a mistake in my updates,
> tentatively marking bug as fixed.

Thanks.  I think, given Drew's response, we can close this bug.

Previous Next

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