bug#57246: biblatex don't recognize video type entry

bug#57246: biblatex don't recognize video type entry

[Cletip Cletip]

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

Hello
It's all in the object: biblatex does not recognize inputs of type "video".
I think that the bibtex-biblatex-entry-alist variable (and maybe
bibtex-biblatex-field-alist) should be modified

Thanks in advance

[-- Attachment #2: Type: text/html, Size: 273 bytes --]

bug#57246: biblatex don't recognize video type entry

[Lars Ingebrigtsen]

Cletip Cletip <clement020302@gmail.com> writes:

> It's all in the object: biblatex does not recognize inputs of type "video".
> I think that the bibtex-biblatex-entry-alist variable (and maybe
> bibtex-biblatex-field-alist) should be modified

Perhaps Roland has some comments here; added to the CCs.

bug#57246: biblatex don't recognize video type entry

[Roland Winkler]

On Wed, Aug 17 2022, Lars Ingebrigtsen wrote:
> Cletip Cletip <clement020302@gmail.com> writes:
>
>> It's all in the object: biblatex does not recognize inputs of type "video".
>> I think that the bibtex-biblatex-entry-alist variable (and maybe
>> bibtex-biblatex-field-alist) should be modified
>
> Perhaps Roland has some comments here; added to the CCs.

I believe these are non-standard biblatex entries with incomplete
biblatex support.

In Emacs BibTeX mode the problem is here that all biblatex entry types
are defined via the rather "big" user variable
bibtex-biblatex-entry-alist.  So the idea is that users can customize
this variable and define additional entry types.  However, this is not a
very practical strategy.  From a technical perspective, there is still
bug#53606.  Also, as biblatex evolves, the default value of
bibtex-biblatex-entry-alist is continuously updated with each release of
Emacs.  (Usually this refers to small changes concerning biblatex entry
types that are already defined via this variable.)  However, if a user
customizes this variable in whatever way, she will miss the updated
default value when the next release of emacs is shipped.

I believe, these problems are not specific to BibTeX mode.  There are
several "big" user variables in Auctex where I am splicing my custom
elements into an alist instead of using the customize machinery.  This
is not a very user-friendly approach.

Often such "big" user variables are alists.  Sometimes I have been
wondering whether the customize machinery could provide special support
for alists that allows one to modify or add individual cons cells
without touching other cells that are part of the default value.  Then
if a new release of emacs uses updated values for such user variables,
there are less opportunities for how this may collide with individual
customizations.

Would that be useful?

In the present context, a simpler strategy would be to define a new user
variable bibtex-biblatex-extra-entry-alist that complements / overrides
the defaults in bibtex-biblatex-entry-alist.

bug#57246: biblatex don't recognize video type entry

[Stefan Kangas]

Roland Winkler <winkler@gnu.org> writes:

> In Emacs BibTeX mode the problem is here that all biblatex entry types
> are defined via the rather "big" user variable
> bibtex-biblatex-entry-alist.  So the idea is that users can customize
> this variable and define additional entry types.  However, this is not a
> very practical strategy.  From a technical perspective, there is still
> bug#53606.  Also, as biblatex evolves, the default value of
> bibtex-biblatex-entry-alist is continuously updated with each release of
> Emacs.  (Usually this refers to small changes concerning biblatex entry
> types that are already defined via this variable.)  However, if a user
> customizes this variable in whatever way, she will miss the updated
> default value when the next release of emacs is shipped.

How about just having two variables instead?  One for users, and one for
the mode itself.

For an example, see `dired-guess-shell-alist-default' and
`dired-guess-shell-alist-user'.

bug#57246: biblatex don't recognize video type entry

[Roland Winkler]

On Wed, Aug 17 2022, Stefan Kangas wrote:
> How about just having two variables instead?  One for users, and one for
> the mode itself.

That's certainly an option (see the last paragraph of my message).

Is there a possibility to declare the customizability of a variable
obsolete?  bibtex-biblatex-entry-alist has been around as a user
variable for more than ten years and bibtex-BibTeX-entry-alist for yet
many more years.  I doubt that many people ever tried to customize these
variables.  Still, if we add new dedicated user variables, it would be
nice to tell users that the customization of the old variables has been
depreciated.

bug#57246: biblatex don't recognize video type entry

[Arash Esbati]

Roland Winkler <winkler@gnu.org> writes:

> On Wed, Aug 17 2022, Stefan Kangas wrote:
>> How about just having two variables instead?  One for users, and one for
>> the mode itself.
>
> That's certainly an option (see the last paragraph of my message).
>
> Is there a possibility to declare the customizability of a variable
> obsolete?  bibtex-biblatex-entry-alist has been around as a user
> variable for more than ten years and bibtex-BibTeX-entry-alist for yet
> many more years.  I doubt that many people ever tried to customize these
> variables.  Still, if we add new dedicated user variables, it would be
> nice to tell users that the customization of the old variables has been
> depreciated.

My apologies if I'm missing the obvious, but why not leave
bibtex-biblatex-entry-alist customizable and introduce an internal
variable, say bibtex-biblatex-entry-alist-builtin and move the current
content into that one?  Then define a function like this:

(defun bibtex-biblatex-entry-alist ()
  (append bibtex-biblatex-entry-alist
          bibtex-biblatex-entry-alist-builtin))

where user entries overrule the builtin ones.  This is what AUCTeX
mostly does for the "big" variables.

Best, Arash

bug#57246: biblatex don't recognize video type entry

[Stefan Kangas]

Roland Winkler <winkler@gnu.org> writes:

> Is there a possibility to declare the customizability of a variable
> obsolete?  bibtex-biblatex-entry-alist has been around as a user
> variable for more than ten years and bibtex-BibTeX-entry-alist for yet
> many more years.  I doubt that many people ever tried to customize these
> variables.  Still, if we add new dedicated user variables, it would be
> nice to tell users that the customization of the old variables has been
> depreciated.

No, but you can mark the variable itself obsolete.

IOW, you would mark the old variable as obsolete, add some way to handle
it for backwards-compatibility, then introduce the two new variables.

So if the new variables are named `bibtex-biblatex-entry-user-alist' and
`bibtex-biblatex-entry-default-alist':

    (make-obsolete-variable 'bibtex-biblatex-entry-alist
       bibtex-biblatex-entry-user-alist "29.1")

bug#57246: biblatex don't recognize video type entry

[Roland Winkler]

On Thu, Aug 18 2022, Arash Esbati wrote:
> My apologies if I'm missing the obvious, but why not leave
> bibtex-biblatex-entry-alist customizable and introduce an internal
> variable, say bibtex-biblatex-entry-alist-builtin and move the current
> content into that one?

As biblatex evolves, the default value of bibtex-biblatex-entry-alist
requires minor updates with each release of emacs.  If a user has customized
this variable to modify or add just one cell of this alist. this stores
the entire value of this variable in her emacs init file.  Then she
misses the updates that appear in new releases of emacs.

That's why I suggested that the customize machinery should allow users
to modify or add individiual cells of an alist without storing the
entire alist in the user's init file.