Use org.jabref.model.entry.KeywordList#parse(java.lang.String, java.lang.Character, java.lang.Character) and then work on KeywordList

Reason: Better data structure and adheres to user configuration (keyword delimiter) and escpaings.

See at other usages of the parser and how to pass the prefernces

At first, I thought:

but this is wrong, because no escaping treatment etc.

Needs to be reviewed in IDE - why this general method is needed - until now, this was not needed - and the formatter worked.

I had no way to retrieve BibEntryPreferences so that I could call getKeywordSeperator. This is used to inject preferences so that the formatter can use a dynamic delimiter.

If there is another method of retrieving BibEntryPreferences pleases lmk.

Why is getInstance() deprecated for JabrefCLIPreferences Class? Isn't the point of this class to allow preferences to be accessible globally. @koppor

I feel like it defeats the purpose to implement a Singleton design that isn't easily accessible. 😅

Preferences are indeed singleton but nonetheless you should avoid calling get instance as it creates a tight coupling between the two classes and hinders testing.
That's why you should pass or inject them via constructor so you can still mock them

Thanks for clarifying. @Siedlerchr

That said, do you think my approach was correct?

Creating a new constructor for FieldFormatterCleanups
In JabrefCliPreferences, passing BibEntryPreferences to this constructor
Finally, passing those preferences down to the formatter to get the keyword separator.

Where is your method used? I did I do a mistake at checking out your branch?

I think, in this case, it is OK to use Injector.instantiateModelOrService(CliPreferences.class) and then get your preferences for that.

Do this at the latest point in time - and do not initialize a default value ,

Note that you already have

    Character dlim = preferences.getKeywordSeparator();

At this place, use this injector "magic".

Add a javadoc comment to the class that it relies to on Injector.instantiateModelOrService(CliPreferences.class), and add a reason. Maybe "because routing through this dependency causes too much changes."

Where is your method used? I did I do a mistake at checking out your branch?

My fault, I think I forgot to change this (I was testing setter vs constructor injection), I put it in this method of JabRefCliPreferences initially.