unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Roland Winkler <winkler@gnu.org>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: Lars Ingebrigtsen <larsi@gnus.org>, 56475@debbugs.gnu.org
Subject: bug#56475: 28.1.50; bibtex-parse-entry disregards @string substitutions
Date: Sun, 17 Jul 2022 15:10:39 -0500	[thread overview]
Message-ID: <87edyjsdog.fsf@gnu.org> (raw)
In-Reply-To: <87zgh887et.fsf@localhost> (Ihor Radchenko's message of "Sun, 17 Jul 2022 16:34:02 +0800")

On Sun, Jul 17 2022, Ihor Radchenko wrote:
>>> Also, note that bibtex-string-files cannot help with situations when
>>> the BibTeX buffer does not have an associated file.
>>
>> When does this happen?  To the best of my knowledge, this has never been
>> an issue for users of bibtex.el.
>
> It is more of a hypothetical scenario that might occur in future if Org
> tries to support bibliographies provided inside .org files. Such
> bibliographies will need to be converted to .bib files transiently and
> might not need to be saved on disk.

This sounds to me like reinventing the wheel and a poor design choice.
BibTeX is a well-established bibliography format with a large ecosystem
[(La)TeX].  Also, publishers provide BibTeX records for their journal
articles.  (Occassionally I need to deal with records that have some
other database format like RIS.  Converting formats is always painful.)

From a practical perspective, BibTeX mode is built around the idea that
users may have a large bibliography database.  Something like 10,000
records is not exotic.  Then it is natural to split up these entries
among multiple files.  BibTeX mode and its API support this very nicely.
(I have many little helper functions in my emacs init file that use the
BibTeX mode API.  Maybe I should put some of these also into bibtex.el.)

What are the usage scenarios you have in mind for putting a bibliography
database into org mode that comes with its own database format?





  reply	other threads:[~2022-07-17 20:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-10  7:14 bug#56475: 28.1.50; bibtex-parse-entry disregards @string substitutions Ihor Radchenko
2022-07-11 10:16 ` Lars Ingebrigtsen
2022-07-11 17:12   ` Roland Winkler
2022-07-11 17:29     ` Roland Winkler
2022-07-12  2:32       ` Ihor Radchenko
2022-07-12  4:14         ` Roland Winkler
2022-07-12  6:04           ` Ihor Radchenko
2022-07-12 15:31             ` Roland Winkler
2022-07-17  8:34               ` Ihor Radchenko
2022-07-17 20:10                 ` Roland Winkler [this message]
2022-07-18  4:07                   ` Ihor Radchenko
2022-12-30  6:37                     ` Roland Winkler

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=87edyjsdog.fsf@gnu.org \
    --to=winkler@gnu.org \
    --cc=56475@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=yantar92@gmail.com \
    /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).