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

Jabref removes comments inside the Bibtex code #1026

Closed
stefan-kolb opened this issue Mar 23, 2016 · 14 comments
Closed

Jabref removes comments inside the Bibtex code #1026

stefan-kolb opened this issue Mar 23, 2016 · 14 comments
Labels
status: waiting-for-feedback The submitter or other users need to provide more information about the issue type: enhancement

Comments

@stefan-kolb
Copy link
Member

@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
Copy link
Contributor

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
Copy link
Member Author

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

@lenhard
Copy link
Member

lenhard commented Mar 23, 2016

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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Member

koppor commented Mar 23, 2016

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
Copy link
Member

lenhard commented Mar 24, 2016

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
Copy link
Member

lenhard commented Apr 1, 2016

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 lenhard self-assigned this Apr 1, 2016
@lenhard
Copy link
Member

lenhard commented Apr 1, 2016

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.

@lenhard
Copy link
Member

lenhard commented Jun 8, 2016

@stefan-kolb: For some external control, could you please try out your example from above with #1471

This should preserve the comment in any case. If the entry is reformatted, an empty line will move between the entry and the comment, if unchanged it should be rewritten exactly as is.

@lenhard
Copy link
Member

lenhard commented Jul 11, 2016

@stefan-kolb: Any updates here?

@lenhard lenhard added the status: waiting-for-feedback The submitter or other users need to provide more information about the issue label Jul 11, 2016
@stefan-kolb
Copy link
Member Author

Right now it keeps the comment, but inserts an additional newline between the comment and the entry.

@lenhard
Copy link
Member

lenhard commented Jul 11, 2016

The newline is inserted if you change the entry, right? That is the desired behavior on reformatting.

If you do not change the entry, the comment should stay as is.

@stefan-kolb
Copy link
Member Author

If that's desired everything is ok now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: waiting-for-feedback The submitter or other users need to provide more information about the issue type: enhancement
Projects
None yet
Development

No branches or pull requests

6 participants