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

[Ihor Radchenko]

Roland Winkler <winkler@gnu.org> writes:

> 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.

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.

What to do with the braces is another question and has nothing to do
with bibtex.el. It is to be decided by Org.

> 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.)

bibtex-summary approach might be an option, although it is clearly an
abuse and begs for future bugs.

However, there are at least several issues with, say,
`bibtex-autokey-get-title':
1. Its docstring does not clarify which variables affect the return
   value and does not even mention that the actual title contents is
   transformed in any way.
2. It simply strips the curly braces.
   `bibtex-autokey-titleword-case-convert' is applied regardless of the
   braces.

-- 
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