unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: Roland Winkler <winkler@gnu.org>
Cc: 57712@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>
Subject: bug#57712: 29.0.50; bibtex.el: Should `bibtex-parse-entry' handle curly braces inside fields?
Date: Mon, 12 Sep 2022 13:20:18 +0800	[thread overview]
Message-ID: <87bkrlw4ml.fsf@localhost> (raw)
In-Reply-To: <871qsi5wcf.fsf@gnu.org>

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





  reply	other threads:[~2022-09-12  5:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-10  4:32 bug#57712: 29.0.50; bibtex.el: Should `bibtex-parse-entry' handle curly braces inside fields? Ihor Radchenko
2022-09-10  4:39 ` Lars Ingebrigtsen
2022-09-10 16:07   ` Roland Winkler
2022-09-11  5:11     ` Roland Winkler
2022-09-12  5:20       ` Ihor Radchenko [this message]
2022-09-12 13:50         ` Roland Winkler
2022-09-13  2:34           ` Ihor Radchenko
2022-09-13  4:08             ` Roland Winkler
2022-09-14  2:07               ` Ihor Radchenko
2022-09-14 17:02                 ` Roland Winkler
2022-12-30  6:39                   ` Roland Winkler
2022-09-12  5:06     ` Ihor Radchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bkrlw4ml.fsf@localhost \
    --to=yantar92@gmail.com \
    --cc=57712@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=winkler@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).