From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id yOimAkflE2HcBwAAgWs5BA (envelope-from ) for ; Wed, 11 Aug 2021 16:57:11 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id WA1HOkblE2F5eAAAB5/wlQ (envelope-from ) for ; Wed, 11 Aug 2021 14:57:10 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id AB0F9A803 for ; Wed, 11 Aug 2021 16:57:09 +0200 (CEST) Received: from localhost ([::1]:38224 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mDpfH-0001os-9k for larch@yhetil.org; Wed, 11 Aug 2021 10:57:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49358) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mDpee-0001XD-V1 for emacs-orgmode@gnu.org; Wed, 11 Aug 2021 10:56:28 -0400 Received: from mail-lf1-x12d.google.com ([2a00:1450:4864:20::12d]:39524) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mDpec-0001z6-8A for emacs-orgmode@gnu.org; Wed, 11 Aug 2021 10:56:28 -0400 Received: by mail-lf1-x12d.google.com with SMTP id t9so6346852lfc.6 for ; Wed, 11 Aug 2021 07:56:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andrew-cmu-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/L3TUgr2K+vh+fpJcUaFTVoJf6WeAS76OggkHaqLrG4=; b=FcyDxGwu9KQj6Eae8nYdXcqr+zzlhc8h3bZBDDm08YO919lpjbLmm7EtktKyVGMiGV 3i10u4Kxh7iWE9iJ22kwWRgLr9mYAzO0KFmDNqxw4lN1deSy+AwZhrsIY20fmEWR/ec8 83P8JKclHCMAkyoXbazhJDHaw7TaFnrXdh6+DrrcAEQ137Bi7bmrdZAtD9wG8xANRTYv YbqeWlQBL25Qrsm83pXBC7/34WYCmTYWr6nsPdh2FYM+NtQyp9X0p7zEM2bOe1DCc3Np kjuCLfucCOARp+xXeqYSszom0kttI8JHS3z08rn+6teRTY1RG2UF1MjbMmHzczdPecT5 VfKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/L3TUgr2K+vh+fpJcUaFTVoJf6WeAS76OggkHaqLrG4=; b=m5OkDY5Vpsax+8Ajv/8fFTMgrz7IsKCpGQOB3NEbnDvdlv6z0DzfKTefZu9QturWvc 9WfE23bnCi+l4wy0+RhUxdy3uSAbXvyNf6PNHI09i4e+XlEApmQWrTXUvl13t7OtLVN4 HpsfbZ7d3A9JhgGpqkM+IPgwZRBEzKyRPTBR8yy5UFUC9SF0Vx49T7IbRDW4gYz8+gKU b6Eo3+G8JTnt0Zn8Q2JVFg1Y6YuLnlIPYGYcIllEnfeq2zHZM3qknRO2G4X2Efg1L9gs 3w66uHi0H5XUOqg5Ke7YZpkvWsso/+PDiWxS6tEsfU7E+BsD9XLMqOiAqaFvMzCODVqW V2rg== X-Gm-Message-State: AOAM531YEMcIGWZHAsoaAtBIUjYgP9oQNY/X7nkO7W2Cx9T8mWmvRzyX kgn7inmbycHBg3Iwqh+l3e7UYNlyU813FGVAzwM= X-Google-Smtp-Source: ABdhPJxqL1R2FigkVMc8kso20ucMgj5RZHS6332FuyP1AZ5Dxdd9vgwSrBugkB3mrhGgY7s37H80T2bszo/lReUbXnY= X-Received: by 2002:a19:f719:: with SMTP id z25mr3328335lfe.339.1628693784353; Wed, 11 Aug 2021 07:56:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: John Kitchin Date: Wed, 11 Aug 2021 10:56:12 -0400 Message-ID: Subject: Re: Expanding how the new cite syntax is used to include cross-references - thoughts? To: "Bruce D'Arcus" Content-Type: multipart/alternative; boundary="00000000000076df7e05c949d2b1" Received-SPF: pass client-ip=2a00:1450:4864:20::12d; envelope-from=johnrkitchin@gmail.com; helo=mail-lf1-x12d.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tom Gillespie , org-mode-email Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1628693830; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=/L3TUgr2K+vh+fpJcUaFTVoJf6WeAS76OggkHaqLrG4=; b=W4nS7hj2yUXk8SvW+tq+i6131hGCT3svVLoKBBcqKn8qWFB7eg30/ftldmEiTKRklCwHin XyH8jWcZZ75qdJEDIHe5AwV54zCqcLALKDkY7Nl0GAjFyHa/h3ohE6nAPtOGBfngZtOi43 zRDOOxnEDW6S3QluNcXFULqaBlP9UZlOW9+xjibY2YXF+Z11n/VTnsaRsIbzKtN6SOV8Hg WdLvynhKC10ZOjsypNTZTn8s6sO5MQozNRFajjNiVkT9L9xbwbqiRwqJjbpNqHXc2np7lR r0EyoeKCRZM1ZFICOOIRMVfh/iazI6ATZ/nJL3ws7u0qYuSoXgaqV3rn2alpXA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1628693830; a=rsa-sha256; cv=none; b=Mpbv8vF3rPheSFXUxQ4hPON5lXAcwEBnfYP35DIPPt+GifRgTKjhFGAeHHKEupq4i2kYex Uez9dXoSmso5JYivPHzv1CTuyA2EDAq5BOKwzfIxOhK7JBpVTMB+JFbuF44/a0KIp2ltOY knvuiAtOnIA+9J0azY/MgsVRZjts00dSq6HlBWAyemwmkzVHN9WRoAnfyAAgFQAefiPgLT NkylOB1eFGmO4Y8xH2sghBxb6HzXzRgsKbRgXsILxeSRbdoa3r0s5Hh1XkzWvdr8YaxbDx wrlkiuAZF2pl2qu6cXmaDbRH8q0XpPCAEhhy9hArvZKlXk8AZpulEv1hDYpifQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=andrew-cmu-edu.20150623.gappssmtp.com header.s=20150623 header.b=FcyDxGwu; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=andrew.cmu.edu (policy=none); spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Spam-Score: -1.51 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=andrew-cmu-edu.20150623.gappssmtp.com header.s=20150623 header.b=FcyDxGwu; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=andrew.cmu.edu (policy=none); spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: AB0F9A803 X-Spam-Score: -1.51 X-Migadu-Scanner: scn1.migadu.com X-TUID: qxjE2RdxFlhN --00000000000076df7e05c949d2b1 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 11, 2021 at 10:32 AM Bruce D'Arcus wrote: > On Wed, Aug 11, 2021 at 9:53 AM John Kitchin > 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 > --00000000000076df7e05c949d2b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Aug 11, 2021 at 10:32 AM Br= uce D'Arcus <bdarcus@gmail.com<= /a>> wrote:
O= n 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:=C2=A0 =C2=A0fig:SED-HR4049
> >
> > [[./img/a.jpg]]
> >
> > Or some other metadata on the target?
>
> I don't think metadata on the target helps with the cases describe= d
> 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 def= ined by the export function. The syntax for these is the same (I guess a fu= zzy link must be wrapped in [[ ]], but an external link may also be wrapped= that way). I don't see a=C2=A0 way to differentiate these.=C2=A0
=

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 u= ses external links, defined by org-set-link-parameters.
=C2=A0

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 cod= e, and if you want cross-references too you just use my processors, or writ= e one that does what you want.
=C2=A0

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 necessaril= y, 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.
=C2=A0

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 d= on't have to. Your processors should fail gracefully in any case, becau= se you just cannot control what people will do with the styles.
= =C2=A0

And activate processors would need to be updated to distinguish them someho= w.

Right now this just looks like=C2=A0=

(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 difficul= t to support and troubleshoot a scenario where the same syntax shows differ= ent behavior depending on whether an external link is defined or not. Final= ly, it is so close to what org-ref already does, I think it is too tricky t= o differentiate [[ref:label]] from [[ref/:label]], etc.

Maybe these links would look different enough (as external links) tha= t it would be really clear you were not using org-ref.=C2=A0

=
ref/:@label
ref/eq:@label
ref/page:@label
ref/name:@label
ref/c:@label
ref/C:@label
=

=C2=A0However, this doesn't support using prefix/su= ffix text, which is one of the main reasons the cite syntax came to be.


Bruce
--00000000000076df7e05c949d2b1--