Received: (at 51621) by debbugs.gnu.org; 6 Jan 2025 19:50:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 06 14:50:06 2025
Received: from localhost ([127.0.0.1]:40191 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tUt6z-0007Jx-HQ
for submit <at> debbugs.gnu.org; Mon, 06 Jan 2025 14:50:06 -0500
Received: from mail-yb1-xb31.google.com ([2607:f8b0:4864:20::b31]:55567)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <leo.stein@HIDDEN>)
id 1tUt6w-0007IP-MT
for 51621 <at> debbugs.gnu.org; Mon, 06 Jan 2025 14:50:03 -0500
Received: by mail-yb1-xb31.google.com with SMTP id
3f1490d57ef6-e5372a2fbddso22048280276.3
for <51621 <at> debbugs.gnu.org>; Mon, 06 Jan 2025 11:50:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1736193002; x=1736797802; darn=debbugs.gnu.org;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=UvYJODxzIXVBJTYNgNwjCReaGmorKfM9pUW5ShrQjm8=;
b=XFLGElz82LVWP2ioxnL08CzMbMZ1F0NddNK4+UNn/Y75Y76AXO9CNkmlb3asZ81vBt
RRnLHolbYDbydyAzUwWUSaV5ZT4cev3ccrobtJdvbEBouQ4ftaAbGOLy0JUA5gi7b3tj
0UltnC1yFIIWzavLSMwFz8DuOJ1bWPoctBSDgi50MKHg2ps2e/vCqrBQkqXN91FccGc4
FHFhadoutyLSIG+WWDRvqRGCKGXHOXVceFjWRDJCTN91w4Xav77yJChipEN/vgifVGyx
hyk3E9kPqTyehc5MUXVfrntPCau7haA4Oi28QJm/AjE6nBA53+cqFUcvDxrbgj/5ZgJR
kUqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1736193002; x=1736797802;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=UvYJODxzIXVBJTYNgNwjCReaGmorKfM9pUW5ShrQjm8=;
b=H8VBEtv0h+wB+E9XO3sneDZTKKBY3G0Tqav9VCcvWQg5gi1PdkrwYCpEChtYFiz63s
wzKZ1HU+2jhrWcYG4tL0TR9Zy+vmy/UAbAvoAeEAKb22npjG/6w190Nu6au7kmWV2aBu
a64zpnpF5YdOJq+lsTh3p8KlTBFFZgRjdSsURnvVzlm4DjuP24Cm5C0RmFiDe7plJREO
Ai2/144xFOuGQDfHH9JiZgXif636aqIcPIlR3kH0iAuVJiy6UdVuzQLNxVGGZrZUfoUo
DDFnYq9G5M9dQplN6M+vkQyeyrB9g0AYX9XWujUE4X/EsulytXFyPgxe2WyIoZQsqbGS
Ldbw==
X-Gm-Message-State: AOJu0Yyc0gadUuT9h3Wdu3LepsSSOqdLRm5deJpxXx2+Up/airXibnH/
vMcMpgq32WVudgJFEZiYSdC3AFmMS5myUeZ9h46AY99j9wgrqcPDHnTwozCVKteNEc7iwufFD83
MT557CkRNFXOlDXCJrFcvUQ8ajpA=
X-Gm-Gg: ASbGncuCJZG6kJ262nxY5wtZNVbh2H8cjCLdJIJrqDUw0nbRdK/+HXvv3HmjjQIx9++
2ep/S1nFLEdHoYA7ub5idqNDH5sssmLnHBPx3Bw==
X-Google-Smtp-Source: AGHT+IHNFKwExsi6lEfLB69HlcE8dAZTahx4APYl9TPSmdZ3wYLaStzv7N8MmDWVIJINIqCS7HJfslvwlyBCc0T01d8=
X-Received: by 2002:a05:690c:4c0d:b0:6ef:a08f:8ec0 with SMTP id
00721157ae682-6f3f815b486mr446047587b3.22.1736193001627; Mon, 06 Jan 2025
11:50:01 -0800 (PST)
MIME-Version: 1.0
References: <87mshekwo5.fsf@HIDDEN> <875xmxhi1t.fsf@HIDDEN>
In-Reply-To: <875xmxhi1t.fsf@HIDDEN>
From: Leo Stein <leo.stein@HIDDEN>
Date: Mon, 6 Jan 2025 13:49:45 -0600
X-Gm-Features: AbW1kvZ3oqFQjO6rGJw2eY_rho4D_PJBFDcNCLCBsxW9F0_Fc1sTAtYz34T0sH0
Message-ID: <CAE56pjEruOGVY4AQrZiGv8q-42Lvq7roWrmbQgweCyQvaypSoA@HIDDEN>
Subject: Re: bug#51621: 29.0.50;
bibtex.el biblatex "2.1.3 Non-standard Types" support
To: Roland Winkler <winkler@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000001fa911062b0eef67"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 51621
Cc: Leonard Lausen <leonard@HIDDEN>, 51621 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--0000000000001fa911062b0eef67
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Dear Roland,
Happy new year! I'm glad you are adding more customization. 1. Why is the
standard value of bibtex-BibTeX-aux-entry-alist given as '(("Conference"
"Article in Conference Proceedings" "InProceedings")) ? 2. I still don't
understand the point of making a distinction between "dialects". As I've
tried to emphasize before, which fields are accepted is under the purview
of the bst (for bibtex) or bbx/cbx/lbx file (for biber+biblatex) that the
user will eventually use. That can't be inferred from the contents of a
.bib file; in fact, a .bib file could be used in multiple different
projects with different bst/bbx/cbx/lbx files, all of which allow for
different fields. I still maintain that the best approach is to be
permissive about *parsing* entries in bibtex-parse-entry. That is a
different question from the contents of templates provided by C-c C-e
[KEY], for which of course the mode must know about the structure of each
given entry.
Best
Leo
On Thu, Jan 2, 2025 at 12:00=E2=80=AFAM Roland Winkler <winkler@HIDDEN> wr=
ote:
> On Mon, Dec 02 2024, Roland Winkler wrote:
> > I am currently working on a patch for bibtex-mode that will make it
> > easier for users to customize the entry types known by a dialect,
> > including the possibility to define aliases for entry types. This
> > patch should be installed on master in a few weeks. (I want to test
> > it first.)
>
> I added new variables bibtex-BibTeX-aux-entry-alist and
> bibtex-biblatex-aux-entry-alist that should facilitate the customization
> of entry types. Also, these variables now accept aliases. Please try
> it out.
>
> commit b26418694e8
>
--0000000000001fa911062b0eef67
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Dear Roland,<div><br></div><div>Happy new year! I'm gl=
ad you are adding more customization. 1. Why is the standard value of=C2=A0=
bibtex-BibTeX-aux-entry-alist=C2=A0given as=C2=A0'(("Conference&qu=
ot; "Article in Conference Proceedings" "InProceedings"=
)) ? 2. I still don't understand the point of making a distinction betw=
een "dialects". As I've tried to emphasize before, which fiel=
ds are accepted is=C2=A0under the purview of the bst (for bibtex) or bbx/cb=
x/lbx file (for biber+biblatex) that the user will eventually use. That can=
't be inferred from the contents of a .bib file; in fact, a .bib file c=
ould be used in multiple different projects with different bst/bbx/cbx/lbx =
files, all of which allow for different fields. I still maintain that the b=
est approach is to be permissive about *parsing* entries in=C2=A0bibtex-par=
se-entry. That is a different question from the contents of templates provi=
ded by C-c C-e [KEY], for which of course the mode must know about the stru=
cture of each given entry.</div><div><br></div><div>Best</div><div>Leo</div=
></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr=
" class=3D"gmail_attr">On Thu, Jan 2, 2025 at 12:00=E2=80=AFAM Roland Winkl=
er <<a href=3D"mailto:winkler@HIDDEN">winkler@HIDDEN</a>> wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Dec 02 202=
4, Roland Winkler wrote:<br>
> I am currently working on a patch for bibtex-mode that will make it<br=
>
> easier for users to customize the entry types known by a dialect,<br>
> including the possibility to define aliases for entry types.=C2=A0 Thi=
s<br>
> patch should be installed on master in a few weeks.=C2=A0 (I want to t=
est<br>
> it first.)<br>
<br>
I added new variables bibtex-BibTeX-aux-entry-alist and<br>
bibtex-biblatex-aux-entry-alist that should facilitate the customization<br=
>
of entry types.=C2=A0 Also, these variables now accept aliases.=C2=A0 Pleas=
e try<br>
it out.<br>
<br>
commit b26418694e8<br>
</blockquote></div>
--0000000000001fa911062b0eef67--
bug-gnu-emacs@HIDDEN:bug#51621; Package emacs.
Full text available.Received: (at 51621) by debbugs.gnu.org; 2 Jan 2025 06:00:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 02 01:00:19 2025 Received: from localhost ([127.0.0.1]:42383 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tTEFl-0005Yz-W9 for submit <at> debbugs.gnu.org; Thu, 02 Jan 2025 01:00:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53712) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <winkler@HIDDEN>) id 1tTEFj-0005XF-Q1 for 51621 <at> debbugs.gnu.org; Thu, 02 Jan 2025 01:00:16 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <winkler@HIDDEN>) id 1tTEFe-0004e6-0a; Thu, 02 Jan 2025 01:00:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=LdY0IkMEoXt6jFkFxuGwJ8EXof3G2LnVTreaRjykN7c=; b=EI0t4th8+DJr9WaaZGsE rthoXkFbFj5Gj1yP7oHQGd+HvZ2c8OyIiSf7lTPRF19tkQszS0wqMke/w+aek1b5dhMSNl4hWIIXf xfOlCZpVXgqGvRWF2TO07gNcYZxgBkcqunWCcsn5VfKU7TQw8Ut3I21OKtN/hrB+M97KsgsvNhNvh hr+EMF0sfqd670u29O4t96sngwpAqj+SQBQ0yKeBSEFvo0Ug2hqGx5d3d5tMaLxPI2d/S2xVQg8xl ywH346syMpv1Zhjx4SjrJ6tk+XDdxyKbhb49Be4FavsgyjXcMu9JvK67SAyZ07FB6hH3Z3mWFO5u3 7kI/IR9s4C5lbg==; From: Roland Winkler <winkler@HIDDEN> To: 51621 <at> debbugs.gnu.org Subject: Re: bug#51621: 29.0.50; bibtex.el biblatex "2.1.3 Non-standard Types" support In-Reply-To: <87mshekwo5.fsf@HIDDEN> (Roland Winkler's message of "Mon, 02 Dec 2024 08:05:14 -0600") References: <87mshekwo5.fsf@HIDDEN> Date: Wed, 01 Jan 2025 23:59:58 -0600 Message-ID: <875xmxhi1t.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 51621 Cc: Leo Stein <leo.stein@HIDDEN>, Leonard Lausen <leonard@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) On Mon, Dec 02 2024, Roland Winkler wrote: > I am currently working on a patch for bibtex-mode that will make it > easier for users to customize the entry types known by a dialect, > including the possibility to define aliases for entry types. This > patch should be installed on master in a few weeks. (I want to test > it first.) I added new variables bibtex-BibTeX-aux-entry-alist and bibtex-biblatex-aux-entry-alist that should facilitate the customization of entry types. Also, these variables now accept aliases. Please try it out. commit b26418694e8
bug-gnu-emacs@HIDDEN:bug#51621; Package emacs.
Full text available.Received: (at 51621) by debbugs.gnu.org; 3 Dec 2024 21:14:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 03 16:14:08 2024 Received: from localhost ([127.0.0.1]:33150 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tIaDf-0004Dg-NY for submit <at> debbugs.gnu.org; Tue, 03 Dec 2024 16:14:08 -0500 Received: from mail-yw1-f181.google.com ([209.85.128.181]:48326) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <leo.stein@HIDDEN>) id 1tIaDd-0004D4-9K for 51621 <at> debbugs.gnu.org; Tue, 03 Dec 2024 16:14:06 -0500 Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-6eeba477fcaso57344267b3.0 for <51621 <at> debbugs.gnu.org>; Tue, 03 Dec 2024 13:14:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733260379; x=1733865179; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RIQE7gG3oRTybMRE6iHfZAjUKWVKYcxsJ5QRJELfqxA=; b=ClUn8kLb+XxO2yyKpUNEZngceA1a5qzcip0GXuvqVAt7obotIQ1Y8Xnyab8xnO2enr U91k8dbmcb8+L3g1r78Ua6T4cbF/rI/E5NIhNQlAL8VC3RmW6v4yAhddfDOmgFRKLv24 Yow9VgaMqbrtI7BsIcSSsF/V3buucjncCUk7SOH3zeNfqq205vgn77T4bCzuEj6M7hjB qy5YwjMomYob0ADRH9yi9gfYbbR/0y1WM/2EjR/MPNDdFiy9zk9e86GB9Hi4eYYHvWyf xdFf/OhHjIz4u2PXz8iOHq/TG0xOisVd0JIE+0DrtBobIoCYDaMKjrmveeakFys8l4hs GjyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733260379; x=1733865179; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RIQE7gG3oRTybMRE6iHfZAjUKWVKYcxsJ5QRJELfqxA=; b=nIuD9MwE5ts1EFDRQd6H/i/5GNs0AXK6LHX/A73IbYxzSOHW/xHlaBSBCq/tIxTsbt bii/Bv8+2h+so0qCelKNw3412tShwWEtUNjiq+rh0oVH1JY+8Bjl3xSgHfH0rlrx1zW+ 1Jdtzy+hv1HuPzGLuzYC9sIG0WltKzqeWq4O4jUUgHcXYxY3Yhrmk15P1NyXgJbRly/F PuEIXqBscUE7aJFM8uTx4e4VIZEL3NR0FYzvFK0olGQt6RkebcEJ8vZt2DcXxVR+f7Js smucDzpf037T+kC8iWDc9azjcUn2558nLIXbSuZAOTrrbkeKlJVOv+9Tcv/GIn/5nmuE nBnQ== X-Gm-Message-State: AOJu0YwlxXA6Lg1t1hn2muSpiWzKVMXpu8vZZmF3NQsPB79F1U1f3de6 Z9mlYSpCS6RQrv2mcqJmv1jfC80bT12c2zH/QXc5pcYQRZUfsUXkvH7Gegv+Is0/x76+jq2BBbW twkSTv8nttgcM6ubTCY+DatlgheM= X-Gm-Gg: ASbGncvY6GVCxnAdJ4eAwHxuDfet5gVIz8Amqv3gW0S+S+v0xfT7oXqVTx5+BKYMIwo 3GYtc4bO+6hjUz+i8iJMzjQggTtbcm8g= X-Google-Smtp-Source: AGHT+IH3zoXbxDnn3/M5Xj8u5y6idwu1rbVOipyIm1tMP1hWszeYF7cr2tzsM03bRPlqlRwE+GLwh7pfDy3Wy6B1/VA= X-Received: by 2002:a05:6902:1207:b0:e39:96af:53b7 with SMTP id 3f1490d57ef6-e39d43879bfmr4972913276.52.1733260379489; Tue, 03 Dec 2024 13:12:59 -0800 (PST) MIME-Version: 1.0 References: <87mshekwo5.fsf@HIDDEN> <CAE56pjF_zjiCZfKRK-7UdCj2G+YLmkn2xuUgc0eGOHUO=dufsg@HIDDEN> <87jzcgjyek.fsf@HIDDEN> In-Reply-To: <87jzcgjyek.fsf@HIDDEN> From: Leo Stein <leo.stein@HIDDEN> Date: Tue, 3 Dec 2024 15:12:43 -0600 Message-ID: <CAE56pjEs4dLuN39nxT1KKA+maCo+OJcy48vSN0wBpDSk8mdWmg@HIDDEN> Subject: Re: bug#51621: 29.0.50; bibtex.el biblatex "2.1.3 Non-standard Types" support To: Roland Winkler <winkler@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000390edf06286421e0" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 51621 Cc: Leonard Lausen <leonard@HIDDEN>, 51621 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --000000000000390edf06286421e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Dec 3, 2024 at 2:37=E2=80=AFPM Roland Winkler <winkler@HIDDEN> wro= te: > On Mon, Dec 02 2024, Leo Stein wrote: > > I really wish this was more permissive. Looking at a .bib file, we > > have no way of knowing the biblio style that it's going to be set > > with. We also have no way of knowing whether the user is going to > > parse it with bibtex or biber. > > The user needs to know whether she wants to use a bib file with BibTeX > or biblatex and use entry types these programs can handle. Bibtex-mode > cannot be blamed for this. > We are both re-hashing the same points. I will say again that both bibtex and biber+biblatex can handle any types of entries. I think the more flexible approach is to permissive about entry types, and allow bibtex-parse-entry to parse an entry of any type, not just a fixed list of default types from (i) btxdoc.pdf, a piece of documentation from 1988; and (ii) biblatex.pdf, the documentation for a latex package, not the parser, biber, which indeed allows any entry type. > > > I am still missing something... as far as I can tell, the "dialect" is > > just controlling which entries are valid. Is that right? But this is > > not within the purview of whether we use bibtex, or biber+biblatex. It > > depends on the biblio style that the user wants to use for setting > > their bibliography. > > Beyond the defaults documented for BibTeX and biblatex, you are free to > write your own bst style files, and you are free to customize > bibtex-mode to your liking. Everything we discuss here refers only to > user options of bibtex-mode. > > The defaults of bibtex-mode match the defaults specified in the > documentation of BibTeX and biblatex. It would be confusing for users > of bibtex-mode to deviate from that. > You don't understand why you say it would be confusing. Just like emacs can not read users' minds, I don't see how you can be sure about what would be confusing. There are common entry types, e.g. @software, which are in very wide use with standard bibtex. > > > I'm happy to hear that there will be future improvements. > > The goal is to facilitate the customization of bibtex-mode. I see no > reason to change the defaults of user variables. > > > I sincerely request that parsing of entries be made more permissive =E2= =80=94 > > not restricted to a list of entry types, or relying on the user to > > make some customizations [I think most users are not going to discover > > that it's possible to customize this]. > > It is a basic aspect of Emacs that users can customize its behavior. > But Emacs cannot (yet) read the mind of its users and foresee the > customizations they want. > > I have heard rumors that reading the users' mind will become a user > option in Emacs 42. (But I do not know whether this option will be > enabled by default.) > You don't have to try to read my mind =E2=80=94 I am trying to make my mind= known to the devs by emailing this list. I continue to strongly request that bibtex-parse-entry should be more permissive about parsing types than a predefined list from 1988. --000000000000390edf06286421e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr">On Tue, Dec 3, 2024 at 2:37=E2=80=AFPM Ro= land Winkler <<a href=3D"mailto:winkler@HIDDEN">winkler@HIDDEN</a>>= wrote:</div><div class=3D"gmail_quote gmail_quote_container"><blockquote c= lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli= d rgb(204,204,204);padding-left:1ex">On Mon, Dec 02 2024, Leo Stein wrote:<= br> > I really wish this was more permissive. Looking at a .bib file, we<br> > have no way of knowing the biblio style that it's going to be set<= br> > with. We also have no way of knowing whether the user is going to<br> > parse it with bibtex or biber.<br> <br> The user needs to know whether she wants to use a bib file with BibTeX<br> or biblatex and use entry types these programs can handle.=C2=A0 Bibtex-mod= e<br> cannot be blamed for this.<br></blockquote><div><br></div><div>We are both = re-hashing the same points. I will say again that both bibtex and biber+bib= latex can handle any types of entries. I think the more flexible approach i= s to permissive about entry types, and allow bibtex-parse-entry to parse an= entry of any type, not just a fixed list of default types from (i) btxdoc.= pdf, a piece of documentation from 1988; and (ii) biblatex.pdf, the documen= tation for a latex package, not the parser, biber, which indeed allows any = entry type.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex"> <br> > I am still missing something... as far as I can tell, the "dialec= t" is<br> > just controlling which entries are valid. Is that right? But this is<b= r> > not within the purview of whether we use bibtex, or biber+biblatex. It= <br> > depends on the biblio style that the user wants to use for setting<br> > their bibliography.<br> <br> Beyond the defaults documented for BibTeX and biblatex, you are free to<br> write your own bst style files, and you are free to customize<br> bibtex-mode to your liking.=C2=A0 Everything we discuss here refers only to= <br> user options of bibtex-mode.<br> <br> The defaults of bibtex-mode match the defaults specified in the<br> documentation of BibTeX and biblatex.=C2=A0 It would be confusing for users= <br> of bibtex-mode to deviate from that.<br></blockquote><div><br></div><div>Yo= u don't understand why you say it would be confusing. Just like emacs c= an not read users' minds,=C2=A0I don't see how you can be sure abou= t what would be confusing. There are common entry types, e.g. @software, wh= ich are in very wide use with standard bibtex.</div><div>=C2=A0</div><block= quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1= px solid rgb(204,204,204);padding-left:1ex"> <br> > I'm happy to hear that there will be future improvements. <br> <br> The goal is to facilitate the customization of bibtex-mode.=C2=A0 I see no<= br> reason to change the defaults of user variables.<br> <br> > I sincerely request that parsing of entries be made more permissive = =E2=80=94<br> > not restricted to a list of entry types, or relying on the user to<br> > make some customizations [I think most users are not going to discover= <br> > that it's possible to=C2=A0customize this].<br> <br> It is a basic aspect of Emacs that users can customize its behavior.<br> But Emacs cannot (yet) read the mind of its users and foresee the<br> customizations they want.<br> <br> I have heard rumors that reading the users' mind will become a user<br> option in Emacs 42.=C2=A0 (But I do not know whether this option will be<br= > enabled by default.)<br></blockquote><div><br></div><div>You don't have= to try to read my mind =E2=80=94 I am trying to make my mind known to the = devs by emailing this list. I continue to strongly request that=C2=A0bibtex= -parse-entry should be more permissive about parsing types than a predefine= d list from 1988.</div></div></div> --000000000000390edf06286421e0--
bug-gnu-emacs@HIDDEN:bug#51621; Package emacs.
Full text available.Received: (at 51621) by debbugs.gnu.org; 3 Dec 2024 20:40:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 03 15:40:08 2024 Received: from localhost ([127.0.0.1]:33094 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tIZgl-0002c0-GA for submit <at> debbugs.gnu.org; Tue, 03 Dec 2024 15:40:08 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50766) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <winkler@HIDDEN>) id 1tIZgi-0002Yk-BE for 51621 <at> debbugs.gnu.org; Tue, 03 Dec 2024 15:40:05 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <winkler@HIDDEN>) id 1tIZeV-0002uI-0l; Tue, 03 Dec 2024 15:37:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=QcfYKxYBzG3avrNh4YBl7l5epOdHf0JBDhohpHe5rOQ=; b=mu7KW7l2MMfxf1XJr6BI CF2xe7HTu3tGYfsyJThfWSZmb0pgnlGqayv9FlWjQzgyZn00ghCpU7QvUUgMe3xNTpfh0ySbvMvKS 8TMbVWmwh2McTK15n1/KnKQHvEOAAw9k2FatTb730wbKSywyoveCVCJwrQdwHXbNXtBKW4kv3bItb qDQ5MQVdH61z4OVZUGRPRmZTD5L6uekRgX84/GVcTrm/KVeze2wLQHrqyYUBqVSGmaC/ZY+RP76KO s8/fTIJO26cjOm49God4VsYF7F30S9q+Lyyqh6AGSifcMereKLK5Rm8utNUMNjwmhVKj62qBjkfkH XD1bTcevt3PhBw==; From: Roland Winkler <winkler@HIDDEN> To: Leo Stein <leo.stein@HIDDEN> Subject: Re: bug#51621: 29.0.50; bibtex.el biblatex "2.1.3 Non-standard Types" support In-Reply-To: <CAE56pjF_zjiCZfKRK-7UdCj2G+YLmkn2xuUgc0eGOHUO=dufsg@HIDDEN> (Leo Stein's message of "Mon, 2 Dec 2024 11:23:31 -0600") References: <87mshekwo5.fsf@HIDDEN> <CAE56pjF_zjiCZfKRK-7UdCj2G+YLmkn2xuUgc0eGOHUO=dufsg@HIDDEN> Date: Tue, 03 Dec 2024 14:37:39 -0600 Message-ID: <87jzcgjyek.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 51621 Cc: Leonard Lausen <leonard@HIDDEN>, 51621 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) On Mon, Dec 02 2024, Leo Stein wrote: > I really wish this was more permissive. Looking at a .bib file, we > have no way of knowing the biblio style that it's going to be set > with. We also have no way of knowing whether the user is going to > parse it with bibtex or biber. The user needs to know whether she wants to use a bib file with BibTeX or biblatex and use entry types these programs can handle. Bibtex-mode cannot be blamed for this. > I am still missing something... as far as I can tell, the "dialect" is > just controlling which entries are valid. Is that right? But this is > not within the purview of whether we use bibtex, or biber+biblatex. It > depends on the biblio style that the user wants to use for setting > their bibliography. Beyond the defaults documented for BibTeX and biblatex, you are free to write your own bst style files, and you are free to customize bibtex-mode to your liking. Everything we discuss here refers only to user options of bibtex-mode. The defaults of bibtex-mode match the defaults specified in the documentation of BibTeX and biblatex. It would be confusing for users of bibtex-mode to deviate from that. > I'm happy to hear that there will be future improvements.=20 The goal is to facilitate the customization of bibtex-mode. I see no reason to change the defaults of user variables. > I sincerely request that parsing of entries be made more permissive =E2= =80=94 > not restricted to a list of entry types, or relying on the user to > make some customizations [I think most users are not going to discover > that it's possible to=C2=A0customize this]. It is a basic aspect of Emacs that users can customize its behavior. But Emacs cannot (yet) read the mind of its users and foresee the customizations they want. I have heard rumors that reading the users' mind will become a user option in Emacs 42. (But I do not know whether this option will be enabled by default.)
bug-gnu-emacs@HIDDEN:bug#51621; Package emacs.
Full text available.Received: (at 51621) by debbugs.gnu.org; 2 Dec 2024 17:24:53 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 02 12:24:53 2024 Received: from localhost ([127.0.0.1]:56423 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tIAAG-0004kF-9a for submit <at> debbugs.gnu.org; Mon, 02 Dec 2024 12:24:52 -0500 Received: from mail-yb1-f176.google.com ([209.85.219.176]:42288) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <leo.stein@HIDDEN>) id 1tIAAC-0004k5-QM for 51621 <at> debbugs.gnu.org; Mon, 02 Dec 2024 12:24:49 -0500 Received: by mail-yb1-f176.google.com with SMTP id 3f1490d57ef6-e39779a268bso3276439276.1 for <51621 <at> debbugs.gnu.org>; Mon, 02 Dec 2024 09:24:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733160228; x=1733765028; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7r04ujBlVHjJI6xuSn4LKCXtYdU24FRg2fFhRipzZI8=; b=kp7oT9+L9Ej0sigjZvwToe8lTkGslzLg92mpekBYmZTjVWq86cSF6eb8d0QvwUDTM8 PWa4HEJGS7Jwu88DwRV4aejKwPZ4J6kYP3sxP14MSjo4u5y9W77mSuTY6auyQGfvKR+3 Rb/e+CHIJvQGDiA/x+HiFEUEEC/4BdQHzmzHs8thzh+wPH7tNUe2KzKFEVlFqV/ht5mr 66epqL97sg3im37cBW3fU9D2tIik+PAf60xcZ9SR81k4nO46B0bbrWb2lr7MF/KNjSWu 8X9FzmoM5mCuIMwfSSMMTjaJ0ABGFGFZKCbs+BgN+5Fy7n6+7uZqHdzYUJIBzM8JB7F7 lzxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733160228; x=1733765028; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7r04ujBlVHjJI6xuSn4LKCXtYdU24FRg2fFhRipzZI8=; b=Yv8wwGtUrWa4250bxQ7ntLnXzgXKd9IG6bOFtzxSdydLRIjzrvJ4JwMFbAfWFOLQXk YloBm9WXSH24utj+zaUC/5UjoEePHJJVFmHjQr1F3T20vfmRR5I3SpxXT+/ZGQCl2hMO qmwTood0jTutDbUvKwDoyhpgc37tYmTHzCPZeIWGCya8rpBxZqFJnfsrwdcvYQKUP1M8 of71y3pbsnyaNPxoxTm+flESjMitsfTKG5BhUCN6keMh+fJBLjsJLa6fZQBKLejTZ72/ j9lMMCpThIA5ayKktVvlfAYWUklpk70S9gOp+KPKPNFbt5qtulriHGUQeOTJqY04L1ab 1/8w== X-Gm-Message-State: AOJu0Yx6pyIg0MvZHK16iTf5P1dgnEKYXnI26laMr7jFZmdpo6f0ttRO E0HCvOazyCKG4frwDdLEST6fqcR9+IHV8cS6RN5G61hNfg7bJQE+WfBB+TYWxUa/COhJBy2hKEm 2oznk+RopO1KbJ/Lyk2h6KgQl/fs= X-Gm-Gg: ASbGncsPS3HpnLIpnbx9jETdii5JDyEqqWH5pWvRKKqtTqfaYMd+jXIedKYBSGOOZym 8+GPUvihm89j5bkYqcF3BIPJxGI0uvyM4+DZtKX4XQKBOqJ8= X-Google-Smtp-Source: AGHT+IE9wCBzHGVZ1TQBWOq6F889MhK+Dp603Y1edr94hegIcuumf62HnGJ3yeXwjoU3PAAbydEXAtIv4trTXZKz0Bc= X-Received: by 2002:a25:7449:0:b0:e38:7d21:3b53 with SMTP id 3f1490d57ef6-e3971a1ad60mr18230223276.22.1733160228128; Mon, 02 Dec 2024 09:23:48 -0800 (PST) MIME-Version: 1.0 References: <87mshekwo5.fsf@HIDDEN> In-Reply-To: <87mshekwo5.fsf@HIDDEN> From: Leo Stein <leo.stein@HIDDEN> Date: Mon, 2 Dec 2024 11:23:31 -0600 Message-ID: <CAE56pjF_zjiCZfKRK-7UdCj2G+YLmkn2xuUgc0eGOHUO=dufsg@HIDDEN> Subject: Re: bug#51621: 29.0.50; bibtex.el biblatex "2.1.3 Non-standard Types" support To: Roland Winkler <winkler@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000bc8dde06284ccff0" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 51621 Cc: Leonard Lausen <leonard@HIDDEN>, 51621 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --000000000000bc8dde06284ccff0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Roland, First of all, thanks for maintaining this very handy mode! On Mon, Dec 2, 2024 at 8:05=E2=80=AFAM Roland Winkler <winkler@HIDDEN> wro= te: > > I'm starting to think that the "dialect" design within bibtex.el was > > confused about bibtex vs. biblatex (this is pretty confusing, as we > > can see here: https://tex.stackexchange.com/q/25701/34063). However, > > I'm not sure what is the correct solution. At the very least, > > bibtex.el should be more permissive about what entry types get parsed > > by bibtex-parse-entry. > > The range of "acceptable" entry types needs to be compatible with the > BibTeX style files that one wants to use. Certainly, these style files > can be modified to handle any entry types you like. But I am not sure > it makes sense to extend the defaults of bibtex.el beyond the defaults > defined by BibTeX and / or biblatex. I really wish this was more permissive. Looking at a .bib file, we have no way of knowing the biblio style that it's going to be set with. We also have no way of knowing whether the user is going to parse it with bibtex or biber. > If you want to use the full range > of entry types defined by biblatex, you may be served better by making > biblatex your default dialect of bibtex-mode. (I find it useful if > bibtex-mode keeps track of the entry types known to a dialect.) > I am still missing something... as far as I can tell, the "dialect" is just controlling which entries are valid. Is that right? But this is not within the purview of whether we use bibtex, or biber+biblatex. It depends on the biblio style that the user wants to use for setting their bibliography. > > I am currently working on a patch for bibtex-mode that will make it > easier for users to customize the entry types known by a dialect, > including the possibility to define aliases for entry types. This patch > should be installed on master in a few weeks. (I want to test it > first.) > I'm happy to hear that there will be future improvements. I sincerely request that parsing of entries be made more permissive =E2=80=94 not restr= icted to a list of entry types, or relying on the user to make some customizations [I think most users are not going to discover that it's possible to customize this]. > > PS: My reading of the above thread on stackexchange is that it will not > make everyone happy if the distinction between old BibTeX and new > biblatex gets blurred by bibtex-mode. > Again I don't understand why bibtex-mode is making a distinction. The syntax of the .bib is identical whether the user wants to use bibtex or biber+biblatex. Best, Leo --000000000000bc8dde06284ccff0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr">Dear Roland,<div><br></div><div>First of = all, thanks for maintaining this very handy mode!</div></div><br><div class= =3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Dec 2, 2024 = at 8:05=E2=80=AFAM Roland Winkler <<a href=3D"mailto:winkler@HIDDEN">wi= nkler@HIDDEN</a>> wrote:<br></div><blockquote class=3D"gmail_quote" sty= le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi= ng-left:1ex">> I'm starting to think that the "dialect" de= sign within bibtex.el was<br> > confused about bibtex vs. biblatex (this is pretty confusing, as we<br= > > can see here: <a href=3D"https://tex.stackexchange.com/q/25701/34063" = rel=3D"noreferrer" target=3D"_blank">https://tex.stackexchange.com/q/25701/= 34063</a>). However,<br> > I'm not sure what is the correct solution. At the very least,<br> > bibtex.el should be more permissive about what entry types get parsed<= br> > by bibtex-parse-entry.<br> <br> The range of "acceptable" entry types needs to be compatible with= the<br> BibTeX style files that one wants to use.=C2=A0 Certainly, these style file= s<br> can be modified to handle any entry types you like.=C2=A0 But I am not sure= <br> it makes sense to extend the defaults of bibtex.el beyond the defaults<br> defined by BibTeX and / or biblatex.</blockquote><div><br></div><div>I real= ly wish this was more permissive. Looking at a .bib file, we have no way of= knowing the biblio style that it's going to be set with. We also have = no way of knowing whether the user is going to parse it with bibtex or bibe= r.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:= 0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">= =C2=A0 If you want to use the full range<br> of entry types defined by biblatex, you may be served better by making<br> biblatex your default dialect of bibtex-mode.=C2=A0 (I find it useful if<br= > bibtex-mode keeps track of the entry types known to a dialect.)<br></blockq= uote><div><br></div><div>I am still missing something... as far as I can te= ll, the "dialect" is just controlling which entries are valid. Is= that right? But this is not within the purview of whether we use bibtex, o= r biber+biblatex. It depends on the biblio style that the user wants to use= for setting their bibliography.</div><div>=C2=A0</div><blockquote class=3D= "gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2= 04,204,204);padding-left:1ex"> <br> I am currently working on a patch for bibtex-mode that will make it<br> easier for users to customize the entry types known by a dialect,<br> including the possibility to define aliases for entry types.=C2=A0 This pat= ch<br> should be installed on master in a few weeks.=C2=A0 (I want to test it<br> first.)<br></blockquote><div><br></div><div>I'm happy to hear that ther= e will be future improvements. I sincerely request that parsing of entries = be made more permissive =E2=80=94 not restricted to a list of entry types, = or relying on the user to make some customizations [I think most users are = not going to discover that it's possible to=C2=A0customize this].</div>= <div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> PS: My reading of the above thread on stackexchange is that it will not<br> make everyone happy if the distinction between old BibTeX and new<br> biblatex gets blurred by bibtex-mode.<br></blockquote><div><br></div><div>A= gain I don't understand why bibtex-mode is making a distinction. The sy= ntax of the .bib is identical whether the user wants to use bibtex or biber= +biblatex.</div><div><br></div><div>Best,</div><div>Leo</div><div>=C2=A0</d= iv></div></div> --000000000000bc8dde06284ccff0--
bug-gnu-emacs@HIDDEN:bug#51621; Package emacs.
Full text available.Received: (at 51621) by debbugs.gnu.org; 2 Dec 2024 14:05:55 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 02 09:05:55 2024 Received: from localhost ([127.0.0.1]:54771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tI73j-0001zN-4t for submit <at> debbugs.gnu.org; Mon, 02 Dec 2024 09:05:55 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52656) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <winkler@HIDDEN>) id 1tI73g-0001z2-02 for 51621 <at> debbugs.gnu.org; Mon, 02 Dec 2024 09:05:53 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <winkler@HIDDEN>) id 1tI73V-00043B-El; Mon, 02 Dec 2024 09:05:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:Subject:To:From:in-reply-to: references; bh=HerY5f0iKTkOFJds9nrSmY0RcB44dKDCk5lPDxrjx+M=; b=cL9MV9C/hospkr bv8OKCkmBpjKZJ/TetlkSHaXXQtxcfzN5JsZoqWlD/fsZi/c5ylGRtVwg1oSRECZIKgHYERVZ01xQ j5piVDxqiQnK/N7VwJ+athyypdBgCImthqGT6RH66NSpr3eWN0FoFktZBVaojYnzrvkyKCbkQCKaF 2fVwH9TNWKkzL/rDClij1VTe2PJqUZHbk9Dr5gnEhyjhWDg6k2UMVepbFRK48A4esDjGDszG7kK++ aDlrXAP6lz6se/2Cq/iY+6tp881Dh68bMfSQuNhr2b/lynxtVrCoYo8eht6WqH0uM6MIUQ0yDTXG4 m63nBmwEaUZI3U1+9HDA==; From: Roland Winkler <winkler@HIDDEN> To: 51621 <at> debbugs.gnu.org Subject: Re: bug#51621: 29.0.50; bibtex.el biblatex "2.1.3 Non-standard Types" support Date: Mon, 02 Dec 2024 08:05:14 -0600 Message-ID: <87mshekwo5.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 51621 Cc: Leo Stein <leo.stein@HIDDEN>, Leonard Lausen <leonard@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > I'm starting to think that the "dialect" design within bibtex.el was > confused about bibtex vs. biblatex (this is pretty confusing, as we > can see here: https://tex.stackexchange.com/q/25701/34063). However, > I'm not sure what is the correct solution. At the very least, > bibtex.el should be more permissive about what entry types get parsed > by bibtex-parse-entry. The range of "acceptable" entry types needs to be compatible with the BibTeX style files that one wants to use. Certainly, these style files can be modified to handle any entry types you like. But I am not sure it makes sense to extend the defaults of bibtex.el beyond the defaults defined by BibTeX and / or biblatex. If you want to use the full range of entry types defined by biblatex, you may be served better by making biblatex your default dialect of bibtex-mode. (I find it useful if bibtex-mode keeps track of the entry types known to a dialect.) I am currently working on a patch for bibtex-mode that will make it easier for users to customize the entry types known by a dialect, including the possibility to define aliases for entry types. This patch should be installed on master in a few weeks. (I want to test it first.) PS: My reading of the above thread on stackexchange is that it will not make everyone happy if the distinction between old BibTeX and new biblatex gets blurred by bibtex-mode.
bug-gnu-emacs@HIDDEN:bug#51621; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 1 Dec 2024 12:12:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 01 07:12:45 2024 Received: from localhost ([127.0.0.1]:50595 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tHioe-0005WV-Bu for submit <at> debbugs.gnu.org; Sun, 01 Dec 2024 07:12:45 -0500 Received: from lists.gnu.org ([209.51.188.17]:38690) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <leo.stein@HIDDEN>) id 1tHbgN-0006zS-HW for submit <at> debbugs.gnu.org; Sat, 30 Nov 2024 23:35:44 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <leo.stein@HIDDEN>) id 1tHbeF-0003kN-Li for bug-gnu-emacs@HIDDEN; Sat, 30 Nov 2024 23:33:31 -0500 Received: from mail-yw1-x112f.google.com ([2607:f8b0:4864:20::112f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <leo.stein@HIDDEN>) id 1tHbeD-0004ZE-Sg for bug-gnu-emacs@HIDDEN; Sat, 30 Nov 2024 23:33:31 -0500 Received: by mail-yw1-x112f.google.com with SMTP id 00721157ae682-6ee676b4e20so33490647b3.3 for <bug-gnu-emacs@HIDDEN>; Sat, 30 Nov 2024 20:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733027608; x=1733632408; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=IQIzGhnIJ90V/Gbao76fV8Vtrm3dwkXHLNA+fnzDVlE=; b=Zw1LBVTE+fnR8WlLjrlCFIkzEs33qTjSmABsyc6b+TMY0RpkGw2kFRhVuzhkNFS4V8 0Y+f7It9cYHLvUQRIK74AleLwIJX4BKdTz9A++0i8Qsu8tsZDlEcn1a+HcEQSw/1JjWk I6GV50knqUdAWdhKPQDjDSSsEAnIUrJgHIUbVJhi0VqwuBDYTLPC31+Dxr4BMUs9DOdG CYV5E513Ol5rNJPfE6iWrJ8dwFwJ/QbQFR4naP42UylNZRHSNbihaOdMl8iQslxX9mRL TZj7nXmXZJ8LxRQPCvMkRgOf7OMZTkRk8V523gGQLhYxrGM3jTz+loo48cBzFB7iGedZ sCmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733027608; x=1733632408; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=IQIzGhnIJ90V/Gbao76fV8Vtrm3dwkXHLNA+fnzDVlE=; b=j2u8B3x7twtt6/iRwCUqdNmPhKg5amFFabVi0Kq4jv2urQxWFijuEkW6eKGDJNGavT Vwags52ZVAGUJ1MliAw7D/JF5X1cKTudT2wVpiId0an95x5Vx39lNTYxqpP4dwIInNqs Aoao13hAgEqF8ER7Rd+B5+jEjB2n75Jf3lfrmN1YCKibwwPCE9xxkek94n6iivcx0rF7 yE+LyLmlHT07qEnegWlBdjUn8GoCq6lpqZwxvSeYHnpHSEQ9TwhQdXAS/1RnyXj6rO+C xQhVIKlN9/SzAVBpl4oGuMMmXNfG7MJqz+uZZ+i2qlp1yuIlN1eyvJJSIxDkW7yCTKLy pQCA== X-Forwarded-Encrypted: i=1; AJvYcCXbaVZ7dEMD+V+F/hJpALlVmm0VTDhczjQ0uxpRMYrJYOq+5LLUKE/kLACiJ/7maSBNk1NMtgtnFoG4pjz5@HIDDEN X-Gm-Message-State: AOJu0YwkVIsCx/3kM5Wv0KG19KNrHeQwkXUbfocHvRtxaG2l4bOEssc+ tpB/2gH9TZ/iehwMOVzdV6Lvs5ABISYRWcF77MWHIOnS/fVnp56iOxX1W+jlelqtGxRgFZxxiAE 4dbAIgSe3R5h/qwVYJCb7C0fjxiQvmraz X-Gm-Gg: ASbGncuV57mKmbHOu/0m+X6ovxXlgCgGWYp+fqhh+NNcngjGT0OzEeYfHlfHeUlasH3 V73P8p8ImXd7DZz8mVY/t8jGnzTXEsVo= X-Google-Smtp-Source: AGHT+IEQwweKGpT1LFS5jkj7gFUylgfJw9fPQAQYh0JmI2qR7pSSXXGcgN2wOLrsCc79K7BGbcvBys+ovukxYTckKUA= X-Received: by 2002:a05:690c:74c9:b0:6ec:b108:e5ce with SMTP id 00721157ae682-6ef37279c69mr232078277b3.28.1733027607862; Sat, 30 Nov 2024 20:33:27 -0800 (PST) MIME-Version: 1.0 From: Leo Stein <leo.stein@HIDDEN> Date: Sat, 30 Nov 2024 22:33:11 -0600 Message-ID: <CAE56pjEEJh-MbcMLX2PRLLBZSq3A5C6=DEGm8ootqLWSkUzyvg@HIDDEN> Subject: bug#51621: 29.0.50; bibtex.el biblatex "2.1.3 Non-standard Types" support To: Leonard Lausen <leonard@HIDDEN>, bug-gnu-emacs@HIDDEN Content-Type: multipart/alternative; boundary="000000000000f3e86b06282dee93" Received-SPF: pass client-ip=2607:f8b0:4864:20::112f; envelope-from=leo.stein@HIDDEN; helo=mail-yw1-x112f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Sun, 01 Dec 2024 07:12:43 -0500 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) --000000000000f3e86b06282dee93 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I wanted to raise a bug report but found this earlier one from 3 years ago that was almost the same as my own. I was confused about why BibTeX-mode was happily fontifying a doi=3D... field within a @software entry, and attaching a button to it, but I could not follow the URL =E2=80=94 because BibTeX-mode thinks @software is not an allowed type within the "BibTeX" "dialect". So, bibtex-parse-entry returns nil. This is because the regex bibtex-entry-head is built from all "valid" entry types of the "dialect". However, there is no reason @software, or any other type of entry, should be an "invalid" entry in a bibtex file. It's the purview of whatever bibtex style (defined in a .bst file) to determine what to do with different entries. Some bst's default to passing things along to the @misc entry type. But, I count 7 different bst's in the 2024 TeXLive tree that define a @software type, and I'm sure there are many more custom types (e.g. the TeX User's Group's tugboat.bst defines an entry type for @ctan , i.e. to cite an entry on the Comprehensive TeX Archive Network). I'm starting to think that the "dialect" design within bibtex.el was confused about bibtex vs. biblatex (this is pretty confusing, as we can see here: https://tex.stackexchange.com/q/25701/34063). However, I'm not sure what is the correct solution. At the very least, bibtex.el should be more permissive about what entry types get parsed by bibtex-parse-entry. Best Leo --000000000000f3e86b06282dee93 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div>Hi,</div><div><br></div><div>I wante= d to raise a bug report but found this earlier one from 3 years ago that wa= s almost the same as my own. I was confused about why BibTeX-mode was happi= ly fontifying a doi=3D... field within a @software entry, and attaching a b= utton to it, but I could not follow the URL =E2=80=94 because BibTeX-mode t= hinks @software is not an allowed type within the "BibTeX" "= dialect". So, bibtex-parse-entry returns nil. This is because the rege= x bibtex-entry-head is built from all "valid" entry types of the = "dialect".</div><div><br></div><div>However, there is no reason @= software, or any other type of entry, should be an "invalid" entr= y in a bibtex file. It's the purview of whatever bibtex style (defined = in a .bst file) to determine what to do with different entries. Some bst= 9;s default to passing things along to the @misc entry type. But, I count 7= different bst's in the 2024 TeXLive tree that define a @software type,= and I'm sure there are many more custom types (e.g. the TeX User's= Group's tugboat.bst defines an entry type for @ctan , i.e. to cite an = entry on the Comprehensive TeX Archive Network).</div><div><br></div><div>I= 'm starting to think that the "dialect" design within bibtex.= el was confused about bibtex vs. biblatex (this is pretty confusing, as we = can see here:=C2=A0<a href=3D"https://tex.stackexchange.com/q/25701/34063">= https://tex.stackexchange.com/q/25701/34063</a>). However, I'm not sure= what is the correct solution. At the very least, bibtex.el should be more = permissive about what entry types get parsed by bibtex-parse-entry.</div><d= iv><br></div><div>Best</div><div>Leo</div> </div> </div> --000000000000f3e86b06282dee93--
bug-gnu-emacs@HIDDEN:bug#51621; Package emacs.
Full text available.Received: (at 51621) by debbugs.gnu.org; 7 Nov 2021 03:37:11 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 06 23:37:11 2021 Received: from localhost ([127.0.0.1]:51442 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mjYzW-0004a2-Ub for submit <at> debbugs.gnu.org; Sat, 06 Nov 2021 23:37:11 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50730) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <winkler@HIDDEN>) id 1mjYzT-0004Zl-HU for 51621 <at> debbugs.gnu.org; Sat, 06 Nov 2021 23:37:10 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33874) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <winkler@HIDDEN>) id 1mjYzN-0007xR-BZ; Sat, 06 Nov 2021 23:37:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=/dxv/pAEEpPc7ylQRkp2U9BmWiVkioQCvIzGREHsR7E=; b=Wzz4/efuY0qr1WwuMD+p /xE82ZXXp2xWNSpumxdJ0qOOXy93woIJDym1XB1cSDzIH1Iq48kVNj9IBAnIXweo80Ccgag5V7Vsm 2k0qBvcEH0g6FePKy6Bv5KzsPbsDTAd+IaDue78cUSMir+YbfoODvm2zxeX1Dq8P34CV//SvyBsRt MEszGUUtA9iW5dgsTqWcfrJSuVO8BbHOtZfM0PT8JkSZLDV+NNxFId5d5nGN/nctbm7w6vG7Gat18 bQiDZwP9e/vHl86XZi97O/f6XkPNGozaKznl4PXKUGGKvKnXuIfty541xYtJEqZBN5nsByo0hHAfN 3/vcNX1exkPz/g==; Received: from [2600:1700:5650:f790::42] (port=50034 helo=regnitz) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <winkler@HIDDEN>) id 1mjYzN-00061f-5V; Sat, 06 Nov 2021 23:37:01 -0400 From: "Roland Winkler" <winkler@HIDDEN> To: Leonard Lausen <leonard@HIDDEN> Subject: Re: bug#51621: 29.0.50; bibtex.el biblatex "2.1.3 Non-standard Types" support References: <87v91618i8.fsf@HIDDEN> Date: Sat, 06 Nov 2021 22:37:00 -0500 In-Reply-To: <87v91618i8.fsf@HIDDEN> (Leonard Lausen's message of "Fri, 05 Nov 2021 23:35:11 +0000") Message-ID: <87v914ab6r.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 51621 Cc: 51621 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) On Fri, Nov 05 2021, Leonard Lausen wrote: > Would it make sense to add support for these types to bibtex.el? I myself do not use biblatex. But it seems to me that the sheer number of entry types supported by biblatex gets overwhelming and inefficient for users that may use only a subset of all biblatex entry types. Could it make sense to break down the list of biblatex entry types into two customizable subsets such that commands like bibtex-entry and the menu "Entry-Types" list only the "important" entry types, whereas functions like bibtex-validate accept the complete set of entry types supported by biblatex? Roland
bug-gnu-emacs@HIDDEN:bug#51621; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 5 Nov 2021 23:35:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 05 19:35:30 2021
Received: from localhost ([127.0.0.1]:47635 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1mj8k6-0001F1-8p
for submit <at> debbugs.gnu.org; Fri, 05 Nov 2021 19:35:30 -0400
Received: from lists.gnu.org ([209.51.188.17]:52156)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <leonard@HIDDEN>) id 1mj8k4-0001Es-4z
for submit <at> debbugs.gnu.org; Fri, 05 Nov 2021 19:35:28 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:42510)
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <leonard@HIDDEN>) id 1mj8k3-0000yM-VY
for bug-gnu-emacs@HIDDEN; Fri, 05 Nov 2021 19:35:27 -0400
Received: from devico.uberspace.de ([185.26.156.185]:47964)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <leonard@HIDDEN>) id 1mj8k1-0006XT-5Q
for bug-gnu-emacs@HIDDEN; Fri, 05 Nov 2021 19:35:27 -0400
Received: (qmail 318 invoked from network); 5 Nov 2021 23:35:15 -0000
Received: from localhost (HELO localhost) (127.0.0.1)
by devico.uberspace.de with SMTP; 5 Nov 2021 23:35:15 -0000
From: Leonard Lausen <leonard@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 29.0.50; bibtex.el biblatex "2.1.3 Non-standard Types" support
Date: Fri, 05 Nov 2021 23:35:11 +0000
Message-ID: <87v91618i8.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=185.26.156.185; envelope-from=leonard@HIDDEN;
helo=devico.uberspace.de
X-Spam_score_int: -18
X-Spam_score: -1.9
X-Spam_bar: -
X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.4 (-)
X-Debbugs-Envelope-To: submit
Cc: winkler@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.4 (--)
biblatex types such as @audio, @music, @review from section 2.1.3 of the
biblatex documentation are not considered by bibtex.el's biblatex
dialect implementation. The standard styles treat these types (with
exceptions) like @misc. An example of an exception is @review, which is
a more specific variant of the @article type.
I think the types are called non-standard, because the standard
bibliography styles provide no bibliography drivers for these types, but
these types are known to the default data model and will be happily
accepted by biber.
The impact is that emacs will not recognize entries of those types as
valid entries, and prevent referencing them via org-cite or applying
operations such as bibtex-clean-entry.
To reproduce run `emacs -Q`. Then switch to `bibtex-mode` and set
`(bibtex-set-dialect 'biblatex t)`. Finally paste (taken from
https://tex.stackexchange.com/a/435059/106845)
@audio{Smith2018,
author={Stacey Vanek Smith and Stanley Plotkin},
title={The Economics of Vaccines},
howpublished={NPR},
organization={Planet Money}
month=6,
year=2010,
series={Planet Money},
url={https://www.npr.org/templates/transcript/transcript.php?storyId=616926505}
}
and navigate the cursor into the @audio entry. Then execute `M-x
bibtex-clean-entry` and observe "Not inside a BibTex entry" error
message.
Would it make sense to add support for these types to bibtex.el?
In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.29, cairo version 1.16.0)
of 2021-11-05 built on leonard-xps13
Repository revision: 37632dae180e9d5196ef01343fefa9234c5f05b9
Repository branch: feature/pgtk
Repository: https://github.com/leezu/emacs
Windowing system distributor 'System Description: Gentoo/Linux
Configured using:
'configure --with-cairo --with-x-toolkit=no --with-pgtk --with-modules
--with-native-compilation --prefix=/home/leonard/local'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XIM
GTK3 ZLIB
Important settings:
value of $LC_COLLATE: C
value of $LC_CTYPE: zh_CN.UTF-8
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: BibTeX
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search seq gv
byte-opt bytecomp byte-compile cconv mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils bibtex iso8601
time-date subr-x help-mode cl-loaddefs cl-lib china-util iso-transl
tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit pgtk lcms2 multi-tty make-network-process
native-compile emacs)
Memory information:
((conses 16 86191 6454)
(symbols 48 7175 0)
(strings 32 24675 1427)
(string-bytes 1 773743)
(vectors 16 15122)
(vector-slots 8 363616 15516)
(floats 8 24 48)
(intervals 56 325 0)
(buffers 992 10))
Leonard Lausen <leonard@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#51621; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.