Hello, "Bruce D'Arcus" <bdar...@gmail.com> writes:
> On Mon, Oct 11, 2021 at 11:54 AM Nicolas Goaziou <m...@nicolasgoaziou.fr> > wrote: >> I don't think that's totally true. The additional space makes sense >> typographically, in particular when some suffix is associated to the >> key. > > Can you give an example of what you mean here? I can't think of one > off the top-of-my-head. I mean that it seems natural to write, e.g., [cite:@doe21 p. 1; @doe99] instead of [cite:@doe21 p. 1;@doe99] >> Org Cite is unrelated to this. One could as well have inserted spaces >> manually, i.e., without calling `org-cite-insert' at all. > > I know; but you changed the default behavior of > org-cite-make-insert-processor. > > The OP asked if there were any implications for this generally, and > I'm just saying "yes, there is." OK. Then, we are in a violent agreement. :) > You do have to trim the whitespace on either side of the key, since > the space is the delimiter. I guess it's not possible for the citation > parser to ignore the other whitespace? I'm not sure to understand your question. The space is not the delimiter; the semicolon is. For now, the whitespaces are significant for the parser, barring the leading and trailing ones. It seemed useful for export back-end and citation processor combinations unable to handle punctuation automatically (e.g., HTML + oc-basic). I can't tell if they should be ignored instead. >> The functions responsible for swapping citations ought to cope with this >> situation >> too. > > So check if the content of an affix, for example, is " " (rather than > whether there's an affix), and adjust accordingly? I don't think you need to check affixes when cycling citation references. You could split at ";", trim, re-order, and re-build the contents inserting "; " between each reference. Regards, -- Nicolas Goaziou