Fix mixed CRLF / CR

[koppor]

Sometimes, JabRef writes BibTeX files with mixed line endings. This PR fixes that.

I implemented a new class BibWriter, which works similar to StringJoiner, but more tayloured to support our use case. The main ideas are a) newlines are normalized during write and b) the writer is aware of blocks. That way, the empty newline separating two entries is now a kind of internal data and not associated to any of the two entries. Moreover, there is no leading empty line at the beginning of a .bib file anymore. --> fixes koppor#390

While I was on it, I also removed the % Encoding: UTF8 preamble, because Unicode is the most common encoding for the WWW since 2008.

A bib file should keep the line break style. When collaborating on a network drive with different operating systems, the line breaks surely differ from the linebreaks in local files or in a drop box. Thus, the linebreaks of the .bib file itself should be respected. This is implemented in this PR. This fixes https://sourceforge.net/p/jabref/feature-requests/857. (See also #4877 (comment)).

and the setting "Newline separator" should a) be respected, b) the newline separator of the .bib file should be used (because in the case of multiple bib files, the separators might vary from file to file). -- The implementation of the latter is prepared. "Just" need to finish it.

---

• Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (for UI changes)
• Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

[Siedlerchr]

Might be Related

jabref/src/main/java/org/jabref/gui/fieldeditors/AbstractEditorViewModel.java

Lines 66 to 75 in 079a2d2

	if (newValue != null) {
	// Controlsfx uses hardcoded \n for multiline fields, but JabRef stores them in OS Newlines format
	String oldValue = entry.getField(field).map(value -> value.replace(OS.NEWLINE, "\n").trim()).orElse(null);
	// Autosave and save action trigger the entry editor to reload the fields, so we have to
	// check for changes here, otherwise the cursor position is annoyingly reset every few seconds
	if (!(newValue.trim()).equals(oldValue)) {
	entry.setField(field, newValue);
	UndoManager undoManager = JabRefGUI.getMainFrame().getUndoManager();
	undoManager.addEdit(new UndoableFieldChange(entry, field, oldValue, newValue));
	}

[koppor]

This PR makes #8239 still necessary. - This PR "only" ensures that line endings are consistent when writing. The implementation here decided to normalize right before the writing. That means, methods to change field contents etc are left untouched. The decision was to have one single place to ensure consistency than touching all methods handling field content. I know that this is not the best solution: Field contents should also be normalized so that algorithms working on it work correctly. Nevertheless, this is IMHO a big step in the right direction and makes JabRef working good again.

[Siedlerchr]

You need to remove the comment In OS.java

  // Newlines
    // will be overridden in initialization due to feature #857 @ JabRef.java