Jabref removes comments inside the Bibtex code

[stefan-kolb]

@lenhard Do we intend to do this? i thought we keep the source as is if possible?

%% author = {Ahronovitz, Miha and Amrhein, Dustin and Anderson, Patrick and De, Andrew}
 @misc{Ahronovitz2010a,
 author = {{Cloud Computing Use Case Discussion Group}},
 title = {Cloud {Computing} {Use} {Cases} {White} {Paper} - {Version} 4.0},
 date = {2010-07}
 }

Will get

 @misc{Ahronovitz2010a,
 author = {{Cloud Computing Use Case Discussion Group}},
 title = {Cloud {Computing} {Use} {Cases} {White} {Paper} - {Version} 4.0},
 date = {2010-07}
 }

This will only be done when changing the entry right?

[oscargus]

Everything outside of an entry is a comment and should, if possible, be kept. This is not an answer to your question though, just a statement.

[stefan-kolb]

Actually it is not at the moment at least for me.

[lenhard]

I assume that the comment will be overwritten if the entry is reformatted. Otherwise, it is kept as part of the parsed serialization of the entry.

As far as I know, JabRef has always overwritten such comments, but we might consider to change this functionalty (this has strong implications on parsing/writing)

[tobiasdiez]

Right now everything not contained in an entry (or @comment tag) is completely ignored by the parser. In particular, it is not saved anywhere and gets lost on rewrite. The problem with this floating-around text is that is not connected to any entry and thus the new position of it can not be determined on save. By the way, even user-defined @comment tags get lost.

[oscargus]

I can understand that it is hard to keep everything for sure and I think that it is OK to some extent. If you use JabRef you do not need to do manual edits...

[koppor]

The fact that JabRef destroys content of the the bib file often prevents users to switch from plain text editing to JabRef. Therefore, I would propose to add a data structure to BibEntry which keeps the text lines above (somehow). Maybe, we offer a separate tab offering "Comment" showing the lines above the bib entry.

[lenhard]

Adding a datastructure to BibEntry that keeps the lines above wouldn't actually be too difficult. The parser reads it like that already. But then, what happens to

• all the comments below the last entry
• comments that are mixed between meta data entries
• comments between the first entry and the file header (special handling here)

[lenhard]

From Devcall: We will try to keep all text in the file at the same position. I will have a look at how to implement this.

[lenhard]

I had a first look at this. Unfortunately, this would be very very very ugly. It would essentially require a rewrite of the parsing logic. As it turns out, arbitrary comments are not stored at the moment even for the parsed serialization.

A few things contribute to making this complicated:

• We have a specific comment that we do not want to keep: The encoding file header at the begin of a file. This is really a major reason for complication and the origin of a lot of specialist code, since we cannot just plainly keep all text, but need to decide somehow. How should the parser detect the structure of the header, since that structure is not predefined (many possible different encodings)? Also what about 'random' file headers in the middle of the file? So far, the parser parses each entry regardless of its position in the file. This would no longer work if we want to remove only the first file header and keep everything else. Thus parsing would become more complex.
• We have a 'gray' area that is rewritten every time: Meta data, strings, and the preamble. Here, no additonal text in between meta data entries is stored so far and storing it will require a major restructuring of our MetaData class.

Since the serialization details are quite a nasty and un-fun part of work I hesitate to revisit (I have spent a good dozen hours only to get newline parsing correct for all of many different occasions) and it is not very motivating to throw large parts of what I wrote during the last three versions into the gutter again, I might not volunteer for implementing this.

Btw.: If it helps, currently all text after the last entry is kept.