Intolerance to any white space in multiple citation about asciidoctor-bibliography HOT 2 OPEN

@shahryareiv that's indeed an oft-encountered problem with Asciidoctor -- for example, a control phrase that uses underscores or other syntax symbols will get cut off with a linebreak, so it's not a specific issue with asciidoctor-bibliography.

We could possibly support the suggested syntax of cite:[key1;key2;key3]. Thoughts @paolobrasolin @opoudjis ?

from asciidoctor-bibliography.

Thanks for your feedback @shahryareiv!

I initially though about using semicolons as separators myself, but I decided not to in order to offer a syntax reminiscent of other common macros to target a specific indices within a multiple citations:

cite:foo_index[Aa2017]+bar_index[Bb2017]

Ignoring whitespace is technically easy but refraining from it avoided ambiguity in edge cases, e.g. when you'd want a literal + [something] after a citation. It's a bit far fetched, but still possible.

Furthermore, allowing to break the line after + would create a behaviour diverging from the default expected one.

Another point in favour of not allowing line breaks could be that these are an inline macros - but I do realise they can get too long to maintain very quickly.

A solution might be as follows:

// single citation
cite:[foo_key]
// single citation w/ non default target 
cite:my_index[foo_key]
// single citation w/ non default target (alt. syntax) 
cite:[foo_key, target=my_index]
// multiple citations
cite:[foo_key; bar_key]
// multiple citations w/ common non default target
cite:my_index[foo_key; bar_key]
// multiple citations w/ common non default target and a local target override
cite:my_index[foo_key; bar_key; baz_key, target=your_index]

All this while allowing for arbitrary whitespace in the attribute list in canonical way.

On top of that, we could also allow for line breaks within the square brackets; this would be a non canonical behaviour for an inline macro, but might greatly improve its usability.

(If we decide to implement this I'd keep the +-concatenation but drop it at the next major; this syntax seems a bit more reasonable.)

@ronaldtse Any thoughts? My only concern is that allowing line breaks inside the attribute list of an inline macro is a non canonical behaviour.

from asciidoctor-bibliography.