Re: Strange use of (run-with-timer 0 nil #'foo args) in do-after-load-evaluation

[Juri Linkov <juri@linkov.net>]

>> An asynchronous message doesn't hide the minibuffer.  It's displayed
>> at the end of the minibuffer text.
>
> The original bug report was about:
>
> (progn
>   (run-at-time 2 nil (lambda () (message "foo")))
>   (y-or-n-p "Yes? "))
>
> But this seems to have the same problem?
>
> (progn
>   (run-at-time 2 nil (lambda () (message "foo")))
>   (read-from-minibuffer "Yes? "))
>
> When I eval that, "foo" completely hides the prompt -- it's not appended
> or reasserted.

'message' can be easily replaced with 'minibuffer-message',
then it doesn't obscure the minibuffer:

(progn
  (run-at-time 2 nil (lambda () (minibuffer-message "foo")))
  (read-from-minibuffer "Yes? "))

Whereas it obscures the prompt in y-or-n-p:

(progn
  (run-at-time 2 nil (lambda () (minibuffer-message "foo")))
  (y-or-n-p "Yes? "))

>>> I think having a history for y-or-n-p doesn't sound very useful?
>>> Hitting `M-p' doesn't to get to the previous answer just sounds
>>> confusing to me.
>>
>> Please try the example I sent earlier.  It feels quite naturally
>> typing 'M-p RET' to repeat a previous y/n answer.
>
> I played with it a bit, and I'm not very enthusiastic about that.  Like
> Stefan K says, it seems error-prone, and I think it would just create
> frustration.  And it's a bigger change in the interface than it first
> sounds like -- people may be used to hitting <up> as a way to reassert
> the prompt, for instance.

In case of doubt, we could add a new function read-y-or-n-p,
not to replace the implementation of the existing y-or-n-p.

Then like many users already put in init files:

  (fset 'yes-or-no-p 'y-or-n-p)

it will be possible to put:

  (fset 'yes-or-no-p 'read-y-or-n-p)
  (fset 'y-or-n-p 'read-y-or-n-p)

And when it will prove to work better than the current y-or-n-p,
maybe after the next release the implementation of y-or-n-p
could be switched to read-y-or-n-p later.