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

Previous Next

Full log

View this message in rfc822 format

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: Roland Winkler <winkler <at> gnu.org>
Cc: 57712 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: bug#57712: 29.0.50; bibtex.el: Should `bibtex-parse-entry' handle curly braces inside fields?
Date: Tue, 13 Sep 2022 10:34:50 +0800

Roland Winkler <winkler <at> gnu.org> writes:

> On Mon, Sep 12 2022, Ihor Radchenko wrote:
>> To clarify, I do not expect bibtex-parse-entry to strip the braces. What
>> I'd like to see is _parsing_ braces (say, as sexp) and other special
>> BibTeX syntax. At least, as long as appropriate option is passed to
>> bibtex-parse-entry.
>
> Can you give some examples of what you believe bibtex-parse-entry should
> do if it had an optional arg CONTENT?  What should it return instead of
> what it returns without such an arg?

Consider the following title:

  title           = {{Introduction $3^5$ to Mark\.{o}v Chain {MOnte} Carlo \LaTeX}},

(bibtex-parse-entry '(symbols braces mathmode latex strings))

will return

'("Introduction " (mathmode "$3^5$") " to Markȯv Chain " (braces "{MOnte}") "Carlo" (latex "\LaTeX"))

that is
1. Escaped symbols are replaced by their unicode
2. Braces are indicated by (braces "string")
3. LaTeX math is indicated by (mathmode "math string")
4. LaTeX commands are indicated by (latex "command")
5. @strings are replaced appropriately

>> bibtex-summary approach might be an option, although it is clearly an
>> abuse and begs for future bugs.
>
> My point is: the meaning of CONTENT may largely depend on what the
> caller of bibtex-parse-entry wants to achieve.  What appears perfectly
> reasonable from your perspective may be meaningless from another
> perspective.  That's why the autokey machinery comes with lots of
> options in terms of user variables, plus the option of letting the user
> ignore all of this and define her own function (both for automatically
> generating a key and for generating a summary for an entry). -- It's not
> a perfect solution.  But it has worked well for many years.
>
> A single arg CONTENT (trying to guess "do what I mean") cannot cover all
> this in a satisfactory way.

It can, if it is something like a plist. Note that I do not insist that
CONTENT value must be the only way to control the function behaviour.
Using let-bound variables is another valid option. But all the affecting
variables should be documented in the docstring then.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Previous Next

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