Ver 3.1 comment not written correctly.

[zl5877761]

I have a file started with bibtex item, e.g.,

1 @Article{XXXXXX,
2 author = {XXXXXXXX},
3 .........
4 }

when I use 3.1 to save the database, one line break between encoding comment and items is missing, e.g.,

1 % Encoding: UTF-8@ARTICLE{XXXXXX,
2 author = {XXXXXXXX},
3 .........
4 }

please fix it.

[lenhard]

This is not a bug, but the exact desired behavior.

We only modify entries that have been changed by the user, because there was a lot of complaining about this functionality. Every unchanged entry is written back exactly as it was read. So if there was no line break before your entry when loading the file, there will be no line break when saving it back.

You can "fix" your database yourself extremly easy. Just add a line break.

[koppor]

@lenhard Sorry to disagree here. When opening a valid bib file in JabRef and saving it, it should not get invalid. I am aware that we should not add additional newlines at each save (which IMHO would happen if we just wrote a newline after the encoding comment). I nevertheless wonder, why we don't write a newline after that comment 😇.

Does this relate to JabRef#114?

[lenhard]

Ok, I see. The encoding parser throws an exception (which is utterly unrelated to the entry itself).

Unfortunately, there is no good way to fix this. Any optional newline writing will depend on a lot of conditions (first entry unchanged, etc. etc.) and will be quite hacky. I don't have time to do this, so a contribution from anybody else would be more than welcome.

Alternatively: Can't we just eliminate the file header completely? I though it wasn't used anyway?

[tobiasdiez]

The easiest way would be to normalize all new lines in the file (i.e don't save empty lines in the parsed serialization). But I suspect there is a reason why newlines are stored, right?

The file header is used while opening a file (not on importing one - but this is more a bug than a feature).

[lenhard]

Correct, if we do not store the newlines, then we end up reformatting the file on save. Avoiding this was the whole point. (And newlines are the most tricky part that leads to most of the effort regarding file format...).

I will fix this when I find the time, but the earliest possible date for me is JabCon. It shouldn't be too difficult. A fix in the parsing of the file header should be sufficient (to make the parser stop trying to parse the encoding when it encounters an @). Right now it only stops with the first newline. We can also add a test for the parser for this case. If anyone wants to go ahead with an implementation, be my guest.