Subject: RE: bug#3938: 23.0.96; regression: minibuffer-message interferes with C-u

From: "Drew Adams" <[email-masked]>
Date: Tue, 28 Jul 2009 23:54:13 -0700

> > Actually, I already had the call to `minibuffer-message' last, in my
> > own code.
> >
> > ... we use an exact copy of `universal-argument-map' instead of
> > `universal-argument-map' itself. That's the only change from vanilla
> > Emacs (the definition of `my-ensure-overriding-map-is-bound' just
> > reflects the vanilla definition).
> >
> > Same instructions as before: M-x C-u C-f, hitting C-f right 
> > after C-u (no delay) vs waiting until the 2-sec delay for
> > `minibuffer-message' has elapsed.
> 
> If you want to hack universal-argument this way, you need to hack
> sit-for as well: replace the last few lines of sit-for with
> 
>       (if (eq overriding-terminal-local-map my-universal-argument-map)
>           (setq read (cons t read)))
>       (push read unread-command-events)
>       nil))))))

I see. I will look into such a workaround when I get some time. However:

1. That kind of thing should not be necessary. Something has become overly
fragile or things have become overly coupled.

I'm not "hacking universal-argument this way" or in any way - I don't redefine
it. I just use a different binding for `C-u' and a different keymap from
`universal-argument-map'. (In the bug report I show that even an exact copy of
that map demonstrates the bug, but in my real code I do use a slightly different
map.)

All my code does is change the behavior of `C-u' during completion very
slightly, so that the prefix arg is echoed in the minibuffer using
`minibuffer-message'. IOW, instead of echoing "FOO" as in the bug report, it
shows the prefix arg. In Icicles, you can perform lots of operations during
completion, and you can use `C-u' with those operations.

That's true for vanilla Emacs too, but it's not as often that users use `C-u'
when editing minibuffer text. Because `C-u' is used more during completion,
Icicles shows the prefix value.

2. As I mentioned, the code for `sit-for' has not changed a bit between Emacs 22
and 23 (and my code works in Emacs 22-21-20). Something else must have changed.
There should be no need to replace any of the `sit-for' code. This should not be
happening. There should be no need for such jumping through hoops and redefining
multiple things.

I appreciate the workaround advice, and I'll look into it as a temporary Emacs
23 workaround. But how about fixing this regression? Interrupting `sit-for' with
user input should never cause the full `sit-for' delay to be waited out -
something is amiss. `sit-for' is not `sleep-for'.