GNU bug report logs -
#45412
File ... is large (... MiB), really open? (y)es or (n)o or (l)iterally
Previous Next
Reported by: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Date: Thu, 24 Dec 2020 23:27:01 UTC
Severity: wishlist
Tags: fixed
Merged with 45647,
47556
Fixed in version 28.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 45412 in the body.
You can then email your comments to 45412 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#45412; Package
emacs.
(Thu, 24 Dec 2020 23:27:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
積丹尼 Dan Jacobson <jidanni <at> jidanni.org>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 24 Dec 2020 23:27:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
File 06-7377E-001A.jpg is large (14.4 MiB), really open? (y)es or (n)o or (l)iterally y
File 06-7377E-001B.jpg is large (14.4 MiB), really open? (y)es or (n)o or (l)iterally y
File 06-7377E-001C.jpg is large (14.4 MiB), really open? (y)es or (n)o or (l)iterally y
...
Maybe add choices:
"(a)lways" (for the rest of the session).
"(n)ever" (for the rest of the session).
Also the user has no clue about what to change to change whatever is
asking this. So maybe add (c)ustomize.
Seen with
v runs the command dired-view-file (found in dired-mode-map).
emacs-version "27.1"
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Fri, 25 Dec 2020 01:02:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 45412 <at> debbugs.gnu.org (full text, mbox):
積丹尼 Dan Jacobson <jidanni <at> jidanni.org> writes:
Thank you for your feature request to improve Emacs.
> File 06-7377E-001A.jpg is large (14.4 MiB), really open? (y)es or (n)o or (l)iterally y
> File 06-7377E-001B.jpg is large (14.4 MiB), really open? (y)es or (n)o or (l)iterally y
> File 06-7377E-001C.jpg is large (14.4 MiB), really open? (y)es or (n)o or (l)iterally y
> ...
> Maybe add choices:
> "(a)lways" (for the rest of the session).
I think users would be confused about this option. Would it always open
the file regularly or literally? A minor thing, I think it's customary
in Emacs to use "!" for this "don't ask me again" feature (see
save-some-buffers or hack-local-variables-confirm, for example).
> "(n)ever" (for the rest of the session).
Same here, it's not totally clear to me if this option would never open
a large file, or never ask for confirmation before opening a large
file. The dialog message ends with "really open?".
>
> Also the user has no clue about what to change to change whatever is
> asking this. So maybe add (c)ustomize.
Makes sense, but I don't know how well it'd fit the rest of Emacs.
AFAIK, customization points are not usually advertised in Emacs prompts.
It's more typical to expect that users "ask Emacs" to discover them, for
example by issuing M-x customize-apropos large file RET or M-x
customize-group files RET.
Instead, one possibility could be to offer a "!" option that would
always open big files non-literally in the current Emacs session. Its
implementation would basically open the large file and set
large-file-warning-threshold to nil. However, I foresee problems if
users accidentally press "!" in this prompt.
Another approach could be to offer a C-h binding that opens a help
window that describes the possible options and briefly links to the
customization entry point that removes the prompt permanently.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Fri, 25 Dec 2020 01:30:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 45412 <at> debbugs.gnu.org (full text, mbox):
>>>>> "DM" == Daniel Martín <mardani29 <at> yahoo.es> writes:
DM> Another approach could be to offer a C-h binding
Indeed. Then all options of what the user could do could be explained in
detail there without any size limit.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Fri, 25 Dec 2020 05:53:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 45412 <at> debbugs.gnu.org (full text, mbox):
Daniel Martín <mardani29 <at> yahoo.es> writes:
> I think users would be confused about this option. Would it always open
> the file regularly or literally?
Yes, it's rife with confusion.
> Instead, one possibility could be to offer a "!" option that would
> always open big files non-literally in the current Emacs session. Its
> implementation would basically open the large file and set
> large-file-warning-threshold to nil. However, I foresee problems if
> users accidentally press "!" in this prompt.
Whether to open a large file (and how) is so situation-dependent that I
think adding a "!" option here would be a disservice.
> Another approach could be to offer a C-h binding that opens a help
> window that describes the possible options and briefly links to the
> customization entry point that removes the prompt permanently.
Yeah, that sounds like a good idea.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Fri, 25 Dec 2020 09:40:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 45412 <at> debbugs.gnu.org (full text, mbox):
>> Another approach could be to offer a C-h binding that opens a help
>> window that describes the possible options and briefly links to the
>> customization entry point that removes the prompt permanently.
>
> Yeah, that sounds like a good idea.
I agree, this is really the best idea.
Forcibly Merged 45412 45647.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Mon, 04 Jan 2021 10:04:03 GMT)
Full text and
rfc822 format available.
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 04 Jan 2021 13:16:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Sat, 10 Apr 2021 22:34:01 GMT)
Full text and
rfc822 format available.
Message #24 received at 45412 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Juri Linkov <juri <at> linkov.net> writes:
>>> Another approach could be to offer a C-h binding that opens a help
>>> window that describes the possible options and briefly links to the
>>> customization entry point that removes the prompt permanently.
>>
>> Yeah, that sounds like a good idea.
>
> I agree, this is really the best idea.
OK, I've implemented it in the attached patch. Suggestions
welcome.
[0001-Add-a-help-option-in-the-open-large-files-prompt.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Sat, 10 Apr 2021 23:05:02 GMT)
Full text and
rfc822 format available.
Message #27 received at 45412 <at> debbugs.gnu.org (full text, mbox):
>>>> Another approach could be to offer a C-h binding that opens a help
>>>> window that describes the possible options and briefly links to the
>>>> customization entry point that removes the prompt permanently.
>>>
>>> Yeah, that sounds like a good idea.
>>
>> I agree, this is really the best idea.
>
> OK, I've implemented it in the attached patch. Suggestions
> welcome.
>
> + (while (null choice)
> + (setq choice (read-char-choice
> + (concat prompt " (y)es, (n)o, (l)iterally, (?)")
> + '(?y ?Y ?n ?N ?l ?L ?? ?\C-h)))
> + (when (memq choice '(?? ?\C-h))
> + (files--ask-user-about-large-file-help
> + op-type (funcall byte-count-to-string-function size))
To avoid the additional loop, maybe it's easier just to let-bind
the variable 'help-form' that is handled by 'read-char-choice'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Sun, 11 Apr 2021 07:04:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 45412 <at> debbugs.gnu.org (full text, mbox):
> Cc: 45412 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
> 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
> Date: Sun, 11 Apr 2021 00:32:34 +0200
> From: Daniel Martín via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> >>> Another approach could be to offer a C-h binding that opens a help
> >>> window that describes the possible options and briefly links to the
> >>> customization entry point that removes the prompt permanently.
> >>
> >> Yeah, that sounds like a good idea.
> >
> > I agree, this is really the best idea.
>
> OK, I've implemented it in the attached patch. Suggestions
> welcome.
Thanks, see below for some comments.
> +---
> +** When Emacs prompts before opening a large file, a new help window
> +has been added. This help window describes the available options and
> +how to disable the prompt by customizing the
> +'large-file-warning-threshold' variable.
This should mention the C-h key which triggers the help display:
IMO that's the most important piece of information users should know
about the new feature.
NEWS is visited in Outline mode, so each entry should have a heading
line which is a complete sentence with a concise description of the
change.
> +
>
> * Editing Changes in Emacs 28.1
>
> diff --git a/lisp/files.el b/lisp/files.el
> index 60d6034011..49224e4b1e 100644
> --- a/lisp/files.el
> +++ b/lisp/files.el
> @@ -2123,28 +2123,62 @@ out-of-memory-warning-percentage
>
> (declare-function x-popup-dialog "menu.c" (position contents &optional header))
>
> +(defun files--ask-user-about-large-file-help (op-type size)
> + "Show a buffer explaining the options to open large files in Emacs."
> + (with-output-to-temp-buffer "*Help*"
> + (with-current-buffer standard-output
> + (insert
> + (format
> + "The file that you want to %s is large (%s).
I suggest to say here what is the threshold above which Emacs asks the
question (because users may wish to customize it, as mentioned below).
> +You can press ‘y‘ to open the file.
Press 'y' to open the file.
And please also use our style of quoting in documentation and strings,
'like this'.
> +You can press ‘n‘ to abort.
This should explain what "abort" means in this case.
> +You can press ‘l‘ to open the file literally, which means that
Suggest to say "(the letter ell)" here, to avoid confusion with the
digit 1.
Also, the text says literally "open", but the function actually
accepts an argument that describes the operation, which could be
something else.
> +Emacs will open the file without doing any format or character code
> +conversion and in Fundamental mode, without loading any potentially
> +expensive feature.
^^^^^^^
"features", in plural.
> +You can customize the option ‘large-file-warning-threshold‘ to be
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Quoting style again. Please quote `like this' here, so that Emacs
creates a hyperlink to the variable's doc.
> +the file size, in bytes, from which Emacs will ask for
> +confirmation. Set it to ‘nil‘ to never request
We don't quote nil and t in this context.
> + (if use-dialog
> + (setq choice (x-popup-dialog t `(,prompt
> + ("Yes" . ?y)
> + ("No" . ?n)
> + ("Open literally" . ?l))))
A literal "Open" again.
Also, don't we want to add a Help option to the dialog? If not, why
not?
> + (while (null choice)
> + (setq choice (read-char-choice
> + (concat prompt " (y)es, (n)o, (l)iterally, (?)")
> + '(?y ?Y ?n ?N ?l ?L ?? ?\C-h)))
> + (when (memq choice '(?? ?\C-h))
Why only ? or C-h? What about F1? what about the case that help-char
is something else?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Mon, 12 Apr 2021 08:07:01 GMT)
Full text and
rfc822 format available.
Message #33 received at 45412 <at> debbugs.gnu.org (full text, mbox):
Daniel Martín <mardani29 <at> yahoo.es> writes:
> OK, I've implemented it in the attached patch. Suggestions
> welcome.
Hm... wouldn't just using `read-multiple-choice' be simpler here?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Fri, 16 Apr 2021 23:51:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 45412 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Daniel Martín <mardani29 <at> yahoo.es> writes:
>
>> OK, I've implemented it in the attached patch. Suggestions
>> welcome.
>
> Hm... wouldn't just using `read-multiple-choice' be simpler here?
I've given `read-multiple-choice' a try and the help text doesn't look
very good if any of the descriptions is a bit long. Another problem I
saw is that if the help text contains a reference to a variable, the
rendered hyperlink doesn't work.
It's a pity because I think this function is a good way to simplify and
homogenize this use case in Emacs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Sat, 17 Apr 2021 11:45:02 GMT)
Full text and
rfc822 format available.
Message #39 received at 45412 <at> debbugs.gnu.org (full text, mbox):
Daniel Martín <mardani29 <at> yahoo.es> writes:
> I've given `read-multiple-choice' a try and the help text doesn't look
> very good if any of the descriptions is a bit long. Another problem I
> saw is that if the help text contains a reference to a variable, the
> rendered hyperlink doesn't work.
>
> It's a pity because I think this function is a good way to simplify and
> homogenize this use case in Emacs.
Well, neither problem seem insurmountable to fix.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Forcibly Merged 45412 45647 47556.
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org.
(Sun, 18 Apr 2021 16:44:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Wed, 21 Apr 2021 22:14:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 45412 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Daniel Martín <mardani29 <at> yahoo.es> writes:
>
>> I've given `read-multiple-choice' a try and the help text doesn't look
>> very good if any of the descriptions is a bit long. Another problem I
>> saw is that if the help text contains a reference to a variable, the
>> rendered hyperlink doesn't work.
>>
>> It's a pity because I think this function is a good way to simplify and
>> homogenize this use case in Emacs.
>
> Well, neither problem seem insurmountable to fix.
OK, I've refactored the feature on top of a patched version of
`read-multiple-choice' that adds support for overriding the help text.
I've also handled the `edit' action, so that a user can enter a
recursive edit to select the help link. This API change is
backwards-compatible. As one change depends on the previous one, but
they are otherwise orthogonal, I've made two separate commits.
These new patches address the following review comments:
- Simplify the call site by avoiding the character loop.
- The help description now appears on `help-char', ?, or F1.
- Improves and fixes the help text and NEWS description, per Eli's
suggestions.
The idea to show the help text also for graphical prompts is a good
idea, but as there's no command already in Emacs that supports it,
AFAIK, it could be a separate feature request. What do you think?
Thanks.
[0001-Extend-read-multiple-choice-to-support-free-form-hel.patch (text/x-patch, attachment)]
[0002-Add-a-help-option-to-the-open-large-files-prompt.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Thu, 22 Apr 2021 10:05:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 45412 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 22 Apr 2021 00:12:54 +0200
> From: Daniel Martín via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> -(defun read-multiple-choice (prompt choices)
> +(defun read-multiple-choice (prompt choices &optional help-string)
> "Ask user a multiple choice question.
> PROMPT should be a string that will be displayed as the prompt.
>
> @@ -35,15 +35,18 @@ read-multiple-choice
> be displayed while prompting (if there's room, it might be
> shortened). DESCRIPTION is an optional longer explanation that
> will be displayed in a help buffer if the user requests more
> -help.
> +help. This help description has a fixed format in columns, but
> +the user can control the text that is displayed and how it is
> +formatted with optional argument HELP-STRING.
This leaves it unsaid what HELP-STRING is (is it a string? a list? a
function? something else?) and how it is used by the function.
> +If the user enters `recenter', `scroll-up', or `scroll-down'
> +responses, perform the requested window recentering or scrolling
> +and ask again. If the user enters `edit', a recursive edit is
> +started.
The last sentence (ab)uses the passive tense, and thus reads
awkwardly. Can you reword not to use passive tense?
Also, how about saying what happens when the user exits the
recursive-edit?
> @@ -133,6 +136,10 @@ read-multiple-choice
> (ignore-errors (scroll-other-window)) t)
> ((eq answer 'scroll-other-window-down)
> (ignore-errors (scroll-other-window-down)) t)
> + ((eq answer 'edit)
> + (save-excursion
> + (save-window-excursion
> + (recursive-edit))))
It is customary to display an echo-area message when entering
recursive-edit, telling the user how to exit when done editing.
> - (setq wrong-char (not (memq tchar '(?? ?\C-h)))
> + (setq wrong-char (not (memq tchar '(?? help-char)))
What about F1?
> + (if help-string
> + (with-help-window buf
> + (with-current-buffer buf
> + (insert help-string)))
Should this verify that HELP-STRING is a string?
> +---
> +** New help window when Emacs prompts before opening a large file.
> ++Press '?' or 'help-char' (by default, 'C-h') to display this new help window.
I think this should mention the situations where this happens.
"Opening large files" is not detailed enough: I suggest to mention a
couple of commands that trigger this, and perhaps also what is
considered a "large file".
> (defun files--ask-user-about-large-file (size op-type filename offer-raw)
> (let ((prompt (format "File %s is large (%s), really %s?"
> (file-name-nondirectory filename)
> (funcall byte-count-to-string-function size) op-type)))
> (if (not offer-raw)
> (if (y-or-n-p prompt) nil 'abort)
> - (let* ((use-dialog (and (display-popup-menus-p)
> - last-input-event
> - (listp last-nonmenu-event)
> - use-dialog-box))
> + (let* ((prompt (format "File %s is large (%s), really %s?"
> + (file-name-nondirectory filename)
> + (funcall byte-count-to-string-function size) op-type))
> (choice
> - (if use-dialog
> - (x-popup-dialog t `(,prompt
> - ("Yes" . ?y)
> - ("No" . ?n)
> - ("Open literally" . ?l)))
Why are we losing the feature whereby we use GUI dialogs to ask the
question? This sounds like a regression to me, at least for users who
use the mouse and menu-bar in preference to the keyboard. And the doc
string still says we do support the dialogs. Am I missing something?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Thu, 22 Apr 2021 22:11:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 45412 <at> debbugs.gnu.org (full text, mbox):
> The idea to show the help text also for graphical prompts is a good
> idea, but as there's no command already in Emacs that supports it,
> AFAIK, it could be a separate feature request. What do you think?
Thanks. While testing your patches, I noticed a compilation warning:
emacs-lisp/rmc.el:29:1: Warning: Variable `buf' left uninitialized
Also these let-bindings are duplicated:
(prompt (format "File %s is large (%s), really %s?"
(file-name-nondirectory filename)
(funcall byte-count-to-string-function size) op-type))
Otherwise, it looks nice, except of Eli's comment about the need
to keep graphical dialogs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Sun, 25 Apr 2021 19:16:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 45412 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> - (if use-dialog
>> - (x-popup-dialog t `(,prompt
>> - ("Yes" . ?y)
>> - ("No" . ?n)
>> - ("Open literally" . ?l)))
>
> Why are we losing the feature whereby we use GUI dialogs to ask the
> question? This sounds like a regression to me, at least for users who
> use the mouse and menu-bar in preference to the keyboard. And the doc
> string still says we do support the dialogs. Am I missing something?
The support for x-popup-dialog is in `read-multiple-choice', so I assume
that it's just using that instead? But I haven't tried the patch.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Sun, 25 Apr 2021 21:24:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 45412 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> - (if use-dialog
>>> - (x-popup-dialog t `(,prompt
>>> - ("Yes" . ?y)
>>> - ("No" . ?n)
>>> - ("Open literally" . ?l)))
>>
>> Why are we losing the feature whereby we use GUI dialogs to ask the
>> question? This sounds like a regression to me, at least for users who
>> use the mouse and menu-bar in preference to the keyboard. And the doc
>> string still says we do support the dialogs. Am I missing something?
>
> The support for x-popup-dialog is in `read-multiple-choice', so I assume
> that it's just using that instead? But I haven't tried the patch.
Yes, if you click on a large file in Dired, you'll see a graphical
prompt, as always.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Mon, 26 Apr 2021 02:29:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 45412 <at> debbugs.gnu.org (full text, mbox):
> From: Daniel Martín <mardani29 <at> yahoo.es>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 45412 <at> debbugs.gnu.org,
> jidanni <at> jidanni.org, juri <at> linkov.net
> Date: Sun, 25 Apr 2021 23:23:02 +0200
>
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> >>> - (if use-dialog
> >>> - (x-popup-dialog t `(,prompt
> >>> - ("Yes" . ?y)
> >>> - ("No" . ?n)
> >>> - ("Open literally" . ?l)))
> >>
> >> Why are we losing the feature whereby we use GUI dialogs to ask the
> >> question? This sounds like a regression to me, at least for users who
> >> use the mouse and menu-bar in preference to the keyboard. And the doc
> >> string still says we do support the dialogs. Am I missing something?
> >
> > The support for x-popup-dialog is in `read-multiple-choice', so I assume
> > that it's just using that instead? But I haven't tried the patch.
>
> Yes, if you click on a large file in Dired, you'll see a graphical
> prompt, as always.
With which buttons and which text?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Tue, 27 Apr 2021 01:09:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 45412 <at> debbugs.gnu.org (full text, mbox):
Daniel Martín <mardani29 <at> yahoo.es> writes:
> Yes, if you click on a large file in Dired, you'll see a graphical
> prompt, as always.
Right. Eli had other comments on the patch, though -- would it be
possible for you to rework the patch, and then we can get it applied?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Wed, 05 May 2021 23:11:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 45412 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Daniel Martín <mardani29 <at> yahoo.es> writes:
>
>> Yes, if you click on a large file in Dired, you'll see a graphical
>> prompt, as always.
>
> Right. Eli had other comments on the patch, though -- would it be
> possible for you to rework the patch, and then we can get it applied?
I think I've applied all code review suggestions (patches attached).
Thanks.
[0001-Extend-read-multiple-choice-to-support-free-form-hel.patch (text/x-patch, attachment)]
[0002-Add-a-help-option-to-the-open-large-files-prompt.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Thu, 06 May 2021 08:29:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 45412 <at> debbugs.gnu.org (full text, mbox):
Daniel Martín <mardani29 <at> yahoo.es> writes:
> I think I've applied all code review suggestions (patches attached).
> Thanks.
Thanks; applied to Emacs 28 (with some minor changes). Seems to work
great. :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) fixed.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Thu, 06 May 2021 08:29:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 28.1, send any further explanations to
45412 <at> debbugs.gnu.org and 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Thu, 06 May 2021 08:29:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Thu, 06 May 2021 08:32:01 GMT)
Full text and
rfc822 format available.
Message #75 received at 45412 <at> debbugs.gnu.org (full text, mbox):
> From: Daniel Martín <mardani29 <at> yahoo.es>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 45412 <at> debbugs.gnu.org,
> jidanni <at> jidanni.org, juri <at> linkov.net
> Date: Thu, 06 May 2021 01:10:08 +0200
>
> I think I've applied all code review suggestions (patches attached).
Thanks, there are still a couple of nits left:
> * lisp/emacs-lisp/rmc.el (read-multiple-choice): Add a new argument to
> override the default help description in `read-multiple-choice'. Use
> the `help-char' variable instead of ?\C-h. Also support the `edit'
> action from `query-replace-map', so that help links can be visited by
> entering a recursive edit.
In commit log messages and in NEWS we nowadays prefer quoting 'like
this', not `like this'.
> +shortened). DESCRIPTION is an optional longer explanation for
> +the entry that will be displayed in a help buffer if the user
> +requests more help. This help description has a fixed format in
> +columns, but, for greater flexibility, instead of passing a
> +DESCRIPTION, the user can use the optional argument HELP-STRING.
> +This argument is a string that contains the text with the
> +complete description of all choices. `read-multiple-choice' will
> +display that description in a help buffer if the user requests
> +it.
You say "user" here several times, but I think you mean the Lisp
program that calls this function, not the Emacs user.
> + (substitute-command-keys
> + "Recursive edit. Resume with \\[exit-recursive-edit]"))
I think "resume" is too vague here to be useful. Suggest to reword:
Recursive edit; type \\[exit-recursive-edit] to return to help screen.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Fri, 07 May 2021 14:12:01 GMT)
Full text and
rfc822 format available.
Message #78 received at 45412 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 06 May 2021 11:30:57 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 45412 <at> debbugs.gnu.org, larsi <at> gnus.org, jidanni <at> jidanni.org, juri <at> linkov.net
>
> > From: Daniel Martín <mardani29 <at> yahoo.es>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 45412 <at> debbugs.gnu.org,
> > jidanni <at> jidanni.org, juri <at> linkov.net
> > Date: Thu, 06 May 2021 01:10:08 +0200
> >
> > I think I've applied all code review suggestions (patches attached).
>
> Thanks, there are still a couple of nits left:
Looks like these comments were ignored, so I went ahead and made the
changes myself. (Except that there's no way of fixing the quoting in
the commit log message...)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Sat, 08 May 2021 11:38:01 GMT)
Full text and
rfc822 format available.
Message #81 received at 45412 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Looks like these comments were ignored, so I went ahead and made the
> changes myself.
Thanks.
> (Except that there's no way of fixing the quoting in the commit log
> message...)
I don't think we have any policy on quoting symbols in the commit
messages.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Sat, 08 May 2021 12:24:01 GMT)
Full text and
rfc822 format available.
Message #84 received at 45412 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: mardani29 <at> yahoo.es, 45412 <at> debbugs.gnu.org, jidanni <at> jidanni.org,
> juri <at> linkov.net
> Date: Sat, 08 May 2021 13:37:32 +0200
>
> I don't think we have any policy on quoting symbols in the commit
> messages.
We decided to quote 'like this' in NEWS and ChangeLog files, AFAIR.
Since ChangeLog files are nowadays produced from the Git log, I
thought this was in effect there as well.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Sun, 09 May 2021 09:59:01 GMT)
Full text and
rfc822 format available.
Message #87 received at 45412 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> We decided to quote 'like this' in NEWS and ChangeLog files, AFAIR.
> Since ChangeLog files are nowadays produced from the Git log, I
> thought this was in effect there as well.
It makes sense to insist on a convention in the NEWS file, but in the
commit messages (and therefore ChangeLog files), that requires more
effort than it's worth. (And very few people seem to be following the
same conventions currently.)
There's too many hurdles to contribute to Emacs already -- let's not add
more.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45412; Package
emacs.
(Sun, 09 May 2021 10:05:02 GMT)
Full text and
rfc822 format available.
Message #90 received at 45412 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: mardani29 <at> yahoo.es, 45412 <at> debbugs.gnu.org, jidanni <at> jidanni.org,
> juri <at> linkov.net
> Date: Sun, 09 May 2021 11:57:53 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > We decided to quote 'like this' in NEWS and ChangeLog files, AFAIR.
> > Since ChangeLog files are nowadays produced from the Git log, I
> > thought this was in effect there as well.
>
> It makes sense to insist on a convention in the NEWS file, but in the
> commit messages (and therefore ChangeLog files), that requires more
> effort than it's worth. (And very few people seem to be following the
> same conventions currently.)
>
> There's too many hurdles to contribute to Emacs already -- let's not add
> more.
I think having 2 different conventions is worse than having just one,
but I won't argue further.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 06 Jun 2021 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 315 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.