JabRef adds newlines when writing jabref-meta: groupstree:

[bluebirch]

When JabRef writes jabref-meta data in @comment{} entries, it uses a fixed line with. Other programs that read and write the BibTeX file might not care about newlines in comments. An example of this is biber, wich I try to use as a BibTeX pretty-printer. Minimum working example:

Consider the following BibTeX file written by JabRef:

% This file was created with JabRef 2.11b4.
% Encoding: UTF8


@Misc{Paranoid2015,
  title           = {Don't Talk to Me About Life},
  author          = {Marvin the Paranoid Android},
  date            = {2015-10-21},
  date-modified   = {2015-10-21}
}

@comment{jabref-meta: groupsversion:3;}

@comment{jabref-meta: groupstree:
0 AllEntriesGroup:;
1 ExplicitGroup:Statically group entries by manual assignment\;0\;Para
noid2015\;;
}

Note the newline in the middle of a BibTeX key. When processing this file with the current development version of biber (previous versions removed comments altogether), it comes out like this:

@MISC{Paranoid2015,
  AUTHOR        = {Marvin the Paranoid Android},
  DATE          = {2015-10-21},
  DATE-MODIFIED = {2015-10-21},
  TITLE         = {Don't Talk to Me About Life},
}

@COMMENT{jabref-meta: groupsversion:3;}
@COMMENT{jabref-meta: groupstree: 0 AllEntriesGroup:; 1 ExplicitGroup:Statically group entries by manual assignment\;0\;Para noid2015\;;}

Note that the newline in the BibTeX key is converted to a space (Para noid2015), which breaks the groups tree.

Now, this could be considered a bug in either biber or JabRef. I tend to blame JabRef, since I can't see any reason why JabRef should write fixed-with @comment entries and thus rely on truly verbatim treatment of @comment entries.

[plk]

As the biber developer, I can say that bibtex libraries tend to remove newlines when reading comments and so if you have to output them again (which biber tool mode does), you lose any verbatim formatting. So, relying on newlines in comments for any processing decisions is generally a bad idea.

[matthiasgeiger]

Agreed.
And JabRef (and the group functionality) is not relying on the verbatim structure.

The only problem here is the inserted space within a Bibtex key - but I would say that this is also an issue on our side, as breaking within a BibTeX key is not the best idea 😉

[lenhard]

So what would a fix to this look like? Disable line wrapping in JabRef?

[matthiasgeiger]

Breaking after word boundaries?

[plk]

Why break lines?

[lenhard]

There are preferences for line wrapping, but I cannot find an option to set the line width in the GUI. Maybe line wrapping was meant to be deleted anyway. I would be very much in favor of this. I do not see why we need line wrapping at all. Related: #116

By the way, I do not think that this will be implemented for 2.11, but instead for 2.80.

[matthiasgeiger]

Line breaking in the group serialisation seems to be independent from the globally defined linebreking, as this are the only lines wrapped in my dummy bib file. So it should be rather easy to remove the line breaks for group definitions.

[stefan-kolb]

👍 for removing any line breaking functionality in metadata fields. Other line breaking is not affected by this bug.

[matthiasgeiger]

I removed the hard-coded line breaking for MetaData in 4c25b6a.

@bluebirch Can you please test with this shapshot https://circle-artifacts.com/gh/JabRef/jabref/837/artifacts/0/home/ubuntu/jabref/build/releases/JabRef-2.80dev--snapshot--2015-10-21--fix-metaData-linebreaking--4c25b6a.jar whether the problem is solved in your workflow using biber. Thanks!

[lenhard]

@matthiasgeiger: how about writing a serialization test that uses the entry sample from @bluebirch, writes it to a file and checks that the file is correct? :)

[bluebirch]

@matthiasgeiger That solved the problem, thank you.

On a side note, I wonder why not write the groups tree in standard XML or something instead of some kind of obscure CSV format? :-)

[koppor]

Historical reasons. I don't know, if JSON can be nested in BibTeX (special characters?). Currently, that would be my favorite as we don't need the extensibility of XML (and I am a real XML fan 😇)

[bluebirch]

I would guess anything that does not depend on newlines, indents and so on is feasible. However, I suspect brackets ({}) would be prone to break more than one bibtex parser, which unfortunately rules out JSON.

[bluebirch]

Is this bug fix back-ported to 2.11?

[matthiasgeiger]

No. 😞

[koppor]

@bluebirch Could you try the 2.11 development at http://ge.tt/9Idc446? We tried to backport the fix.

[bluebirch]

Sorry for a late response. Obviously, it was backported to 2.11.1, and it seems to work. Thank you.