GNU bug report logs -
#74409
30.0.92; customize buffer for bibtex-biblatex-entry-alist also shows unformatted variable value
Previous Next
Reported by: Roland Winkler <winkler <at> gnu.org>
Date: Sun, 17 Nov 2024 22:45:02 UTC
Severity: normal
Found in version 30.0.92
Done: Roland Winkler <winkler <at> gnu.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 74409 in the body.
You can then email your comments to 74409 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#74409; Package
emacs.
(Sun, 17 Nov 2024 22:45:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Roland Winkler <winkler <at> gnu.org>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 17 Nov 2024 22:45:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
In emacs -Q load BibTeX mode and run
M-x customize-variable RET
bibtex-biblatex-entry-alist RET
The top of the customize buffer is clogged with the unformatted
variable value that hides the actual customization buffer.
I do not know whether this is related to bug #53606. Like bug #53606,
the problem did not exist in earlier version of emacs (say, emacs 26.3).
But it started some time ago (confirmed with emacs 28.2).
Nothing changed on the side of BibTeX mode back then.
In GNU Emacs 30.0.92 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.16.0) of 2024-11-01 built on regnitz
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Debian GNU/Linux 12 (bookworm)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74409; Package
emacs.
(Sun, 24 Nov 2024 10:43:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 74409 <at> debbugs.gnu.org (full text, mbox):
> From: Roland Winkler <winkler <at> gnu.org>
> Date: Sun, 17 Nov 2024 16:42:10 -0600
>
>
> In emacs -Q load BibTeX mode and run
>
> M-x customize-variable RET
> bibtex-biblatex-entry-alist RET
>
> The top of the customize buffer is clogged with the unformatted
> variable value that hides the actual customization buffer.
>
> I do not know whether this is related to bug #53606. Like bug #53606,
> the problem did not exist in earlier version of emacs (say, emacs 26.3).
> But it started some time ago (confirmed with emacs 28.2).
> Nothing changed on the side of BibTeX mode back then.
It looks like the value of the variable was not shown in Emacs 26, but
is shown now. Bisecting to find the offending commit would be highly
appreciated.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74409; Package
emacs.
(Fri, 10 Jan 2025 14:32:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 74409 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Roland Winkler <winkler <at> gnu.org>
>> Date: Sun, 17 Nov 2024 16:42:10 -0600
>>
>>
>> In emacs -Q load BibTeX mode and run
>>
>> M-x customize-variable RET
>> bibtex-biblatex-entry-alist RET
>>
>> The top of the customize buffer is clogged with the unformatted
>> variable value that hides the actual customization buffer.
>>
>> I do not know whether this is related to bug #53606. Like bug #53606,
>> the problem did not exist in earlier version of emacs (say, emacs 26.3).
>> But it started some time ago (confirmed with emacs 28.2).
>> Nothing changed on the side of BibTeX mode back then.
>
> It looks like the value of the variable was not shown in Emacs 26, but
> is shown now. Bisecting to find the offending commit would be highly
> appreciated.
>
> Thanks.
I can't build Emacs 26 for some reason, but it's very likely that this
is a result of my change for Bug#35133:
commit 897b8561cdc856fb40b2a3c6f29230849aaf4a34
Author: Mauro Aranda <maurooaranda <at> gmail.com>
Date: Sun Dec 13 10:44:30 2020 -0300
Stop dropping the tag when creating the custom-variable widget
* lisp/cus-edit.el (custom-variable-value-create): Obey the specified
tag format when creating the variable tag, but stop dropping the tag
format for the variable's type widget, since the tag can be used to
give useful information to the user about the variable. (Bug#35133)
The lazy widget (from which the widget bibtex-entry-alist derives),
prints its :tag. Since there's no explicit :tag in bibtex-entry-alist,
and neither in the definition of the lazy widget, all of the widget
value gets printed.
Before my change, we dropped the tag (so no value printing for
bibtex-biblatex-entry-alist), but that wasn't a very good idea (see
Bug#35133), since we were overriding valuable info the defcustom writer
could have given to the Customize user.
I tend to think that we should fix these problems by giving appropriate
tags to the widgets used for user options, and leaving the cus-edit.el
code as it is.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74409; Package
emacs.
(Fri, 10 Jan 2025 14:49:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 74409 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 10 Jan 2025 11:31:28 -0300
> Cc: 74409 <at> debbugs.gnu.org
> From: Mauro Aranda <maurooaranda <at> gmail.com>
>
> I tend to think that we should fix these problems by giving appropriate
> tags to the widgets used for user options, and leaving the cus-edit.el
> code as it is.
Such a solution would be fine with me, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74409; Package
emacs.
(Fri, 10 Jan 2025 15:09:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 74409 <at> debbugs.gnu.org (full text, mbox):
On Fri, Jan 10 2025, Mauro Aranda wrote:
> I tend to think that we should fix these problems by giving appropriate
> tags to the widgets used for user options, and leaving the cus-edit.el
> code as it is.
I never understood in full glory how these widgets work with defcustom.
What would be a minimal example what the missing tag could look like for
bibtex-biblatex-entry-alist? (Is this documented in the elisp manual?)
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74409; Package
emacs.
(Fri, 10 Jan 2025 15:35:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 74409 <at> debbugs.gnu.org (full text, mbox):
Roland Winkler <winkler <at> gnu.org> writes:
> On Fri, Jan 10 2025, Mauro Aranda wrote:
>> I tend to think that we should fix these problems by giving appropriate
>> tags to the widgets used for user options, and leaving the cus-edit.el
>> code as it is.
>
> I never understood in full glory how these widgets work with defcustom.
> What would be a minimal example what the missing tag could look like for
> bibtex-biblatex-entry-alist? (Is this documented in the elisp manual?)
>
> Thanks.
Since the variable says it's an alist, I'd say:
(define-widget 'bibtex-entry-alist 'lazy
"Format of `bibtex-BibTeX-entry-alist' and friends."
:tag "Alist"
:type '(repeat
(choice (group :tag "Alias"
(string :tag "Entry type")
(string :tag "Documentation")
(string :tag "Alias"))
(group :tag "Entry"
(string :tag "Entry type")
(string :tag "Documentation")
(repeat :tag "Required fields" bibtex-field-list)
(repeat :tag "Crossref fields" bibtex-field-list)
(repeat :tag "Optional fields"
bibtex-field-list)))))
And maybe it looks better if you do:
(define-widget 'bibtex-entry-alist 'lazy
"Format of `bibtex-BibTeX-entry-alist' and friends."
:tag "Alist"
:type '(repeat
:format "\n%v" ;; I think this looks better.
(choice (group :tag "Alias"
(string :tag "Entry type")
(string :tag "Documentation")
(string :tag "Alias"))
(group :tag "Entry"
(string :tag "Entry type")
(string :tag "Documentation")
(repeat :tag "Required fields" bibtex-field-list)
(repeat :tag "Crossref fields" bibtex-field-list)
(repeat :tag "Optional fields"
bibtex-field-list)))))
Both :format and :tag keywords are documented under:
15.4.4 Type Keywords
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74409; Package
emacs.
(Fri, 10 Jan 2025 16:02:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 74409 <at> debbugs.gnu.org (full text, mbox):
On Fri, Jan 10 2025, Mauro Aranda wrote:
> Since the variable says it's an alist, I'd say:
Thanks, these real-world examples are very helpful, I'll try this out.
> Both :format and :tag keywords are documented under: 15.4.4 Type
> Keywords
My understanding of what is documented there has been that these
keywords are certainly useful, but always optional. But this bug report
shows that not having the :tag keyword can have rather undesirable side
effects. So I was wondering whether the documentation could gently
indicate that not having a :tag keyword should be avoided (in what
context?). -- But I do not understand enough details whether the fairly
complex customization declarations for bibtex-biblatex-entry-alist that
triggered this bug report are too specific a use case to justify this.
What you say suggests to me that the present bug report #74409 has
nothing to do with #53606. The latter has bothered me yet more. If you
happen to be able to shine light on that one, too, that would be great.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74409; Package
emacs.
(Fri, 10 Jan 2025 17:33:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 74409 <at> debbugs.gnu.org (full text, mbox):
Roland Winkler <winkler <at> gnu.org> writes:
> On Fri, Jan 10 2025, Mauro Aranda wrote:
>> Both :format and :tag keywords are documented under: 15.4.4 Type
>> Keywords
>
> My understanding of what is documented there has been that these
> keywords are certainly useful, but always optional. But this bug report
> shows that not having the :tag keyword can have rather undesirable side
> effects. So I was wondering whether the documentation could gently
> indicate that not having a :tag keyword should be avoided (in what
> context?). -- But I do not understand enough details whether the fairly
> complex customization declarations for bibtex-biblatex-entry-alist that
> triggered this bug report are too specific a use case to justify this.
I see, yes. Docs could be improved here. Not having a :tag, is almost
never a good idea. This would be specific to the section Defining New
Types.
> What you say suggests to me that the present bug report #74409 has
> nothing to do with #53606. The latter has bothered me yet more. If you
> happen to be able to shine light on that one, too, that would be great.
Yes, nothing to do with it. I think the patch to wid-edit.el I posted
back in 2023 is the right approach to improving that situation.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74409; Package
emacs.
(Sat, 11 Jan 2025 04:44:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 74409 <at> debbugs.gnu.org (full text, mbox):
I fixed this in bibtex.el following your suggestions. Now things work
as expected. Commit 2f63dab3ee566f
> Docs could be improved here. Not having a :tag, is almost never a
> good idea. This would be specific to the section Defining New Types.
I am keeping this bug open. Can you possibly provide a documentation
patch regarding the :tag keyword for new types? Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74409; Package
emacs.
(Sat, 11 Jan 2025 20:31:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 74409 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Roland Winkler <winkler <at> gnu.org> writes:
>> Docs could be improved here. Not having a :tag, is almost never a
>> good idea. This would be specific to the section Defining New Types.
>
> I am keeping this bug open. Can you possibly provide a documentation
> patch regarding the :tag keyword for new types? Thanks.
Here's an attempt. Please review.
[0001-Emphasize-the-use-of-tag-for-new-customization-types.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74409; Package
emacs.
(Sat, 11 Jan 2025 21:02:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 74409 <at> debbugs.gnu.org (full text, mbox):
On Sat, Jan 11 2025, Mauro Aranda wrote:
>> Can you possibly provide a documentation patch regarding the :tag
>> keyword for new types?
>
> Here's an attempt. Please review.
Thanks, from my perspective, this is a big improvment.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74409; Package
emacs.
(Sun, 12 Jan 2025 05:41:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 74409 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 11 Jan 2025 17:30:15 -0300
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 74409 <at> debbugs.gnu.org
> From: Mauro Aranda <maurooaranda <at> gmail.com>
>
> Roland Winkler <winkler <at> gnu.org> writes:
>
> >> Docs could be improved here. Not having a :tag, is almost never a
> >> good idea. This would be specific to the section Defining New Types.
> >
> > I am keeping this bug open. Can you possibly provide a documentation
> > patch regarding the :tag keyword for new types? Thanks.
>
> Here's an attempt. Please review.
Thanks, a couple of typo corrections below.
> @item :tag @var{tag}
> Use @var{tag} (a string) as the tag for the value (or part of the value)
> -that corresponds to this type.
> +that corresponds to this type. It's important to provide an informative
> +tag for the customization interface, specially if you're using the
^^^^^^^^^
"especially"
> +@code{restricted-sexp} type or if you're defining a new type.
> +@xref{Defining New Types}.
>
> @item :doc @var{doc}
> @kindex doc <at> r{, customization keyword}
> @@ -1349,10 +1352,15 @@ Defining New Types
> being either a string, or a cons-cell whose car and cdr are themselves
> both @code{binary-tree-of-string}. Note the reference to the widget
> type we are currently in the process of defining. The @code{:tag}
> -attribute is a string to name the widget in the user interface, and the
> -@code{:offset} argument is there to ensure that child nodes are
> -indented four spaces relative to the parent node, making the tree
> -structure apparent in the customization buffer.
> +is another important keyword argument because we are using the
> +@code{lazy} widget for our new widget. By default, the @code{lazy}
> +widget doesn't have a tag, and in its abscence the customization buffer
^^^^^^^^
"absence"
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74409; Package
emacs.
(Sun, 12 Jan 2025 10:16:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 74409 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Sat, 11 Jan 2025 17:30:15 -0300
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 74409 <at> debbugs.gnu.org
>> From: Mauro Aranda <maurooaranda <at> gmail.com>
>>
>> Roland Winkler <winkler <at> gnu.org> writes:
>>
>> >> Docs could be improved here. Not having a :tag, is almost never a
>> >> good idea. This would be specific to the section Defining New
Types.
>> >
>> > I am keeping this bug open. Can you possibly provide a documentation
>> > patch regarding the :tag keyword for new types? Thanks.
>>
>> Here's an attempt. Please review.
>
> Thanks, a couple of typo corrections below.
Thanks Eli, here's the updated patch.
[0001-Emphasize-the-use-of-tag-for-new-customization-types.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74409; Package
emacs.
(Sun, 12 Jan 2025 16:46:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 74409 <at> debbugs.gnu.org (full text, mbox):
On Sun, Jan 12 2025, Mauro Aranda wrote:
> Thanks Eli, here's the updated patch.
Thanks. Can you install this? Otherwise, I can do it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74409; Package
emacs.
(Sun, 12 Jan 2025 18:28:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 74409 <at> debbugs.gnu.org (full text, mbox):
Roland Winkler <winkler <at> gnu.org> writes:
> On Sun, Jan 12 2025, Mauro Aranda wrote:
>> Thanks Eli, here's the updated patch.
>
> Thanks. Can you install this? Otherwise, I can do it.
Done. Although I pushed it to master, and I realized right after that I
should've pushed it to emacs-30. Feeling rusty.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74409; Package
emacs.
(Sun, 12 Jan 2025 19:27:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 74409 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 12 Jan 2025 15:27:00 -0300
> Cc: 74409 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> From: Mauro Aranda <maurooaranda <at> gmail.com>
>
> Roland Winkler <winkler <at> gnu.org> writes:
>
> > On Sun, Jan 12 2025, Mauro Aranda wrote:
> >> Thanks Eli, here's the updated patch.
> >
> > Thanks. Can you install this? Otherwise, I can do it.
>
> Done. Although I pushed it to master, and I realized right after that I
> should've pushed it to emacs-30. Feeling rusty.
Thanks, I cherry-picked that to the release branch.
Should this bug be closed now?
Reply sent
to
Roland Winkler <winkler <at> gnu.org>:
You have taken responsibility.
(Sun, 12 Jan 2025 20:02:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Roland Winkler <winkler <at> gnu.org>:
bug acknowledged by developer.
(Sun, 12 Jan 2025 20:02:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 74409-done <at> debbugs.gnu.org (full text, mbox):
On Sun, Jan 12 2025, Eli Zaretskii wrote:
>> Date: Sun, 12 Jan 2025 15:27:00 -0300
>> Cc: 74409 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
>> From: Mauro Aranda <maurooaranda <at> gmail.com>
>>
>> Roland Winkler <winkler <at> gnu.org> writes:
>>
>> > On Sun, Jan 12 2025, Mauro Aranda wrote:
>> >> Thanks Eli, here's the updated patch.
>> >
>> > Thanks. Can you install this? Otherwise, I can do it.
>>
>> Done. Although I pushed it to master, and I realized right after that I
>> should've pushed it to emacs-30. Feeling rusty.
>
> Thanks, I cherry-picked that to the release branch.
>
> Should this bug be closed now?
Thanks, closing.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 10 Feb 2025 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 127 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.