GNU bug report logs -
#13649
boobytrapped dired-do-async-shell-command question
Previous Next
Reported by: jidanni <at> jidanni.org
Date: Thu, 7 Feb 2013 16:28:02 UTC
Severity: minor
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13649 in the body.
You can then email your comments to 13649 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Thu, 07 Feb 2013 16:28:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
jidanni <at> jidanni.org:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 07 Feb 2013 16:28:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
& 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...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Thu, 07 Feb 2013 17:04:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> & 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Thu, 07 Feb 2013 17:14:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 13649 <at> debbugs.gnu.org (full text, mbox):
>>>>> "SM" == Stefan Monnier <monnier <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Fri, 08 Feb 2013 08:26:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Fri, 08 Feb 2013 13:45:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> jurta.org>
> Date: Fri, 08 Feb 2013 10:25:01 +0200
> Cc: 13649 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Fri, 08 Feb 2013 15:12:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 13649 <at> debbugs.gnu.org (full text, mbox):
>> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Fri, 08 Feb 2013 16:04:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Fri, 08 Feb 2013 16:08:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Juri Linkov <juri <at> jurta.org>, 13649 <at> debbugs.gnu.org, jidanni <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Fri, 08 Feb 2013 16:35:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> > 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))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Fri, 08 Feb 2013 17:00:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Fri, 08 Feb 2013 17:08:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> > 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Sat, 09 Feb 2013 01:10:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 13649 <at> debbugs.gnu.org (full text, mbox):
>> > 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Sat, 09 Feb 2013 01:10:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 13649 <at> debbugs.gnu.org (full text, mbox):
>>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Sat, 09 Feb 2013 01:48:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Sat, 09 Feb 2013 03:37:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 13649 <at> debbugs.gnu.org (full text, mbox):
>>>>> "SM" == Stefan Monnier <monnier <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Sat, 09 Feb 2013 08:35:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> > 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Sun, 10 Feb 2013 10:13:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 13649 <at> debbugs.gnu.org (full text, mbox):
>> 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.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Sun, 10 Feb 2013 13:23:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 13649 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Sun, 10 Feb 2013 13:55:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Sun, 10 Feb 2013 14:22:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 13649 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Sun, 10 Feb 2013 15:26:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> 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'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Sun, 10 Feb 2013 15:30:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 13649 <at> debbugs.gnu.org (full text, mbox):
>>>>> "JL" == Juri Linkov <juri <at> 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!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Sun, 10 Feb 2013 16:21:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 13649 <at> debbugs.gnu.org (full text, mbox):
>> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Mon, 11 Feb 2013 09:43:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 13649 <at> debbugs.gnu.org (full text, mbox):
>>>>>> "JL" == Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Sun, 24 Apr 2022 13:50:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 13649 <at> debbugs.gnu.org (full text, mbox):
jidanni <at> 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 marked as fixed in version 29.1, send any further explanations to
13649 <at> debbugs.gnu.org and jidanni <at> jidanni.org
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sun, 24 Apr 2022 13:50:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Sun, 24 Apr 2022 15:51:02 GMT)
Full text and
rfc822 format available.
Message #82 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Sun, 24 Apr 2022 15:58:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 13649 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Mon, 25 Apr 2022 15:46:02 GMT)
Full text and
rfc822 format available.
Message #88 received at 13649 <at> debbugs.gnu.org (full text, mbox):
>> 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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Tue, 26 Apr 2022 09:50:01 GMT)
Full text and
rfc822 format available.
Message #91 received at 13649 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Tue, 26 Apr 2022 15:54:01 GMT)
Full text and
rfc822 format available.
Message #94 received at 13649 <at> debbugs.gnu.org (full text, mbox):
>> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Wed, 27 Apr 2022 12:12:02 GMT)
Full text and
rfc822 format available.
Message #97 received at 13649 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Sun, 08 May 2022 17:56:02 GMT)
Full text and
rfc822 format available.
Message #100 received at 13649 <at> debbugs.gnu.org (full text, mbox):
>> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Sun, 08 May 2022 18:59:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> Cc: 13649 <at> debbugs.gnu.org, jidanni <at> jidanni.org
> From: Juri Linkov <juri <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Mon, 09 May 2022 09:43:01 GMT)
Full text and
rfc822 format available.
Message #106 received at 13649 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Mon, 09 May 2022 09:45:02 GMT)
Full text and
rfc822 format available.
Message #109 received at 13649 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Lars Ingebrigtsen <larsi <at> 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:
[Message part 2 (image/png, inline)]
[Message part 3 (text/plain, inline)]
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Mon, 09 May 2022 19:01:01 GMT)
Full text and
rfc822 format available.
Message #112 received at 13649 <at> debbugs.gnu.org (full text, mbox):
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Mon, 09 May 2022 19:02:02 GMT)
Full text and
rfc822 format available.
Message #115 received at 13649 <at> debbugs.gnu.org (full text, mbox):
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Mon, 09 May 2022 19:21:01 GMT)
Full text and
rfc822 format available.
Message #118 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: larsi <at> gnus.org, 13649 <at> debbugs.gnu.org, jidanni <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Tue, 10 May 2022 01:54:02 GMT)
Full text and
rfc822 format available.
Message #121 received at 13649 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Wed, 11 May 2022 07:26:02 GMT)
Full text and
rfc822 format available.
Message #124 received at 13649 <at> debbugs.gnu.org (full text, mbox):
>> >> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Wed, 11 May 2022 11:40:01 GMT)
Full text and
rfc822 format available.
Message #127 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: larsi <at> gnus.org, 13649 <at> debbugs.gnu.org, jidanni <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Wed, 11 May 2022 17:22:01 GMT)
Full text and
rfc822 format available.
Message #130 received at 13649 <at> debbugs.gnu.org (full text, mbox):
>> 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));
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Wed, 11 May 2022 17:22:03 GMT)
Full text and
rfc822 format available.
Message #133 received at 13649 <at> debbugs.gnu.org (full text, mbox):
>> (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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Wed, 11 May 2022 17:41:01 GMT)
Full text and
rfc822 format available.
Message #136 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: larsi <at> gnus.org, 13649 <at> debbugs.gnu.org, jidanni <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Wed, 11 May 2022 20:28:01 GMT)
Full text and
rfc822 format available.
Message #139 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> >> (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).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Thu, 12 May 2022 05:23:01 GMT)
Full text and
rfc822 format available.
Message #142 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> From: Drew Adams <drew.adams <at> oracle.com>
> CC: "larsi <at> gnus.org" <larsi <at> gnus.org>,
> "13649 <at> debbugs.gnu.org"
> <13649 <at> debbugs.gnu.org>,
> "jidanni <at> jidanni.org" <jidanni <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Thu, 12 May 2022 16:21:01 GMT)
Full text and
rfc822 format available.
Message #145 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> > 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.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Thu, 12 May 2022 17:09:01 GMT)
Full text and
rfc822 format available.
Message #148 received at 13649 <at> debbugs.gnu.org (full text, mbox):
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Thu, 12 May 2022 17:09:02 GMT)
Full text and
rfc822 format available.
Message #151 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Thu, 12 May 2022 17:22:01 GMT)
Full text and
rfc822 format available.
Message #154 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: larsi <at> gnus.org, 13649 <at> debbugs.gnu.org, jidanni <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Thu, 12 May 2022 17:36:01 GMT)
Full text and
rfc822 format available.
Message #157 received at 13649 <at> debbugs.gnu.org (full text, mbox):
>> >> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13649; Package
emacs.
(Thu, 12 May 2022 17:40:01 GMT)
Full text and
rfc822 format available.
Message #160 received at 13649 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: larsi <at> gnus.org, 13649 <at> debbugs.gnu.org, jidanni <at> 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.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 10 Jun 2022 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 24 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.