From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Leo Stein Newsgroups: gmane.emacs.bugs Subject: bug#51621: 29.0.50; bibtex.el biblatex "2.1.3 Non-standard Types" support Date: Tue, 3 Dec 2024 15:12:43 -0600 Message-ID: References: <87mshekwo5.fsf@gnu.org> <87jzcgjyek.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000390edf06286421e0" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40543"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Leonard Lausen , 51621@debbugs.gnu.org To: Roland Winkler Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 03 22:15:41 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tIaFB-000AOy-8B for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 03 Dec 2024 22:15:41 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tIaEb-0007Zh-QE; Tue, 03 Dec 2024 16:15:05 -0500 Original-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 ) id 1tIaEZ-0007ZM-MV for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2024 16:15:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tIaEZ-0003Mu-2M for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2024 16:15:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:From:In-Reply-To:References:MIME-Version:To:Subject; bh=RIQE7gG3oRTybMRE6iHfZAjUKWVKYcxsJ5QRJELfqxA=; b=H5QZ1NvkYMgr15Ueu50xd+2PAZqVsZouqS6h726s4wubEx3L4xA+Aekm9fNQFKohQ233OgPR7Dw96f8v3WT5kp46MMF537w9Ri1AesDIYwPHHOd/P/qx20ZxkuGFND3RjeNq2aevHtmo76KJe8mz6QsH6wDHS3qrZYtFX45MojuuzlVzPVzxiIatH4n0lL7vBUcEBtILRVroLz3JOw/veqw9B41vFZaTa4FGsOe4g3TBGE6TK8EG+A5mSq5GpQw/5VbiDtbYJ4hjVVTv5BExmVucvuq2Y7M0+oy2ulm+D7XESaGNsexaDp9dsbZbMerriSHoZJO08kT2AE9gfl/wXg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tIaEY-0004FU-MD for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2024 16:15:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Leo Stein Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 Dec 2024 21:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51621 X-GNU-PR-Package: emacs Original-Received: via spool by 51621-submit@debbugs.gnu.org id=B51621.173326044816229 (code B ref 51621); Tue, 03 Dec 2024 21:15:02 +0000 Original-Received: (at 51621) by debbugs.gnu.org; 3 Dec 2024 21:14:08 +0000 Original-Received: from localhost ([127.0.0.1]:33150 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tIaDf-0004Dg-NY for submit@debbugs.gnu.org; Tue, 03 Dec 2024 16:14:08 -0500 Original-Received: from mail-yw1-f181.google.com ([209.85.128.181]:48326) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tIaDd-0004D4-9K for 51621@debbugs.gnu.org; Tue, 03 Dec 2024 16:14:06 -0500 Original-Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-6eeba477fcaso57344267b3.0 for <51621@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) In-Reply-To: <87jzcgjyek.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:296387 Archived-At: --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 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
On Tue, Dec 3, 2024 at 2:37=E2=80=AFPM Ro= land Winkler <winkler@gnu.org>= wrote:
On Mon, Dec 02 2024, Leo Stein wrote:<= br> > 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<= br> > 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.=C2=A0 Bibtex-mod= e
cannot be blamed for this.

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.
=C2=A0

> I am still missing something... as far as I can tell, the "dialec= t" 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.=C2=A0 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.=C2=A0 It would be confusing for users=
of bibtex-mode to deviate from that.

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.
=C2=A0

> I'm happy to hear that there will be future improvements.

The goal is to facilitate the customization of bibtex-mode.=C2=A0 I see no<= br> 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.=C2=A0 (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=C2=A0bibtex= -parse-entry should be more permissive about parsing types than a predefine= d list from 1988.
--000000000000390edf06286421e0--