GNU bug report logs -
#76028
31; completing-read-multiple: Add prompt indicator
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 76028 in the body.
You can then email your comments to 76028 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
juri <at> linkov.net, bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Mon, 03 Feb 2025 09:28:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Daniel Mendler <mail <at> daniel-mendler.de>
:
New bug report received and forwarded. Copy sent to
juri <at> linkov.net, bug-gnu-emacs <at> gnu.org
.
(Mon, 03 Feb 2025 09:28:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
The function `completing-read-multiple' (CRM) can be used to read
multiple candidates, separated by comma (see the variable
`crm-separator'). Besides that it acts similarly to `completing-read'.
To the user it is no obvious if CRM is used.
For years I have used an advice in my configuration which adds a CRM
indicator to the prompt. For example, the advice turns the
`describe-face' prompt from "Describe face: " into "[CRM ,] Describe
face: ", which tells the user that multiple face names are read,
separated by comma:
#+begin_src emacs-lisp
(defun crm-indicator (args)
(defvar crm-separator)
(cons (format "[%s %s] %s"
(propertize "CRM" 'face 'error)
(propertize
(replace-regexp-in-string
"\\`\\[.*?]\\*\\|\\[.*?]\\*\\'" ""
crm-separator)
'face 'success)
(car args))
(cdr args)))
(advice-add #'completing-read-multiple :filter-args #'crm-indicator)
#+end_src
I propose to add such an indicator to CRM by default. Above I have
chosen the tag "CRM" for its shortness, but a more user friendly
solution might require a longer more descriptive name. Furthermore the
code above extracts the separator from the regular expression
`crm-separator', which is not robust for all separators.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Mon, 03 Feb 2025 12:50:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 76028 <at> debbugs.gnu.org (full text, mbox):
> Cc: Juri Linkov <juri <at> linkov.net>
> Date: Mon, 03 Feb 2025 10:27:30 +0100
> From: Daniel Mendler via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> The function `completing-read-multiple' (CRM) can be used to read
> multiple candidates, separated by comma (see the variable
> `crm-separator'). Besides that it acts similarly to `completing-read'.
> To the user it is no obvious if CRM is used.
>
> For years I have used an advice in my configuration which adds a CRM
> indicator to the prompt. For example, the advice turns the
> `describe-face' prompt from "Describe face: " into "[CRM ,] Describe
> face: ", which tells the user that multiple face names are read,
> separated by comma:
>
> #+begin_src emacs-lisp
> (defun crm-indicator (args)
> (defvar crm-separator)
> (cons (format "[%s %s] %s"
> (propertize "CRM" 'face 'error)
> (propertize
> (replace-regexp-in-string
> "\\`\\[.*?]\\*\\|\\[.*?]\\*\\'" ""
> crm-separator)
> 'face 'success)
> (car args))
> (cdr args)))
> (advice-add #'completing-read-multiple :filter-args #'crm-indicator)
> #+end_src
>
> I propose to add such an indicator to CRM by default. Above I have
> chosen the tag "CRM" for its shortness, but a more user friendly
> solution might require a longer more descriptive name. Furthermore the
> code above extracts the separator from the regular expression
> `crm-separator', which is not robust for all separators.
Isn't that too cryptic?
A prompt "Describe face: " which expects one or more faces is not the
best prompt text, and should preferably be improved by implying
multiple faces separated by a comma. Or maybe we need some
specialized help key there, which would spell that out. Or something
else which would be explicit even to users who are using CRM for the
first time in their lives.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Mon, 03 Feb 2025 13:03:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 76028 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Cc: Juri Linkov <juri <at> linkov.net>
>> Date: Mon, 03 Feb 2025 10:27:30 +0100
>> From: Daniel Mendler via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> The function `completing-read-multiple' (CRM) can be used to read
>> multiple candidates, separated by comma (see the variable
>> `crm-separator'). Besides that it acts similarly to `completing-read'.
>> To the user it is no obvious if CRM is used.
>>
>> For years I have used an advice in my configuration which adds a CRM
>> indicator to the prompt. For example, the advice turns the
>> `describe-face' prompt from "Describe face: " into "[CRM ,] Describe
>> face: ", which tells the user that multiple face names are read,
>> separated by comma:
>>
>> #+begin_src emacs-lisp
>> (defun crm-indicator (args)
>> (defvar crm-separator)
>> (cons (format "[%s %s] %s"
>> (propertize "CRM" 'face 'error)
>> (propertize
>> (replace-regexp-in-string
>> "\\`\\[.*?]\\*\\|\\[.*?]\\*\\'" ""
>> crm-separator)
>> 'face 'success)
>> (car args))
>> (cdr args)))
>> (advice-add #'completing-read-multiple :filter-args #'crm-indicator)
>> #+end_src
>>
>> I propose to add such an indicator to CRM by default. Above I have
>> chosen the tag "CRM" for its shortness, but a more user friendly
>> solution might require a longer more descriptive name. Furthermore the
>> code above extracts the separator from the regular expression
>> `crm-separator', which is not robust for all separators.
>
> Isn't that too cryptic?
Yes. For my purposes the cryptic text is sufficient but I would prefer
something more readable if we add such an indicator to
`completing-read-multiple'.
> A prompt "Describe face: " which expects one or more faces is not the
> best prompt text, and should preferably be improved by implying
> multiple faces separated by a comma. Or maybe we need some
> specialized help key there, which would spell that out. Or something
> else which would be explicit even to users who are using CRM for the
> first time in their lives.
Improving every `completing-read-multiple' prompt is an option too.
However I would prefer if we uniformly add an indicator to
`completing-read-multiple' such that multi completion becomes clearly
recognizable. Other options could be a help text in the mode line or a
`minibuffer-message' telling the user about multi completion. In any
case the indicator should be guarded by a customization options such
that it can be disabled or customized.
Daniel
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Mon, 03 Feb 2025 13:04:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 76028 <at> debbugs.gnu.org (full text, mbox):
Daniel Mendler via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:
> I propose to add such an indicator to CRM by default. Above I have
> chosen the tag "CRM" for its shortness, but a more user friendly
> solution might require a longer more descriptive name. Furthermore the
> code above extracts the separator from the regular expression
> `crm-separator', which is not robust for all separators.
How about " [comma-separated list] "?
I'd also propose we should have a defcustom for it, allowing users to
set it to something shorter if they want.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Mon, 03 Feb 2025 13:10:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 76028 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefankangas <at> gmail.com> writes:
> Daniel Mendler via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs <at> gnu.org> writes:
>
>> I propose to add such an indicator to CRM by default. Above I have
>> chosen the tag "CRM" for its shortness, but a more user friendly
>> solution might require a longer more descriptive name. Furthermore the
>> code above extracts the separator from the regular expression
>> `crm-separator', which is not robust for all separators.
>
> How about " [comma-separated list] "?
>
> I'd also propose we should have a defcustom for it, allowing users to
> set it to something shorter if they want.
Yes, this would look good. Note that `crm-separator' can be set to an
arbitrary regular expression. How can we turn `crm-separator' into a
string like "comma-separated list"? Maybe `crm-separator' should be
generalized? One could set it to a cons ("," . "comma-separated list")
with the regexp in the car and the description in the cdr. In cases
where `crm-separator' is a string, we could use a generic string like
"[multi list]".
Daniel
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Mon, 03 Feb 2025 13:17:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 76028 <at> debbugs.gnu.org (full text, mbox):
> Cc: Juri Linkov <juri <at> linkov.net>
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Mon, 3 Feb 2025 05:03:12 -0800
>
> Daniel Mendler via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs <at> gnu.org> writes:
>
> > I propose to add such an indicator to CRM by default. Above I have
> > chosen the tag "CRM" for its shortness, but a more user friendly
> > solution might require a longer more descriptive name. Furthermore the
> > code above extracts the separator from the regular expression
> > `crm-separator', which is not robust for all separators.
>
> How about " [comma-separated list] "?
Or maybe "Describe face (FACE1[,FACE2[,...]]): "
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Mon, 03 Feb 2025 15:52:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 76028 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Daniel Mendler <mail <at> daniel-mendler.de> writes:
> Stefan Kangas <stefankangas <at> gmail.com> writes:
>
>> Daniel Mendler via "Bug reports for GNU Emacs, the Swiss army knife of
>> text editors" <bug-gnu-emacs <at> gnu.org> writes:
>>
>>> I propose to add such an indicator to CRM by default. Above I have
>>> chosen the tag "CRM" for its shortness, but a more user friendly
>>> solution might require a longer more descriptive name. Furthermore the
>>> code above extracts the separator from the regular expression
>>> `crm-separator', which is not robust for all separators.
>>
>> How about " [comma-separated list] "?
>>
>> I'd also propose we should have a defcustom for it, allowing users to
>> set it to something shorter if they want.
>
> Yes, this would look good. Note that `crm-separator' can be set to an
> arbitrary regular expression. How can we turn `crm-separator' into a
> string like "comma-separated list"? Maybe `crm-separator' should be
> generalized? One could set it to a cons ("," . "comma-separated list")
> with the regexp in the car and the description in the cdr. In cases
> where `crm-separator' is a string, we could use a generic string like
> "[multi list]".
I have attached a patch to this mail which implements this proposal.
Daniel
[0001-completing-read-multiple-CRM-indication-and-prompt-c.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Mon, 03 Feb 2025 18:06:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 76028 <at> debbugs.gnu.org (full text, mbox):
>> > I propose to add such an indicator to CRM by default. Above I have
>> > chosen the tag "CRM" for its shortness, but a more user friendly
>> > solution might require a longer more descriptive name. Furthermore the
>> > code above extracts the separator from the regular expression
>> > `crm-separator', which is not robust for all separators.
>>
>> How about " [comma-separated list] "?
>
> Or maybe "Describe face (FACE1[,FACE2[,...]]): "
I see no more descriptive prompt that providing an example,
maybe with lower-case like all faces:
Describe face (face1,face2,...):
A more generalized prompt would make this less clear, e.g.
Describe face (separator ‘,’):
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Mon, 03 Feb 2025 18:38:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 76028 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>>> > I propose to add such an indicator to CRM by default. Above I have
>>> > chosen the tag "CRM" for its shortness, but a more user friendly
>>> > solution might require a longer more descriptive name. Furthermore the
>>> > code above extracts the separator from the regular expression
>>> > `crm-separator', which is not robust for all separators.
>>>
>>> How about " [comma-separated list] "?
>>
>> Or maybe "Describe face (FACE1[,FACE2[,...]]): "
>
> I see no more descriptive prompt that providing an example,
> maybe with lower-case like all faces:
>
> Describe face (face1,face2,...):
>
> A more generalized prompt would make this less clear, e.g.
>
> Describe face (separator ‘,’):
Giving an example does not solve the general issue of a uniform CRM
indication for all `completing-read-multiple' calls. In the Emacs code
base `completing-read-multiple' is not used widely but it is used in
other packages, which we cannot update at once.
I find Stefan's suggestion of [comma-separated list] quite nice. See the
patch I have sent in the other mail. Maybe we could use the
[comma-separated list] indicator as fallback if a
`completing-read-multiple' call does not provide examples on its own?
Another possibility might be to use the completion category and the
separator string and convert that to an example, e.g., category face
would yield the prompt "Describe face (face1,face2,...):".
Daniel
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Tue, 04 Feb 2025 08:07:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 76028 <at> debbugs.gnu.org (full text, mbox):
>> Describe face (face1,face2,...):
>>
>> A more generalized prompt would make this less clear, e.g.
>>
>> Describe face (separator ‘,’):
>
> Giving an example does not solve the general issue of a uniform CRM
> indication for all `completing-read-multiple' calls. In the Emacs code
> base `completing-read-multiple' is not used widely but it is used in
> other packages, which we cannot update at once.
Wouldn't addition of more text to the prompt break these packages
in some way? Maybe only those that rely on the fixed format
like minibuf-eldef.el that is quite rare.
> I find Stefan's suggestion of [comma-separated list] quite nice. See the
> patch I have sent in the other mail. Maybe we could use the
> [comma-separated list] indicator as fallback if a
> `completing-read-multiple' call does not provide examples on its own?
The only problem with the patch is that it would be better
to leave the existing format of the variable 'crm-separator'
to avoid possible backward-compatibility problems,
and then add a new variable or two for the separator
and its description.
> Another possibility might be to use the completion category and the
> separator string and convert that to an example, e.g., category face
> would yield the prompt "Describe face (face1,face2,...):".
Maybe then it's possible to provide the separator and its description
in the metadata?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Tue, 04 Feb 2025 08:29:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 76028 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>>> Describe face (face1,face2,...):
>>>
>>> A more generalized prompt would make this less clear, e.g.
>>>
>>> Describe face (separator ‘,’):
>>
>> Giving an example does not solve the general issue of a uniform CRM
>> indication for all `completing-read-multiple' calls. In the Emacs code
>> base `completing-read-multiple' is not used widely but it is used in
>> other packages, which we cannot update at once.
>
> Wouldn't addition of more text to the prompt break these packages
> in some way? Maybe only those that rely on the fixed format
> like minibuf-eldef.el that is quite rare.
I have not seen many such packages which rely on the prompt format, but
yes, one should check the ones like minibuf-eldef.el. I have used my
[CRM,] indicator advice for a long time without big problems.
>> I find Stefan's suggestion of [comma-separated list] quite nice. See the
>> patch I have sent in the other mail. Maybe we could use the
>> [comma-separated list] indicator as fallback if a
>> `completing-read-multiple' call does not provide examples on its own?
>
> The only problem with the patch is that it would be better
> to leave the existing format of the variable 'crm-separator'
> to avoid possible backward-compatibility problems,
> and then add a new variable or two for the separator
> and its description.
Yes, the change of format could be a problem. However if one uses
multiple variables one can easily forget to bind or configure them
together, which leads to bugs or an inconsistency. Currently there is
code, also third-party code, which let-binds a custom crm-separator but
of course not the other variables, such that there would be an
inconsistency immediately if we introduce the new variables. Therefore I
would stick to a single variable. We could also introduce a new variable
crm-config with the proposed list format which is used if crm-separator
is nil. crm-separator will be nil by default and marked obsolete.
Another more tricky approach would be to attach text properties to
crm-separator which carry the additional data. This would be backward-
and forward-compatible also for third-party code, but maybe not very
elegant. What do you think?
>> Another possibility might be to use the completion category and the
>> separator string and convert that to an example, e.g., category face
>> would yield the prompt "Describe face (face1,face2,...):".
>
> Maybe then it's possible to provide the separator and its description
> in the metadata?
This would be more intrusive. Also the question is if the crm-separator
is truly bound to the completion table, or if it should be possible to
reuse the same table with different separators.
Daniel
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Tue, 04 Feb 2025 18:27:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 76028 <at> debbugs.gnu.org (full text, mbox):
> Another more tricky approach would be to attach text properties to
> crm-separator which carry the additional data. This would be backward-
> and forward-compatible also for third-party code, but maybe not very
> elegant. What do you think?
Although text properties are not customizable, this should not be
a problem for third-party packages. And crm-separator is a variable,
not a defcustom.
>>> Another possibility might be to use the completion category and the
>>> separator string and convert that to an example, e.g., category face
>>> would yield the prompt "Describe face (face1,face2,...):".
>>
>> Maybe then it's possible to provide the separator and its description
>> in the metadata?
>
> This would be more intrusive. Also the question is if the crm-separator
> is truly bound to the completion table, or if it should be possible to
> reuse the same table with different separators.
Then it's possible to override the separator. But anyway it seems
text properties are the least intrusive approach.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Tue, 04 Feb 2025 18:58:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 76028 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Juri Linkov <juri <at> linkov.net> writes:
>> Another more tricky approach would be to attach text properties to
>> crm-separator which carry the additional data. This would be backward-
>> and forward-compatible also for third-party code, but maybe not very
>> elegant. What do you think?
>
> Although text properties are not customizable, this should not be
> a problem for third-party packages. And crm-separator is a variable,
> not a defcustom.
>
>>>> Another possibility might be to use the completion category and the
>>>> separator string and convert that to an example, e.g., category face
>>>> would yield the prompt "Describe face (face1,face2,...):".
>>>
>>> Maybe then it's possible to provide the separator and its description
>>> in the metadata?
>>
>> This would be more intrusive. Also the question is if the crm-separator
>> is truly bound to the completion table, or if it should be possible to
>> reuse the same table with different separators.
>
> Then it's possible to override the separator. But anyway it seems
> text properties are the least intrusive approach.
It seems so. The patch gets quite short. I have attached the updated
patch to this mail.
Daniel
[0001-completing-read-multiple-CRM-indication-and-prompt-c.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Thu, 06 Feb 2025 17:26:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 76028 <at> debbugs.gnu.org (full text, mbox):
>> But anyway it seems text properties are the least intrusive approach.
>
> It seems so. The patch gets quite short. I have attached the updated
> patch to this mail.
Thanks, I could push if there are no more objections,
and no NEWS required for this change.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Thu, 06 Feb 2025 22:25:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 76028 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>>> But anyway it seems text properties are the least intrusive approach.
>>
>> It seems so. The patch gets quite short. I have attached the updated
>> patch to this mail.
>
> Thanks, I could push if there are no more objections,
> and no NEWS required for this change.
LGTM.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Fri, 07 Feb 2025 07:01:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 76028 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 76028 <at> debbugs.gnu.org, Stefan Kangas
> <stefankangas <at> gmail.com>
> Date: Thu, 06 Feb 2025 19:24:13 +0200
>
> >> But anyway it seems text properties are the least intrusive approach.
> >
> > It seems so. The patch gets quite short. I have attached the updated
> > patch to this mail.
>
> Thanks, I could push if there are no more objections,
> and no NEWS required for this change.
I think this does have to be called out in NEWS, including the new
user option. In a sense, this is an incompatible behavior change, so
we cannot introduce it silently.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Fri, 07 Feb 2025 09:45:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 76028 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Juri Linkov <juri <at> linkov.net>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 76028 <at> debbugs.gnu.org, Stefan Kangas
>> <stefankangas <at> gmail.com>
>> Date: Thu, 06 Feb 2025 19:24:13 +0200
>>
>> >> But anyway it seems text properties are the least intrusive approach.
>> >
>> > It seems so. The patch gets quite short. I have attached the updated
>> > patch to this mail.
>>
>> Thanks, I could push if there are no more objections,
>> and no NEWS required for this change.
>
> I think this does have to be called out in NEWS, including the new
> user option. In a sense, this is an incompatible behavior change, so
> we cannot introduce it silently.
Agree. I have attached an updated patch to this mail, where the change
is announced in the NEWS.
Daniel
[0001-completing-read-multiple-CRM-indication-and-prompt-c.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Fri, 07 Feb 2025 11:53:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 76028 <at> debbugs.gnu.org (full text, mbox):
> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: Juri Linkov <juri <at> linkov.net>, 76028 <at> debbugs.gnu.org,
> stefankangas <at> gmail.com
> Date: Fri, 07 Feb 2025 10:44:49 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > I think this does have to be called out in NEWS, including the new
> > user option. In a sense, this is an incompatible behavior change, so
> > we cannot introduce it silently.
>
> Agree. I have attached an updated patch to this mail, where the change
> is announced in the NEWS.
Thanks, I have a few minor comments below.
> ++++
The "+++" marker means the manuals weer updated with this information,
which is not true in this case. If you think this should be described
in the ELisp manual, please include a patch for that. If you think
this is too minor to be in the manual, please mark the NEWS entry with
"---" instead.
> +*** New user option 'crm-prompt'.
> +This option configures the prompt of 'completing-read-multiple'. By
> +default the prompt indicates to the user that the completion accepts a
> +comma-separated list.
Two spaces between sentences, please.
More importantly, it sounds like you tried to describe both the
changes to 'completing-read-multiple' and the new option. I think it
would be better to describe them in two separate entries. In any
case, the entry for 'crm-prompt' should describe the default value.
> The variable 'crm-separator' carries the prompt
> +description and the separator string as text properties.
I didn't understand this sentence: what do you mean by "carries" here?
I guess a more detailed description is needed for this part.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Fri, 07 Feb 2025 12:25:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 76028 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Daniel Mendler <mail <at> daniel-mendler.de>
>> Cc: Juri Linkov <juri <at> linkov.net>, 76028 <at> debbugs.gnu.org,
>> stefankangas <at> gmail.com
>> Date: Fri, 07 Feb 2025 10:44:49 +0100
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > I think this does have to be called out in NEWS, including the new
>> > user option. In a sense, this is an incompatible behavior change, so
>> > we cannot introduce it silently.
>>
>> Agree. I have attached an updated patch to this mail, where the change
>> is announced in the NEWS.
>
> Thanks, I have a few minor comments below.
Thanks. I have attached an updated patch with an improved NEWS entry to
this mail. Also thank you for the explanation regarding --- and +++.
Daniel
[0001-completing-read-multiple-CRM-indication-and-prompt-c.patch (text/x-diff, attachment)]
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Sat, 15 Feb 2025 11:41:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Daniel Mendler <mail <at> daniel-mendler.de>
:
bug acknowledged by developer.
(Sat, 15 Feb 2025 11:41:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 76028-done <at> debbugs.gnu.org (full text, mbox):
> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: juri <at> linkov.net, 76028 <at> debbugs.gnu.org, stefankangas <at> gmail.com
> Date: Fri, 07 Feb 2025 13:24:04 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Daniel Mendler <mail <at> daniel-mendler.de>
> >> Cc: Juri Linkov <juri <at> linkov.net>, 76028 <at> debbugs.gnu.org,
> >> stefankangas <at> gmail.com
> >> Date: Fri, 07 Feb 2025 10:44:49 +0100
> >>
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >>
> >> > I think this does have to be called out in NEWS, including the new
> >> > user option. In a sense, this is an incompatible behavior change, so
> >> > we cannot introduce it silently.
> >>
> >> Agree. I have attached an updated patch to this mail, where the change
> >> is announced in the NEWS.
> >
> > Thanks, I have a few minor comments below.
>
> Thanks. I have attached an updated patch with an improved NEWS entry to
> this mail. Also thank you for the explanation regarding --- and +++.
Now installed on master, and closing the bug.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Thu, 20 Feb 2025 08:00:02 GMT)
Full text and
rfc822 format available.
Message #67 received at 76028 <at> debbugs.gnu.org (full text, mbox):
> Agree. I have attached an updated patch to this mail, where the change
> is announced in the NEWS.
I noticed that in the packages list '/ k' now shows the prompt:
[comma-separated list] Keywords (comma separated):
Maybe there are more such prompts that need fixing?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Thu, 20 Feb 2025 08:15:03 GMT)
Full text and
rfc822 format available.
Message #70 received at 76028 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>> Agree. I have attached an updated patch to this mail, where the change
>> is announced in the NEWS.
>
> I noticed that in the packages list '/ k' now shows the prompt:
>
> [comma-separated list] Keywords (comma separated):
>
> Maybe there are more such prompts that need fixing?
Yes, I suggest we clean up these prompts if we stumble over them. Do you
want me to send patches, or it might be quicker if you do this directly
for these minor patches on master, without going through patches?
Daniel
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Thu, 20 Feb 2025 10:20:02 GMT)
Full text and
rfc822 format available.
Message #73 received at 76028 <at> debbugs.gnu.org (full text, mbox):
Daniel Mendler <mail <at> daniel-mendler.de> writes:
> Juri Linkov <juri <at> linkov.net> writes:
>
>>> Agree. I have attached an updated patch to this mail, where the change
>>> is announced in the NEWS.
>>
>> I noticed that in the packages list '/ k' now shows the prompt:
>>
>> [comma-separated list] Keywords (comma separated):
>>
>> Maybe there are more such prompts that need fixing?
>
> Yes, I suggest we clean up these prompts if we stumble over them. Do you
> want me to send patches, or it might be quicker if you do this directly
> for these minor patches on master, without going through patches?
Feel free to fix such minor issues directly, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Thu, 20 Feb 2025 17:40:02 GMT)
Full text and
rfc822 format available.
Message #76 received at 76028 <at> debbugs.gnu.org (full text, mbox):
>>>> Agree. I have attached an updated patch to this mail, where the change
>>>> is announced in the NEWS.
>>>
>>> I noticed that in the packages list '/ k' now shows the prompt:
>>>
>>> [comma-separated list] Keywords (comma separated):
>>>
>>> Maybe there are more such prompts that need fixing?
>>
>> Yes, I suggest we clean up these prompts if we stumble over them. Do you
>> want me to send patches, or it might be quicker if you do this directly
>> for these minor patches on master, without going through patches?
>
> Feel free to fix such minor issues directly, thanks.
I searched for more occurrences and fixed all them on master.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76028
; Package
emacs
.
(Thu, 20 Feb 2025 17:42:02 GMT)
Full text and
rfc822 format available.
Message #79 received at 76028 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>>>>> Agree. I have attached an updated patch to this mail, where the change
>>>>> is announced in the NEWS.
>>>>
>>>> I noticed that in the packages list '/ k' now shows the prompt:
>>>>
>>>> [comma-separated list] Keywords (comma separated):
>>>>
>>>> Maybe there are more such prompts that need fixing?
>>>
>>> Yes, I suggest we clean up these prompts if we stumble over them. Do you
>>> want me to send patches, or it might be quicker if you do this directly
>>> for these minor patches on master, without going through patches?
>>
>> Feel free to fix such minor issues directly, thanks.
>
> I searched for more occurrences and fixed all them on master.
Thank you!
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 21 Mar 2025 11:24:11 GMT)
Full text and
rfc822 format available.
This bug report was last modified 84 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.