Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Save custom entry types in bib file #365

Closed
stefan-kolb opened this issue Nov 18, 2015 · 11 comments
Closed

Save custom entry types in bib file #365

stefan-kolb opened this issue Nov 18, 2015 · 11 comments

Comments

@stefan-kolb
Copy link
Member

Problems might occur when custom types are stored in the file and in the preferences and have the same name. How are these and other similar cases handled?

@koppor
Copy link
Member

koppor commented Nov 18, 2015

How does this relate to #181? I thought, JabRef writes custom entry types. The experiments state that custom entry types are only written if they are used in the bib file. Maybe this should be changed to a way that all custom types should be written. I don't know how JabRef deals with multiple definitions. Say you define @Collection to have numpages and I call that field pagetotal. What happens then?

@koppor
Copy link
Member

koppor commented Nov 23, 2015

This is a bug introduced in the last updates of JabRef. Reproduce by: Load and save issue_181_1.8.0_60-b27.bib. Then, the following line gets lost:

@comment{jabref-entrytype: Collection: req[booktitle;editor;publisher;year] opt[abstract;month;number;series;volume]}

When creating that file on October, 11th by JabRef, the line was written. Only if a @Collection entry was present, but it was written in that case. Now, it is not written any more.

@koppor koppor added this to the v3.0 milestone Nov 23, 2015
@koppor koppor added the bug Confirmed bugs or reports that are very likely to be bugs label Nov 23, 2015
@oscargus
Copy link
Contributor

It might be because collection is natively supported in Biblatex?

@koppor
Copy link
Member

koppor commented Nov 23, 2015

Oh, yes. I recently switched to biblatex mode. Maybe, the test case should be adapted to work on both biblatex and bibtex mode. Don't know how to deal with that case. Think, that makes sharing of bib files across users using different bibtex modes difficult.

Refs koppor#28 and #167.

@simonharrer simonharrer added type: question and removed bug Confirmed bugs or reports that are very likely to be bugs labels Nov 23, 2015
@koppor koppor removed this from the v3.0 milestone Nov 23, 2015
@stefan-kolb stefan-kolb added bug Confirmed bugs or reports that are very likely to be bugs and removed type: question labels Dec 9, 2015
@stefan-kolb
Copy link
Member Author

@koppor Does this bug still exist in the new version, where we implemented file-based BibTeX/Biblatex support?

@koppor
Copy link
Member

koppor commented Mar 13, 2016

Yes, the bug still exists. Not sure whether it is really a bug. Steps to reproduce:

  1. Open src\test\resources\testbib\issue_181_1.8.0_60-b27.bib
  2. Save
  3. Diff

Expected result: @comment{jabref-entrytype: Collection: req[booktitle;editor;publisher;year] opt[abstract;month;number;series;volume]} is kept in the file

Real result: That line is deleted.

@tobiasdiez
Copy link
Member

There is a test writeEntryWithCustomizedTypeAlsoWritesTypeDeclaration in BibDatabaseWriterTest which can be adopted to this case.

@stefan-kolb
Copy link
Member Author

#772

@tobiasdiez
Copy link
Member

tobiasdiez commented May 11, 2016

The BibDatabaseWriter contains the following comment

// Check if we must write the type definition for this
// entry, as well. Our criterion is that all non-standard
// types (not all customized standard types) must be written.

The code explicitly checks if the type is a standard type and in this case does not write the type.
So this behavior seems to be "by design".

If this check is removed then one probably runs into a lot of "has the same name" problems.

@tobiasdiez tobiasdiez added type: enhancement and removed bug Confirmed bugs or reports that are very likely to be bugs labels May 11, 2016
@matthiasgeiger
Copy link
Member

I implemented in the course of #2331 a notification (upon opening a bibfile with customtypes) that warns if some customizations will be overwritten.

Regarding the file link by @koppor ( https://github.com/JabRef/jabref/blob/master/src/test/resources/testbib/issue_181_1.8.0_60-b27.bib) this file is automatically detected as a Biblatex file (due to the usage of collection) and thus the entry customization is ignored (see last comment by @tobiasdiez).

What should we do with this behavior? Shall we stick to the comment with the following semantics "Our criterion is that all non-standard types (not all customized standard types) must be written." - or should all customizations of types be added?

Using the mentioned notification serializing (and loading) customizations of standard types might be an option...
However, this might be quite annoying if a bibfile is used by more than one user with different settings.

@koppor
Copy link
Member

koppor commented Apr 24, 2017

DevCall decision:

  • Standard types not serialized
  • In case a user group agrees to change the standard types, they have to use the export/import preferences functionality

Possibly future work could be: Specific export/import functionality for customized entry types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants