On Wed, Aug 11, 2021 at 9:53 AM John Kitchin <jkitchin@andrew.cmu.edu> wrote:
> > #+CAPTION: This is the caption for the next figure link (or table)
> > #+NAME: fig:SED-HR4049
> >
> > [[./img/a.jpg]]
> >
> > Or some other metadata on the target?
>
> I don't think metadata on the target helps with the cases described
> above, you can reference a label in different ways at different times to
> get different meanings.
OK, this clarifies a key piece then.
I agree then: target metadata alone isn't enough.
So I see two options:
1. per my original response, allow optional typed internal links; e.g.:
[[fig/foo:file]]
This is a bad idea to me. It is only a fuzzy link (what you call a typed internal link) if no one has defined it as an external link. As soon as that happens, then you will lose the export behavior defined for fuzzy links, and get the behavior defined by the export function. The syntax for these is the same (I guess a fuzzy link must be wrapped in [[ ]], but an external link may also be wrapped that way). I don't see a way to differentiate these.
To be clear, with this idea, I'm suggesting an alignment between
external links (which already have similar types) and internal (which
do not).
IUC, org-ref is using *external* link types (not internal links) to
make these distinctions?
Yes, org-ref uses external links, defined by org-set-link-parameters.
2. extend citations, per your idea here, which to me means the
org-cite code would need to be revised and expanded to handle both
cross-references and citations, but do so distinctly.
I don't think so. You only have to extend them where you want to have the capability. org-cite can stay a citation only body of code, and if you want cross-references too you just use my processors, or write one that does what you want.
E.g. an export processor like oc-csl would need to handle these
cross-references in that code, but pass the citations per se to the
citeproc-el backend, which should not need to worry about
cross-references.
Again, not necessarily, this is handled in the export processor, and it can differentiate which citations are sent to oc-csl and which are handled differently based on the style.
Likewise, as a front-end developer, I don't want to deal with
cross-references at all, so I should be able to ignore them in my
insert and follow processors, in the same way you would need to be
able to include support for them.
You don't have to. Your processors should fail gracefully in any case, because you just cannot control what people will do with the styles.
And activate processors would need to be updated to distinguish them somehow.
Right now this just looks like
(when (org-ref-cite-ref-p reference) ...)
My activate processor just runs a bunch of functions and those functions can do nothing if needed.
Right?
It seems to me 1 is the easier path, both practically and
conceptually, unless I'm still missing something (which is certainly
possible).
The biggest issue with 1 is I don't think it is possible to differentiate internal typed links from external links because they use the same syntax. It would be very difficult to support and troubleshoot a scenario where the same syntax shows different behavior depending on whether an external link is defined or not. Finally, it is so close to what org-ref already does, I think it is too tricky to differentiate [[ref:label]] from [[ref/:label]], etc.
Maybe these links would look different enough (as external links) that it would be really clear you were not using org-ref.
ref/:@label
ref/eq:@label
ref/page:@label
ref/name:@label
ref/c:@label
ref/C:@label
However, this doesn't support using prefix/suffix text, which is one of the main reasons the cite syntax came to be.
Bruce