bug#13649: boobytrapped dired-do-async-shell-command question

bug#13649: boobytrapped dired-do-async-shell-command question

[jidanni]

& runs the command dired-do-async-shell-command, which is an
interactive autoloaded compiled Lisp function in `dired-aux.el'.

It sometimes will ask
A command is running in the default buffer.  Use a new buffer? (yes or no)

Which is a boobytrapped question, as picking "no" will always end up in failure...

So perhaps rewrite it so one knows there is only one good choice if one
wants to proceed...

bug#13649: boobytrapped dired-do-async-shell-command question

[Stefan Monnier]

> & runs the command dired-do-async-shell-command, which is an
> interactive autoloaded compiled Lisp function in `dired-aux.el'.

> It sometimes will ask
> A command is running in the default buffer.  Use a new buffer? (yes or no)

> Which is a boobytrapped question, as picking "no" will always end up
> in failure...

> So perhaps rewrite it so one knows there is only one good choice if one
> wants to proceed...

Maybe a better fix is to add a message afterwards, along the lines of
"Haha!  Gotcha!"


        Stefan

bug#13649: boobytrapped dired-do-async-shell-command question

[jidanni]

>>>>> "SM" == Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

SM> Maybe a better fix is to add a message afterwards, along the lines of
SM> "Haha!  Gotcha!"

Or play them the Step Off video
http://www.youtube.com/watch?v=-_g7CZJMnJA&list=PL3A8BC534123C8364

bug#13649: boobytrapped dired-do-async-shell-command question

[Juri Linkov]

> A command is running in the default buffer.  Use a new buffer? (yes or no)
>
> Which is a boobytrapped question, as picking "no" will always end up in failure...

Ah, to you "no" means "don't use a new buffer"?  Yes, this is too ambiguous.
A better question would be:

  A command is running in the default buffer.  Run in a new buffer? (yes or no)

77 characters long, but I have no idea how to make it shorter
without much loss of meaning.

bug#13649: boobytrapped dired-do-async-shell-command question

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Fri, 08 Feb 2013 10:25:01 +0200
> Cc: 13649@debbugs.gnu.org
> 
> > A command is running in the default buffer.  Use a new buffer? (yes or no)
> >
> > Which is a boobytrapped question, as picking "no" will always end up in failure...
> 
> Ah, to you "no" means "don't use a new buffer"?  Yes, this is too ambiguous.
> A better question would be:
> 
>   A command is running in the default buffer.  Run in a new buffer? (yes or no)

Still not clear, IMO (what "default buffer"? run what?).  How about

  Shell output buffer is used by another command; run this command in a new buffer (yes or no)?

> 77 characters long, but I have no idea how to make it shorter
> without much loss of meaning.

I think we should try making it crystal clear and not worry too much
about its length.  The minibuffer is perfectly capable of displaying
multi-line prompts.

bug#13649: boobytrapped dired-do-async-shell-command question

[Stefan Monnier]

>> A command is running in the default buffer.  Use a new buffer? (yes or no)
>> Which is a boobytrapped question, as picking "no" will always end up
>> in failure...
> Ah, to you "no" means "don't use a new buffer"?  Yes, this is too ambiguous.
> A better question would be:

>   A command is running in the default buffer.  Run in a new buffer?
>     (yes or no)

I think it's got the same problem.  I think the question should be more
something like:

  A command is running in the default buffer.  Kill it or use a new buffer?

with C-g being the answer for "don't use a new buffer and don't kill it".


        Stefan

bug#13649: boobytrapped dired-do-async-shell-command question

[Stefan Monnier]

> The minibuffer is perfectly capable of displaying multi-line prompts.

Not mine, because it doesn't know how to grow a minibuffer-only frame.


        Stefan

bug#13649: boobytrapped dired-do-async-shell-command question

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Juri Linkov <juri@jurta.org>,  13649@debbugs.gnu.org,  jidanni@jidanni.org
> Date: Fri, 08 Feb 2013 11:03:23 -0500
> 
> > The minibuffer is perfectly capable of displaying multi-line prompts.
> 
> Not mine, because it doesn't know how to grow a minibuffer-only frame.

I doubt that your minibuffer-only frames are only 1 line high.  It's
not like I suggested a 10,000-character prompt or something.

bug#13649: boobytrapped dired-do-async-shell-command question

[Drew Adams]

> > The minibuffer is perfectly capable of displaying 
> > multi-line prompts.
> 
> Not mine, because it doesn't know how to grow a minibuffer-only frame.

I assume that your point is not to assume that users have a minibuffer that can
grow.

But just in case you are also interested in growing a standalone minibuffer, see
`1on1-fit-minibuffer' here:
http://www.emacswiki.org/emacs-en/download/oneonone.el

I add it to `post-command-hook':
(if (and 1on1-fit-minibuffer-frame-flag (require 'fit-frame nil t))
    (add-hook 'post-command-hook '1on1-fit-minibuffer-frame)
  (remove-hook 'post-command-hook '1on1-fit-minibuffer-frame))

bug#13649: boobytrapped dired-do-async-shell-command question

[Stefan Monnier]

> I doubt that your minibuffer-only frames are only 1 line high.

And yet, they are.

> It's not like I suggested a 10,000-character prompt or something.

But indeed, they're longer than 80 columns (they're 250 columns long,
tho most of it is off the screen, actually displayed is probably closer
to 160).


        Stefan

bug#13649: boobytrapped dired-do-async-shell-command question

[Drew Adams]

> > I doubt that your minibuffer-only frames are only 1 line high.
> 
> And yet, they are.
> 
> > It's not like I suggested a 10,000-character prompt or something.
> 
> But indeed, they're longer than 80 columns (they're 250 columns long,
> tho most of it is off the screen, actually displayed is 
> probably closer to 160).

FWIW, by default the minibuffer frame in oneonone.el is 100% of the display
width and is 2 chars high.  For me, with a `frame-char-width' of 8, that's 160
chars wide.

160 * 2 = 320, which is not very different from Stefan's 250.

bug#13649: boobytrapped dired-do-async-shell-command question

[Juri Linkov]

>> > A command is running in the default buffer.  Use a new buffer? (yes or no)
>> >
>> > Which is a boobytrapped question, as picking "no" will always end up in failure...
>>
>> Ah, to you "no" means "don't use a new buffer"?  Yes, this is too ambiguous.
>> A better question would be:
>>
>>   A command is running in the default buffer.  Run in a new buffer? (yes or no)
>
> Still not clear, IMO (what "default buffer"? run what?).  How about
>
>   Shell output buffer is used by another command; run this command in a new buffer (yes or no)?

I'd rather make the prompt short and add a "help" option
(e.g. "yes/no/help" or "y/n/h") that will display the full
explanation of all options with a link to their customization.

bug#13649: boobytrapped dired-do-async-shell-command question

[Juri Linkov]

>>> A command is running in the default buffer.  Use a new buffer? (yes or no)
>>> Which is a boobytrapped question, as picking "no" will always end up
>>> in failure...
>> Ah, to you "no" means "don't use a new buffer"?  Yes, this is too ambiguous.
>> A better question would be:
>
>>   A command is running in the default buffer.  Run in a new buffer?
>>     (yes or no)
>
> I think it's got the same problem.  I think the question should be more
> something like:
>
>   A command is running in the default buffer.  Kill it or use a new buffer?
>
> with C-g being the answer for "don't use a new buffer and don't kill it".

Alas, this means there is no more "yes/no" question.  Of course,
it could be split to two "yes/no" questions like `find-alternate-file'
used to do until the recent changes that now asks only one question
(yes-or-no-p "Kill and replace the buffer without saving it? ")
I see no way to do the same for the async-shell-command default question.

There is a separate option in `async-shell-command' that asks that question
"A command is running in the default buffer.  Kill it? ".  If is also
possible to combine all other options into one question like:

  A command is running in the default buffer.  What to do? (k/c/r/h)

where the key `k' would mean to kill the running process, `c' - create
a new buffer, `r' - rename the buffer with the running process, and
`h' - help with the explanation of these options.

bug#13649: boobytrapped dired-do-async-shell-command question

[Stefan Monnier]

>   A command is running in the default buffer.  What to do? (k/c/r/h)

> where the key `k' would mean to kill the running process, `c' - create
> a new buffer, `r' - rename the buffer with the running process, and
> `h' - help with the explanation of these options.

BTW, one more useful option would be "run it when the current command
finishes".


        Stefan

bug#13649: boobytrapped dired-do-async-shell-command question

[jidanni]

>>>>> "SM" == Stefan Monnier <monnier@iro.umontreal.ca> writes:
SM>   A command is running in the default buffer.  Kill it or use a new buffer?

SM> with C-g being the answer for "don't use a new buffer and don't kill it".
OK but mention that third C-g option there too.

bug#13649: boobytrapped dired-do-async-shell-command question

[Eli Zaretskii]

> >   Shell output buffer is used by another command; run this command in a new buffer (yes or no)?
> 
> I'd rather make the prompt short and add a "help" option
> (e.g. "yes/no/help" or "y/n/h") that will display the full
> explanation of all options with a link to their customization.

That's a wrong way to treat this kind of problems, in my experience.
People need clear description of the problem because they more often
than not are nervous to be bugged with a question to begin with; the
assumption they will want to look up some help is false.

bug#13649: boobytrapped dired-do-async-shell-command question

[Juri Linkov]

>>   A command is running in the default buffer.  What to do? (k/c/r/h)

Or rather to model the prompt after `save-some-buffers-action-alist'
that asks "Save file? (y, n, !, ., q, C-r, d or C-h)" and ask:

  A command is running.  Kill it? (y, n, c, r, or C-h)

where the key `y' would mean to kill the running process, `c' - create
a new buffer, `r' - rename the buffer with the running process, and
`C-h' - help with the explanation of these options including `C-g':

  C-g to quit (cancel the whole command);

> BTW, one more useful option would be "run it when the current command
> finishes".

IIUC, this will require adding a queue of postponed commands, and also UI
to handle them (e.g. to remove a submitted command from the queue, etc.)

bug#13649: boobytrapped dired-do-async-shell-command question

[jidanni]

You guys are forgetting what the user really wants in the first place.
All he wants to do is do another
$ some_command &
as in the shell.
He is used to doing lots of these without regard if the previous one has
finished yet or not... else what fun would asynchronous be?

Therefore the wisest thing would be to automatically create
*Async Output of bla gla* (or no word Async)
*Async Output of moo goo*
*Async Output of bla gla<2>*
for him, without bothering him with questions.

bug#13649: boobytrapped dired-do-async-shell-command question

[Juri Linkov]

> You guys are forgetting what the user really wants in the first place.
> All he wants to do is do another
> $ some_command &
> as in the shell.
> He is used to doing lots of these without regard if the previous one has
> finished yet or not... else what fun would asynchronous be?
>
> Therefore the wisest thing would be to automatically create
> *Async Output of bla gla* (or no word Async)
> *Async Output of moo goo*
> *Async Output of bla gla<2>*
> for him, without bothering him with questions.

You can customize `async-shell-command-buffer' to `new-buffer'
(labeled "Create a new buffer") that creates new buffers
automatically without questions.

bug#13649: boobytrapped dired-do-async-shell-command question

[jidanni]

JL> You can customize `async-shell-command-buffer' to `new-buffer'
Ahhh! If only I ever knew! OK.

But I see if just adds a <2>, it really should also give a hint about
what was run in the buffer name.

bug#13649: boobytrapped dired-do-async-shell-command question

[Juri Linkov]

> JL> You can customize `async-shell-command-buffer' to `new-buffer'
> Ahhh! If only I ever knew! OK.
>
> But I see if just adds a <2>, it really should also give a hint about
> what was run in the buffer name.

To see what was run in the buffer name is possible with `M-x list-processes'.

bug#13649: boobytrapped dired-do-async-shell-command question

[jidanni]

>>>>> "JL" == Juri Linkov <juri@jurta.org> writes:
JL> To see what was run in the buffer name is possible with `M-x list-processes'.
But ah ha ha ... only if the process is still running!

bug#13649: boobytrapped dired-do-async-shell-command question

[Stefan Monnier]

>> BTW, one more useful option would be "run it when the current command
>> finishes".
> IIUC, this will require adding a queue of postponed commands,

You could just add-function on the process-sentinel.
But as pointed out elsewhere, another option is to actually let both
processes run in the same buffer.


        Stefan

bug#13649: boobytrapped dired-do-async-shell-command question

[Juri Linkov]

>>>>>> "JL" == Juri Linkov <juri@jurta.org> writes:
> JL> To see what was run in the buffer name is possible with `M-x list-processes'.
> But ah ha ha ... only if the process is still running!

The async process buffer could have a header/footer like in compilation:

-*- mode: shell; default-directory: "~/" -*-
Async Shell Command started at Mon Feb 11 11:15:45

command line
output
output
output

Async Shell Command finished at Mon Feb 11 11:15:48

bug#13649: boobytrapped dired-do-async-shell-command question

[Lars Ingebrigtsen]

jidanni@jidanni.org writes:

> It sometimes will ask
> A command is running in the default buffer.  Use a new buffer? (yes or no)
>
> Which is a boobytrapped question, as picking "no" will always end up
> in failure...

I've now added help (on `C-h') on these prompts, which should hopefully
help people figure this out better.  Because I don't think there's any
way to explain it on one single prompt line.

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

bug#13649: boobytrapped dired-do-async-shell-command question

[Juri Linkov]

> I've now added help (on `C-h') on these prompts, which should hopefully
> help people figure this out better.  Because I don't think there's any
> way to explain it on one single prompt line.

I see that you added help using `help-form'.  Is it displayed only
when yes-or-no-p is customized to use short answers with y-or-n-p?
So by default users won't see help?

bug#13649: boobytrapped dired-do-async-shell-command question

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> I see that you added help using `help-form'.  Is it displayed only
> when yes-or-no-p is customized to use short answers with y-or-n-p?
> So by default users won't see help?

I thought help-form was used when doing short answers, too?  But I
haven't checked -- if not, I think that's a bug.

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

bug#13649: boobytrapped dired-do-async-shell-command question

[Juri Linkov]

>> I see that you added help using `help-form'.  Is it displayed only
>> when yes-or-no-p is customized to use short answers with y-or-n-p?
>> So by default users won't see help?
>
> I thought help-form was used when doing short answers, too?  But I
> haven't checked -- if not, I think that's a bug.

help-form is used only with short answers by y-or-n-p.
Maybe yes-or-no-p should support help-form as well?
For example, by allowing to type "help":

  Use a new buffer? (yes, no or help)

bug#13649: boobytrapped dired-do-async-shell-command question

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> help-form is used only with short answers by y-or-n-p.

Oh, right -- I was confused by having a function alias here...

> Maybe yes-or-no-p should support help-form as well?
> For example, by allowing to type "help":
>
>   Use a new buffer? (yes, no or help)

I think `C-h' would be fine here, too.

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

bug#13649: boobytrapped dired-do-async-shell-command question

[Juri Linkov]

>> Maybe yes-or-no-p should support help-form as well?
>> For example, by allowing to type "help":
>>
>>   Use a new buffer? (yes, no or help)
>
> I think `C-h' would be fine here, too.

Typing C-h in the minibuffer is useful for other things,
e.g. to see available keybindings with `C-h b', `C-h m'.
Maybe then `?' would be appropriate as a short key?

bug#13649: boobytrapped dired-do-async-shell-command question

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> I think `C-h' would be fine here, too.
>
> Typing C-h in the minibuffer is useful for other things,
> e.g. to see available keybindings with `C-h b', `C-h m'.
> Maybe then `?' would be appropriate as a short key?

It hadn't occurred to me that somebody would want to say `C-h b' in a
yes-or-no-prompt, but I guess it's possible?  On the other hand, I think
there's an advantage to having the same help key in both y-or-n-p and
yes-or-no-p.

Anybody have any opinions?

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

bug#13649: boobytrapped dired-do-async-shell-command question

[Juri Linkov]

>> Typing C-h in the minibuffer is useful for other things,
>> e.g. to see available keybindings with `C-h b', `C-h m'.
>> Maybe then `?' would be appropriate as a short key?
>
> It hadn't occurred to me that somebody would want to say `C-h b' in a
> yes-or-no-prompt, but I guess it's possible?  On the other hand, I think
> there's an advantage to having the same help key in both y-or-n-p and
> yes-or-no-p.

Actually, `C-h' is useful in `y-or-n-p' as well for the same reasons.
For example, `C-h b' in a `y-or-n-p' prompt shows:

  Key             Binding
  y               act
  n               skip
  C-l             recenter
  ...

BTW, (info "(emacs) Yes or No Prompts") says:

     With both types of yes-or-no query the minibuffer behaves as
  described in the previous sections; you can recenter the selected window
  with ‘C-l’, scroll that window (‘C-v’ or ‘PageDown’ scrolls forward,
  ‘M-v’ or ‘PageUp’ scrolls backward)

But in fact ‘C-l’ doesn't scroll the window, ‘C-v’ and ‘PageDown’ don't
scroll forward, and ‘M-v’ and ‘PageUp’ don't scroll backward.  Should they?

bug#13649: boobytrapped dired-do-async-shell-command question

[Eli Zaretskii]

> Cc: 13649@debbugs.gnu.org, jidanni@jidanni.org
> From: Juri Linkov <juri@linkov.net>
> Date: Sun, 08 May 2022 20:49:19 +0300
> 
> BTW, (info "(emacs) Yes or No Prompts") says:
> 
>      With both types of yes-or-no query the minibuffer behaves as
>   described in the previous sections; you can recenter the selected window
>   with ‘C-l’, scroll that window (‘C-v’ or ‘PageDown’ scrolls forward,
>   ‘M-v’ or ‘PageUp’ scrolls backward)
> 
> But in fact ‘C-l’ doesn't scroll the window, ‘C-v’ and ‘PageDown’ don't
> scroll forward, and ‘M-v’ and ‘PageUp’ don't scroll backward.  Should they?

They do here.  What did you try, exactly?

bug#13649: boobytrapped dired-do-async-shell-command question

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Actually, `C-h' is useful in `y-or-n-p' as well for the same reasons.
> For example, `C-h b' in a `y-or-n-p' prompt shows:
>
>   Key             Binding
>   y               act
>   n               skip
>   C-l             recenter
>   ...

Hm...  Here it brings up the help-for-help?  Which doesn't seem right at
all.

> BTW, (info "(emacs) Yes or No Prompts") says:
>
>      With both types of yes-or-no query the minibuffer behaves as
>   described in the previous sections; you can recenter the selected window
>   with ‘C-l’, scroll that window (‘C-v’ or ‘PageDown’ scrolls forward,
>   ‘M-v’ or ‘PageUp’ scrolls backward)
>
> But in fact ‘C-l’ doesn't scroll the window, ‘C-v’ and ‘PageDown’ don't
> scroll forward, and ‘M-v’ and ‘PageUp’ don't scroll backward.  Should they?

Yeah, all those commands just work on the minibuffer here with
yes-or-no-p, which seems like a bug (probably).

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

bug#13649: boobytrapped dired-do-async-shell-command question

[Lars Ingebrigtsen]

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> Actually, `C-h' is useful in `y-or-n-p' as well for the same reasons.
>> For example, `C-h b' in a `y-or-n-p' prompt shows:
>>
>>   Key             Binding
>>   y               act
>>   n               skip
>>   C-l             recenter
>>   ...
>
> Hm...  Here it brings up the help-for-help?  Which doesn't seem right at
> all.

With "it" I mean just `C-h'.  But `C-h b' does bring up:


[-- Attachment #2: Type: image/png, Size: 122607 bytes --]

[-- Attachment #3: Type: text/plain, Size: 106 bytes --]




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

bug#13649: boobytrapped dired-do-async-shell-command question

[Juri Linkov]

>> BTW, (info "(emacs) Yes or No Prompts") says:
>>
>>      With both types of yes-or-no query the minibuffer behaves as
>>   described in the previous sections; you can recenter the selected window
>>   with ‘C-l’, scroll that window (‘C-v’ or ‘PageDown’ scrolls forward,
>>   ‘M-v’ or ‘PageUp’ scrolls backward)
>>
>> But in fact ‘C-l’ doesn't scroll the window, ‘C-v’ and ‘PageDown’ don't
>> scroll forward, and ‘M-v’ and ‘PageUp’ don't scroll backward.  Should they?
>
> They do here.  What did you try, exactly?

They do to some extent for y-or-n-p, but not at all for yes-or-no.

bug#13649: boobytrapped dired-do-async-shell-command question

[Juri Linkov]

>> Actually, `C-h' is useful in `y-or-n-p' as well for the same reasons.
>> For example, `C-h b' in a `y-or-n-p' prompt shows:
>>
>>   Key             Binding
>>   y               act
>>   n               skip
>>   C-l             recenter
>>   ...
>
> Hm...  Here it brings up the help-for-help?  Which doesn't seem right at
> all.

Strange, I see the same that `C-h' brings up the help-for-help,
but then typing also `b' brings up keybindings.

>> BTW, (info "(emacs) Yes or No Prompts") says:
>>
>>      With both types of yes-or-no query the minibuffer behaves as
>>   described in the previous sections; you can recenter the selected window
>>   with ‘C-l’, scroll that window (‘C-v’ or ‘PageDown’ scrolls forward,
>>   ‘M-v’ or ‘PageUp’ scrolls backward)
>>
>> But in fact ‘C-l’ doesn't scroll the window, ‘C-v’ and ‘PageDown’ don't
>> scroll forward, and ‘M-v’ and ‘PageUp’ don't scroll backward.  Should they?
>
> Yeah, all those commands just work on the minibuffer here with
> yes-or-no-p, which seems like a bug (probably).

y-or-n-p has special handling for these keys:

    (define-key map [remap recenter] #'minibuffer-recenter-top-bottom)
    (define-key map [remap scroll-up] #'minibuffer-scroll-up-command)
    (define-key map [remap scroll-down] #'minibuffer-scroll-down-command)
    (define-key map [remap scroll-other-window] #'minibuffer-scroll-other-window)
    (define-key map [remap scroll-other-window-down] #'minibuffer-scroll-other-window-down)

but yes-or-no-p doesn't.

bug#13649: boobytrapped dired-do-async-shell-command question

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: larsi@gnus.org,  13649@debbugs.gnu.org,  jidanni@jidanni.org
> Date: Mon, 09 May 2022 21:42:40 +0300
> 
> >> BTW, (info "(emacs) Yes or No Prompts") says:
> >>
> >>      With both types of yes-or-no query the minibuffer behaves as
> >>   described in the previous sections; you can recenter the selected window
> >>   with ‘C-l’, scroll that window (‘C-v’ or ‘PageDown’ scrolls forward,
> >>   ‘M-v’ or ‘PageUp’ scrolls backward)
> >>
> >> But in fact ‘C-l’ doesn't scroll the window, ‘C-v’ and ‘PageDown’ don't
> >> scroll forward, and ‘M-v’ and ‘PageUp’ don't scroll backward.  Should they?
> >
> > They do here.  What did you try, exactly?
> 
> They do to some extent for y-or-n-p, but not at all for yes-or-no.

I actually tested with yes-or-no-p.

Again, would you tell what you tried and what happened, as opposed to
what you expected to happen?  I think there might be a
misunderstanding here.

bug#13649: boobytrapped dired-do-async-shell-command question

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> y-or-n-p has special handling for these keys:
>
>     (define-key map [remap recenter] #'minibuffer-recenter-top-bottom)
>     (define-key map [remap scroll-up] #'minibuffer-scroll-up-command)
>     (define-key map [remap scroll-down] #'minibuffer-scroll-down-command)
>     (define-key map [remap scroll-other-window]
> #'minibuffer-scroll-other-window)
>     (define-key map [remap scroll-other-window-down]
> #'minibuffer-scroll-other-window-down)
>
> but yes-or-no-p doesn't.

I guess it should do that, too.

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

bug#13649: boobytrapped dired-do-async-shell-command question

[Juri Linkov]

>> >> BTW, (info "(emacs) Yes or No Prompts") says:
>> >>
>> >>      With both types of yes-or-no query the minibuffer behaves as
>> >>   described in the previous sections; you can recenter the selected window
>> >>   with ‘C-l’, scroll that window (‘C-v’ or ‘PageDown’ scrolls forward,
>> >>   ‘M-v’ or ‘PageUp’ scrolls backward)
>> >>
>> >> But in fact ‘C-l’ doesn't scroll the window, ‘C-v’ and ‘PageDown’ don't
>> >> scroll forward, and ‘M-v’ and ‘PageUp’ don't scroll backward.  Should they?
>> >
>> > They do here.  What did you try, exactly?
>>
>> They do to some extent for y-or-n-p, but not at all for yes-or-no.
>
> I actually tested with yes-or-no-p.
>
> Again, would you tell what you tried and what happened, as opposed to
> what you expected to happen?  I think there might be a
> misunderstanding here.

Two examples from (info "(emacs) Yes or No Prompts"):

  (y-or-n-p "File ‘foo.el’ exists; overwrite?")

‘C-l’, ‘C-v’, ‘M-v’ work fine and scroll the original buffer.

But yes-or-no-p (BTW, it requires the space char at the end of the prompt):

  (yes-or-no-p "Buffer foo.el modified; kill anyway? ")

‘C-l’, ‘C-v’, ‘M-v’ don't scroll the original buffer.

bug#13649: boobytrapped dired-do-async-shell-command question

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: larsi@gnus.org,  13649@debbugs.gnu.org,  jidanni@jidanni.org
> Date: Wed, 11 May 2022 10:17:31 +0300
> 
>   (y-or-n-p "File ‘foo.el’ exists; overwrite?")
> 
> ‘C-l’, ‘C-v’, ‘M-v’ work fine and scroll the original buffer.
> 
> But yes-or-no-p (BTW, it requires the space char at the end of the prompt):
> 
>   (yes-or-no-p "Buffer foo.el modified; kill anyway? ")
> 
> ‘C-l’, ‘C-v’, ‘M-v’ don't scroll the original buffer.

Isn't that expected?  y-or-n-p doesn't need to allow you to edit the
text in the minibuffer.

bug#13649: boobytrapped dired-do-async-shell-command question

[Juri Linkov]

>> y-or-n-p has special handling for these keys:
>>
>>     (define-key map [remap recenter] #'minibuffer-recenter-top-bottom)
>>     (define-key map [remap scroll-up] #'minibuffer-scroll-up-command)
>>     (define-key map [remap scroll-down] #'minibuffer-scroll-down-command)
>>     (define-key map [remap scroll-other-window]
>> #'minibuffer-scroll-other-window)
>>     (define-key map [remap scroll-other-window-down]
>> #'minibuffer-scroll-other-window-down)
>>
>> but yes-or-no-p doesn't.
>
> I guess it should do that, too.

Unfortunately, yes-or-no-p is implemented in C.  But maybe there are
not too many changes required, and it would be enough to add a new keymap
to this call:

      ans = Fdowncase (Fread_from_minibuffer (prompt, Qnil, Qnil, Qnil,
					      Qyes_or_no_p_history, Qnil,
					      Qnil));

bug#13649: boobytrapped dired-do-async-shell-command question

[Juri Linkov]

>>   (y-or-n-p "File ‘foo.el’ exists; overwrite?")
>> 
>> ‘C-l’, ‘C-v’, ‘M-v’ work fine and scroll the original buffer.
>> 
>> But yes-or-no-p (BTW, it requires the space char at the end of the prompt):
>> 
>>   (yes-or-no-p "Buffer foo.el modified; kill anyway? ")
>> 
>> ‘C-l’, ‘C-v’, ‘M-v’ don't scroll the original buffer.
>
> Isn't that expected?  y-or-n-p doesn't need to allow you to edit the
> text in the minibuffer.

Maybe this difference is unimportant.  But still remains the need
to find a key to show help text from yes-or-no-p.  y-or-n-p now
uses C-h to show help, but in yes-or-no-p C-h is useful as
a help key prefix.

bug#13649: boobytrapped dired-do-async-shell-command question

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: larsi@gnus.org,  13649@debbugs.gnu.org,  jidanni@jidanni.org
> Date: Wed, 11 May 2022 20:06:00 +0300
> 
> >> ‘C-l’, ‘C-v’, ‘M-v’ don't scroll the original buffer.
> >
> > Isn't that expected?  y-or-n-p doesn't need to allow you to edit the
> > text in the minibuffer.
> 
> Maybe this difference is unimportant.  But still remains the need
> to find a key to show help text from yes-or-no-p.  y-or-n-p now
> uses C-h to show help, but in yes-or-no-p C-h is useful as
> a help key prefix.

Do we need C-h as a prefix key in this case?

bug#13649: boobytrapped dired-do-async-shell-command question

[Drew Adams]

> >>   (y-or-n-p "File ‘foo.el’ exists; overwrite?")
> >>
> >> ‘C-l’, ‘C-v’, ‘M-v’ work fine and scroll the original buffer.
> >>
> >> But yes-or-no-p (BTW, it requires the space char at the end of the
> prompt):
> >>
> >>   (yes-or-no-p "Buffer foo.el modified; kill anyway? ")
> >>
> >> ‘C-l’, ‘C-v’, ‘M-v’ don't scroll the original buffer.
> >
> > Isn't that expected?  y-or-n-p doesn't need to allow you to edit the
> > text in the minibuffer.
> 
> Maybe this difference is unimportant.  But still remains the need
> to find a key to show help text from yes-or-no-p.  y-or-n-p now
> uses C-h to show help, but in yes-or-no-p C-h is useful as
> a help key prefix.

Apologies for not following this.
If you're looking for a key that will show some help,
maybe consider `?'.

I use that in `dired+.el' for some similar things.
And `dired.el' uses it for `dired-summary' (to show
why something went wrong).

bug#13649: boobytrapped dired-do-async-shell-command question

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "larsi@gnus.org" <larsi@gnus.org>,
>         "13649@debbugs.gnu.org"
> 	<13649@debbugs.gnu.org>,
>         "jidanni@jidanni.org" <jidanni@jidanni.org>
> Date: Wed, 11 May 2022 20:27:39 +0000

> > >> ‘C-l’, ‘C-v’, ‘M-v’ don't scroll the original buffer.
> > >
> > > Isn't that expected?  y-or-n-p doesn't need to allow you to edit the
> > > text in the minibuffer.
> > 
> > Maybe this difference is unimportant.  But still remains the need
> > to find a key to show help text from yes-or-no-p.  y-or-n-p now
> > uses C-h to show help, but in yes-or-no-p C-h is useful as
> > a help key prefix.
> 
> Apologies for not following this.
> If you're looking for a key that will show some help,
> maybe consider `?'.

How can we use a printable character in yes-or-no-p, which expects the
user to type readable text?  Are you saying that the answer to
yes-or-no-p can never include a question mark?  And even if we, for
some strange reason, decide that for yes-or-no-p the question mark is
not needed as itself, this issue is AFAIU general to all uses of
reading from the minibuffer, where we definitely cannot usurp any
printable character for help commands.

bug#13649: boobytrapped dired-do-async-shell-command question

[Drew Adams]

> > Apologies for not following this.
> > If you're looking for a key that will show some help,
> > maybe consider `?'.
> 
> How can we use a printable character in yes-or-no-p, 
> which expects the user to type readable text?  

Apologies, I was thinking of y-or-n-p.

(I use it only where a single char is read.) 

bug#13649: boobytrapped dired-do-async-shell-command question

[Juri Linkov]

>> Maybe this difference is unimportant.  But still remains the need
>> to find a key to show help text from yes-or-no-p.  y-or-n-p now
>> uses C-h to show help, but in yes-or-no-p C-h is useful as
>> a help key prefix.
>
> Do we need C-h as a prefix key in this case?

C-h is a useful prefix key to get help in the yes-or-no-p minibuffer.

bug#13649: boobytrapped dired-do-async-shell-command question

[Juri Linkov]

> If you're looking for a key that will show some help,
> maybe consider `?'.

Good idea, so with a prompt like

  Use a new buffer? (yes, no or ?)

typing `? RET' will show the help buffer.

bug#13649: boobytrapped dired-do-async-shell-command question

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: larsi@gnus.org,  13649@debbugs.gnu.org,  jidanni@jidanni.org
> Date: Thu, 12 May 2022 19:52:36 +0300
> 
> >> Maybe this difference is unimportant.  But still remains the need
> >> to find a key to show help text from yes-or-no-p.  y-or-n-p now
> >> uses C-h to show help, but in yes-or-no-p C-h is useful as
> >> a help key prefix.
> >
> > Do we need C-h as a prefix key in this case?
> 
> C-h is a useful prefix key to get help in the yes-or-no-p minibuffer.

What kind of help?  And how is it different from the help text you
wanted to show, for which you were looking for a key?

bug#13649: boobytrapped dired-do-async-shell-command question

[Juri Linkov]

>> >> Maybe this difference is unimportant.  But still remains the need
>> >> to find a key to show help text from yes-or-no-p.  y-or-n-p now
>> >> uses C-h to show help, but in yes-or-no-p C-h is useful as
>> >> a help key prefix.
>> >
>> > Do we need C-h as a prefix key in this case?
>> 
>> C-h is a useful prefix key to get help in the yes-or-no-p minibuffer.
>
> What kind of help?  And how is it different from the help text you
> wanted to show, for which you were looking for a key?

Any help, e.g. `C-h m', `C-h b', ...  But a special key
like `? RET' is needed to display the text from help-form.

bug#13649: boobytrapped dired-do-async-shell-command question

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: larsi@gnus.org,  13649@debbugs.gnu.org,  jidanni@jidanni.org
> Date: Thu, 12 May 2022 20:34:45 +0300
> 
> >> >> Maybe this difference is unimportant.  But still remains the need
> >> >> to find a key to show help text from yes-or-no-p.  y-or-n-p now
> >> >> uses C-h to show help, but in yes-or-no-p C-h is useful as
> >> >> a help key prefix.
> >> >
> >> > Do we need C-h as a prefix key in this case?
> >> 
> >> C-h is a useful prefix key to get help in the yes-or-no-p minibuffer.
> >
> > What kind of help?  And how is it different from the help text you
> > wanted to show, for which you were looking for a key?
> 
> Any help, e.g. `C-h m', `C-h b', ...  But a special key
> like `? RET' is needed to display the text from help-form.

If you want to be able to use those C-h sequences, then "C-h C-h"
could show the text from help-form.