An option for not aligning = when JabRef saves/imports bib files as well as adds new entries

[gaochenyi]

Is your suggestion for improvement related to a problem? Please describe.
I raised a question in the JabRef forum but found no solution. I think such an option is lacked in current JabRef stable release (i.e., version 5.5).

Describe the solution you'd like
When JabRef adds new entries as well as formats existing bib files, it can be set to not add extra whitespaces to align = for each field in entries.

Additional context
I would have entries persist like

@Article{key,
  author = {Author},
  title = {Title},
  year = {2022},
}

instead of

@Article{key,
  author = {Author},
  title  = {Title},
  year   = {2022},
}

[Siedlerchr]

Have you maybe checked the option? "Always reformat on save" ? I did a quick test and this seems to work when it's unchecked (you might need to restart after unchecking)

[gaochenyi]

Have you maybe checked the option? "Always reformat on save" ? I did a quick test and this seems to work when it's unchecked (you might need to restart after unchecking)

I have the option "Always reformat on save" unchecked, and my test is done with

1. File -> Import -> Import into new library
2. With a brand new library, I add an entry and fill fields in the built-in entry editor

By the way, I do not have the option "Warn about duplicates on import". I guess we are using different versions. (I am running stable-5.5, i.e., JabRef 5.5--2022-01-17--27a05c7.)

[ThiloteE]

Have you done the test after restarting Jabref after unchecking?

[gaochenyi]

Have you done the test after restarting Jabref after unchecking?

No. This option is initially unchecked. By the way, I upgraded JabRef from 3.8.2 to 5.3 on 2021-11-07, and from 5.3 to 5.5 recently. Is this relevant?

EDIT: I tried the test after resetting preferences and got the same results.

[ThiloteE]

I can reproduce.

• The bib-file does NOT get reformated upon save.
• When reopening the .bib file via File > open library, it does get reformated.
• When importing the .bib file via File > Import > ... it does get reformated.

[ThiloteE]

@koppor

Related: https://github.com/JabRef/blog.jabref.org/blob/add-bibtex-file-changes-over-time/_posts/2020-08-20-bibtex-file-changes-over-time.md

[ThiloteE]

Out of curiosity: How much space would you save removing the empty spaces? How many entries do you have in your library file(s)?

[Siedlerchr]

Hi, this is not possible and I doubt we will add this feature. The alignment was done purposefully, so that users with version control systems or other comparison tools have no weird issues when comparing files.
For a history of the format evolution:
https://github.com/JabRef/blog.jabref.org/pull/47/files

On import and file opening, the bib file is read by JabRef's own Bibtex parser and a new library object is created which uses the alignment in the content serialization which is then also written to the file.

[gaochenyi]

@Siedlerchr The post on format history helps. Thanks.

By the way, could you elaborate a bit on this?

... so that users with version control systems or other comparison tools have no weird issues when comparing files.

I tried but could not figure out such an example.

[gaochenyi]

Out of curiosity: How much space would you save removing the empty spaces? How many entries do you have in your library file(s)?

@ThiloteE Currently I have 500+ entries. So it just saves 64 KiB for each time when I sync with online storage.

[gaochenyi]

Apart from disk space saved by not adding extra whitespaces, aligning = has another possible issue: every time I use a new field for my own purpose (e.g., datereceived for the date when the article was received by the editorial office), if the field name is longer than existing ones, extra whitespaces are added to align = and they causes differences in version control system, since JabRef re-formats entries touched.

[Siedlerchr]

Tagging this as devcall. We need to discuss this in detail.

[koppor]

Just as side note: Example rendering of an dblp entry:

@inproceedings{DBLP:conf/ecsa/OlssonEW17,
  author    = {Tobias Olsson and
               Morgan Ericsson and
               Anna Wingkvist},
  editor    = {Rog{\'{e}}rio de Lemos},
  title     = {The relationship of code churn and architectural violations in the
               open source software JabRef},
  booktitle = {11th European Conference on Software Architecture, {ECSA} 2017, Companion
               Proceedings, Canterbury, United Kingdom, September 11-15, 2017},
  pages     = {152--158},
  publisher = {{ACM}},
  year      = {2017},
  url       = {https://doi.org/10.1145/3129790.3129810},
  doi       = {10.1145/3129790.3129810},
  timestamp = {Sun, 25 Oct 2020 22:44:08 +0100},
  biburl    = {https://dblp.org/rec/conf/ecsa/OlssonEW17.bib},
  bibsource = {dblp computer science bibliography, https://dblp.org}
}

[koppor]

We had a huge discussion on this approx. 5 years ago - see https://github.com/JabRef/blog.jabref.org/blob/add-bibtex-file-changes-over-time/_posts/2020-08-20-bibtex-file-changes-over-time.md.

The only two issues with reformatting is IMHO following:

• Inspecting the diff in "git gui" (or similar git diffing tools) - even a white space change looks like a change
• When a group collaborates on a .bib file AND two members change the SAME entry on different machines (based on the same git commit) AND (at least) one change triggers a reformatting THEN there will be a git merge conflict.

---

Idea: Add database-preference "versioning-friendly writing" (refs some-other-issue-to-store-all-prefs-in-the-database)

(Maybe think of re-ordering fields during write to alphatic-only)

Add to here:

Maybe global default at:

---

Decision:

If four other persons raise their hand in this issue, we will focus on it