From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Roland Winkler Newsgroups: gmane.emacs.bugs Subject: bug#57712: 29.0.50; bibtex.el: Should `bibtex-parse-entry' handle curly braces inside fields? Date: Wed, 14 Sep 2022 12:02:24 -0500 Message-ID: <87v8ppvqhr.fsf@gnu.org> References: <87k06b26iu.fsf@localhost> <87r10jrgf4.fsf@gnus.org> <87zgf75i32.fsf@gnu.org> <871qsi5wcf.fsf@gnu.org> <87bkrlw4ml.fsf@localhost> <8735cw3dnm.fsf@gnu.org> <87pmg0t31x.fsf@localhost> <874jxbzzk4.fsf@gnu.org> <87zgf2yai6.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5353"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 57712@debbugs.gnu.org, Lars Ingebrigtsen To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 14 19:47:49 2022 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 1oYWUG-0001GA-NK for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 14 Sep 2022 19:47:48 +0200 Original-Received: from localhost ([::1]:48210 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oYWUF-0007o4-Ny for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 14 Sep 2022 13:47:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42280) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYVmx-0003Iy-03 for bug-gnu-emacs@gnu.org; Wed, 14 Sep 2022 13:03:09 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39020) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oYVmw-0004hz-Lf for bug-gnu-emacs@gnu.org; Wed, 14 Sep 2022 13:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oYVmw-00066k-Gc for bug-gnu-emacs@gnu.org; Wed, 14 Sep 2022 13:03:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Roland Winkler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 14 Sep 2022 17:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57712 X-GNU-PR-Package: emacs Original-Received: via spool by 57712-submit@debbugs.gnu.org id=B57712.166317496623439 (code B ref 57712); Wed, 14 Sep 2022 17:03:02 +0000 Original-Received: (at 57712) by debbugs.gnu.org; 14 Sep 2022 17:02:46 +0000 Original-Received: from localhost ([127.0.0.1]:55948 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYVmg-00065z-EY for submit@debbugs.gnu.org; Wed, 14 Sep 2022 13:02:46 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42088) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYVme-00065c-2C for 57712@debbugs.gnu.org; Wed, 14 Sep 2022 13:02:45 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48232) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYVmL-0004cS-QG; Wed, 14 Sep 2022 13:02:38 -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=Ejw0yhfu7ClTdyhuL32jJM6JMsjJrCeAM+B5nmIiVJU=; b=HdsDpWtOtLskbwGQxeb+ +KXDqQZ49ttLslACJhxFVX06AFe5CGhl5x9/cJLCldalOJYuqLnqucboBi+MnOYkn1VtttvJo8fG5 YVmaBh9Tl2S8ygC02mpjTeb+XVSwFAY1VUG/jupUbWTKWhqZl6qhXbCjV1golJEZa5Tn8+buX0G2E w9OLWwZhW4xigYGb5IVNyj9ZK5F45bHKkVP9IJQ61Y8gXPDH4VfnlaqRTj8BiIBjxKMHU+qayCgcG uenubzSZmv7KaCTq6YQTbuXfWUgF4hhJ2HWpyp3my8SbWO1EmQaGu8mMRJGtCkKXY/4qC6BA1SPew kRl0pv9gwq7PFA==; Original-Received: from [2600:1700:5650:f790::42] (port=40262 helo=regnitz) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYVmK-0002xA-Qi; Wed, 14 Sep 2022 13:02:25 -0400 In-Reply-To: <87zgf2yai6.fsf@localhost> (Ihor Radchenko's message of "Wed, 14 Sep 2022 10:07:13 +0800") 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" Xref: news.gmane.io gmane.emacs.bugs:242498 Archived-At: On Wed, Sep 14 2022, Ihor Radchenko wrote: > I am looking at this differently. Similar to BibTeX fields, text in the > fields is a subject of a specific format. That format is _not_ exactly > the same with TeX (e.g. see > https://tex.stackexchange.com/questions/26338/how-to-code-%C3%9F-german-sharp-s-in-bibtex) No, the problem discussed there exists exactly the same way within any LaTeX document. I deal with this frequently, both in the context of LaTeX and in the context of BibTeX. The content of BibTeX fields must always be valid from LaTeX's perspective that will digest them. (BibTeX never checks itself whether the user made an error from LaTeX's perspective. BibTeX generates bbl files that are then processed by LaTeX. LaTeX will choke over malformed BibTeX fields the same way it will choke over invalid constructs in any LaTeX document.) > I expect bibtex.el to handle all the peculiarities of BibTeX format, so > that external packages do not need to perform extra parsing. There are only two issues beyond the oddities of LaTeX itself - BibTeX string constants - BibTeX crossref'ed entries when a field is absent in an entry because it is present in a "parent" entry. (There is also the odd behavior that standard BibTeX style files want to downcase the content of the BibTeX "title" field, and this can be suppressed by putting curly braces around the characters. But the way this works is that these braces are preserved in the bbl file generated by BibTeX, and LaTeX will simply ignore them. The braces do not violate the rule that the content of BibTeX fields must always be valid from LaTeX's perspective.) > If you dislike modifying bibtex-parse-entry, bibtex-parse-field-text > looks like a reasonable place to handle field text parsing. Both BibTeX string constants and BibTeX crossref'ed entries are handled by bibtex-text-in-field. (As we discussed previously, expanding string constants requires bibtex-expand-strings to be non-nil.) Then bibtex-text-in-field always returns valid LaTeX code (provided the user did not make any LaTeX mistakes in her fields, see above). As I said before: if this doesn't fit your needs for org mode, I suggest you develop a LaTeX parser that can process LaTeX code according to your needs. Then you can feed it with any valid LaTeX code including the return values of bibtex-text-in-field.