Rasmus <ras...@gmx.us> writes:
> In that case I prefer the explicit extraction of keys below, since I don't
> understand why [-@k1] is invalid ("in her seminal -@k @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 [-@k1] 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
>> [@k1].
>
> 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,
