Re: [O] Citations, continued

[Nicolas Goaziou]

Rasmus <address@hidden> writes:

> In that case I prefer the explicit extraction of keys below, since I don't
> understand why address@hidden is invalid ("in her seminal address@hidden 
> @k:journal article,
> @k:author demonstrated that ⋯").  Probably I don't understand pandoc well
> enough...

In the initial suggestion @k:journal or @k:author was not possible. In
pandoc, AFAIU, in-text means author is outside parenthesis. Nothing
fancier. So address@hidden would mean: "author" is outside parenthesis, but
should not be displayed anyway.

> It seemed to be the main characteristics of this "locator" that you all
> were talking about...

See, you are talking again about locator...

> Of course not.  That would be idiotic.  But I would rather try to imitate
> the state-of-the-art, which in my book is biblatex, not pandocs.

I'm sure biblatex is powerful, but it's clearly not the state-of-the-art
in readability, and I guess only `latex' would support its features.

Really my concerns are about parsing speed and readability within the
document. Heavy biblatex users will eventually have to fall-back to
LaTeX-specific syntax at some point anyway.

>> If extracting data from an entry is required, then I suggest to extend
>> key syntax, e.g.:
>>
>>   @K1:year
>
> Extracting from a plist-like thingy is easy.

I don't understand.

> What is hard is proper formatting of things like author, e.g. how many
> author to include, adding "and" etc. It would be amazing to let TOOL
> handle this! Unfortunately, good TOOL is scare outside of the
> latex-world (maybe Zotero? I don't know how commandline friend it is).

In any case, this is not the job of Org. At the moment, the goal is to
find a readable syntax that allows to present citation information to
external processors (biblatex, zotero...).

>> I understand, but would it be needed to have both A (Y, C) and A (B, Y)
>> in the same document?
>
> Sure, why not?

I don't know. Pandoc doesn't allow it, and, apparently, nobody
complained enough to add this feature to Pandoc citations. So, either it
is not that useful, or Pandoc citations are hardly used.

>> [pre @k1 post] is slower to parse. 
>
> Is that because you'd have to check all occurrences or [⋯]?

Correct. 

Also, it is ambiguous with link syntax (e.g., if pre begin with "[") and
footnotes syntax.

>> I haven't much against @k1, but it introduces more false positives than
>> address@hidden
>
> It could check if k1 is a known key and interpret "@k1" accordingly.

No it couldn't. Org doesn't know about keys. Or, more precisely, syntax
mustn't depend on known keys. I don't want to make the same mistake as
export blocks (i.e., #+begin_html doesn't mean the same thing if
"ox-html" is loaded or not).

@k1, for some subset of chars within k1, would always be parsed a key,
valid or not. Again, this is not particularly wrong, but it may
introduce false positive from time to time. However, in these cases, we
could use entities to escape "@" from the key.


Regards,