Open ilippert opened 4 years ago
oh, this would be such an amazing feature!
please let us keep this open
I'm thinking about how this feature would be integrated into the usual copy-paste workflow of entries, and I'm finding edge cases that need to be considered. Say we want to copy an entry from Library A to Library B. In Library B when we receive the paste request, we check the crossref field for the referenced entries' citation keys and search for these entries in the opened libraries. This process would result in a conflict if an entry with the same key exists in library C too (Do we fetch the entry from B or C?).
One idea is to remember the last library where we copied something (in the scenario above it would be library A). But then another problem arises if we copy an entry from the web or another program. Let's say we copy from Library A, then copy another entry from the web, and paste it back into JabRef. If JabRef detects that the entry has a crossref field, it'll try to find the referenced entries in Library A because that's where we last copied from. This could result in the fetching of unwanted entries.
We could add a metadata field to the entry that stores the name of the library it came from and delete the field as soon as the entry was pasted. However, when the entry is pasted somewhere else the metadata field stays. Im not sure if that is a big problem, though.
The main issue here is we don't know where the entry came from when we paste it. But when we drag an entry from one library to another, we do know, so that works fine. Another idea is to add a new option called "Copy to" in the right-click menu of the entry. This would let us choose which library to copy the entry to.
There are still some things to figure out:
Present a dialog with choices: This entry references x other entries.
This would be the first thing. Regarding cite key clashes: If an entry with the same cite key is already found in the new library:
a) the user has auto generation of citation keys activated -> This would work after copying. I think similar to importing. b) no auto generation: we skip it and show a warning at the end (e.g. in a "Result dialog" like I did for copying of BibTeX strings)
Follow-up: https://github.com/JabRef/jabref/issues/7057
Regarding recursive, I just stumbled across this section in Tame the BeaST section 12:
One other important remark is that cross-referenced entries must be defined after entries containing the corresponding crossref field. And you can’t embed cross-references, that is, you cannot crossref an entry that already contains a crossref.
So we only have entry A crossref entry B B crossref C would not work
Thanks a lot.
Please confirm/correct: the temporal specifier after refers to the BibTeX processing, not to how JabRef has to handle entries.
Cheers -- Sent from my LineageOS device with K-9 Mail. Please excuse my brevity.
On 20 May 2024 11:13:28 CEST, Christoph @.***> wrote:
Regarding recursive, I just stumbled across this section in Tame the BeaST section 12:
One other important remark is that cross-referenced entries must be defined after entries containing the corresponding crossref field. And you can’t embed cross-references, that is, you cannot crossref an entry that already contains a crossref.
So we only have entry A crossref entry B B crossref C would not work
-- Reply to this email directly or view it on GitHub: https://github.com/JabRef/jabref/issues/6404#issuecomment-2120023988 You are receiving this because you authored the thread.
Message ID: @.***>
Yes, is primarily related to BibTeX processing, it is the order in the bib file itself that needs to be respected, e.g. when saving/writing entries. JabRef respects this so that Entry B is written before Entry A in the file itself. But it does not affect the order in the table itself.
This comes from https://discourse.jabref.org/t/seamless-crossreferencing/100/4
Describe the solution you'd like Consider an entry A that uses a crossref to another entry B. When I copy entry A from one library I to another library II, I want B to be also copied there IF B is not already present in database II.
Advanced request: when inserting entry B, then the normal procedure should be used, checking whether a potential equivalent entry already exists (e.g. same title, editor, but not same citekey).
Equivalently, if library II is a export bib file, it should work, too.