GNU bug report logs - #57712
29.0.50; bibtex.el: Should `bibtex-parse-entry' handle curly braces inside fields?

Previous Next

Full log

Message #14 received at 57712 <at> debbugs.gnu.org (full text, mbox):

From: Roland Winkler <winkler <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 57712 <at> debbugs.gnu.org, Ihor Radchenko <yantar92 <at> gmail.com>
Subject: Re: bug#57712: 29.0.50; bibtex.el: Should `bibtex-parse-entry'
 handle curly braces inside fields?
Date: Sun, 11 Sep 2022 00:11:28 -0500

On Sat, Sep 10 2022, Roland Winkler wrote:
> I must be missing something.

I looked at the original org bug report that triggered the present
report.  I guess that now I understand what the OP is concerned about.
I believe that bibtex-parse-entry is not the right place to try to fix
this.  The problem is to define what an optional arg CONTENT should do.

I do not know what the "basic org cite export processor" mentioned by
the OP is doing in detail.  But it reminds me of bibtex-summary which is
the default value of bibtex-summary-function.  This function generates a
"human-readable" summary of a BibTeX entry.  It uses the autokey
machinery of bibtex-mode that was originally developed for generating
keys for new BibTeX entries.  But this machinery can easily be "misused"
for things like bibtex-summary.  The point is that it offers rather many
options to customize what such a summary should look like.  Say, an
entry has 20 authors.  Do you want to display three or four authors?  Do
you want to just put dots after the third author or "et al."?  Should the
author(s) come first or should the title come first?  Should the year
appear before or after the title?  (Essentially, you can go through all
the questions relevant for BibTeX style files; but the autokey machinery
comes with the power of emacs :-)

So I suggest that the  "basic org cite export processor" could use
something similar to bibtex-summary.  But this should just be the
default value of something similar to bibtex-summary-function so that
users can customize this more easily.

(Letting users define their personal bibtex-summary function is probably
easier than trying to define some user variables that can control this.
There are just too many possibilities how one might want to customize
things.  My personal bibtex-summary function does a couple things that
nobody else might like, but they are important for me.)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.