From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id ODMYDtG6+GMVEgEAbAwnHQ (envelope-from ) for ; Fri, 24 Feb 2023 14:25:37 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id gAMkDdG6+GOFRgEAG6o9tA (envelope-from ) for ; Fri, 24 Feb 2023 14:25:37 +0100 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 A3028FAFE for ; Fri, 24 Feb 2023 14:25:35 +0100 (CET) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=andrew.cmu.edu header.s=google-2021 header.b=i7dr39Hf; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=andrew.cmu.edu ARC-Seal: i=1; s=key1; d=yhetil.org; t=1677245137; a=rsa-sha256; cv=none; b=gFBSTcOSVfTJfraF/DAHPdo8RqOkA/vc/49zsdnVuM2y41rixkMsFKtADLjkCBuJlXXOeN OofOiZck2vRW/sZfQiLTc1UE/5EGH/bucS6sviqjAhEt7cWSKgcDhbS4UYF3gb4XlCq9pB MZG8R7UGgXMhZ8trIOCajIkmO0VwjlJaCyyBk/XkShzLHa/rJV0aXoty2snNBnijL8nllf xapnyCjSfG40uMTU0A6gxD4fkFGc3dcCzxf/3NGZgdRSsGTouZVyKDl/KX4apBQB8VqjTI PauQ6dGl15zE9dG2FAiUHsODeFUJbMdaSKDDlF1gn63zUfKbPbKJHjKWL8BXbA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=andrew.cmu.edu header.s=google-2021 header.b=i7dr39Hf; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=andrew.cmu.edu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1677245137; 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=Q8pIrb+cy8aAfYTzsfmlT+e12sVjQLVaaE8wPqxAhEA=; b=qICX+DWHjAHhMM8pbYMknUfk66aQtzkR+BCyuo5A+22W4/6eD0qS+YphOZmXBarJqL0ea9 Gh4a526b11nff49ojzHDWvf4z898Kna9S8YyCDATFot+bhHgIa6KlSDe/c3Pb4KkWJ70kN PFlHdBx2KS3uAz1KNyn3Q3qNQwo8KvYJY1i89Ailh8Swvab/Smtbg0MeFK71yQEX0ba++/ AWkBNwZiHE9D5FJKvA3veof6/njUKS2oCncB1ZNHsY7zEyGchQuwdPOJxec25dNOM80kNN qvV6c5sPxISyBLKdeN5geoLiadhy2gIpt2rrlUvn1M2YufEY53ziMFk295K0Sg== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pVY3z-00038J-HI; Fri, 24 Feb 2023 08:24:39 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVY3y-000382-9s for emacs-orgmode@gnu.org; Fri, 24 Feb 2023 08:24:38 -0500 Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pVY3w-0003qj-8W for emacs-orgmode@gnu.org; Fri, 24 Feb 2023 08:24:38 -0500 Received: by mail-wr1-x42d.google.com with SMTP id bw19so3270174wrb.13 for ; Fri, 24 Feb 2023 05:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andrew.cmu.edu; s=google-2021; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Q8pIrb+cy8aAfYTzsfmlT+e12sVjQLVaaE8wPqxAhEA=; b=i7dr39HfysLZXNUv37tRivENiEpSyrxIWeYI2RUj0+5kXnE3cEqbuZ0hd1k67Ypc2t r3ykxQma635HMpOqFPE12ezXEju+26WEQbmh68mRRnRYeMA3sECGOqOHx2IgkFQEJq70 y6uHWqlqdFsZzlCSv6zNQNfvja4w8IXyFI5q5ELl8LxY9lmTcBGdiObNTWNlIgSTGWTR 4LqrgJCMAQy5s4wuDQG8P1J5+vUu/lDaYgZ+F0CMtcIZ+dsZX3YM90EQTRPEnDVHoYw4 omfqFhNfQ2MW7aS7mCtnmHF+UGCkRfFJmwZ1B63D+CohKBrA6gfSB7V952oPE2jnhy0h oiNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Q8pIrb+cy8aAfYTzsfmlT+e12sVjQLVaaE8wPqxAhEA=; b=bbFOJs+tsgit8nqvZltWgeGMrBMxa+U98dNnG5uug3T3kNDgxQxBiHQQlZDIH20eBG BHkCoUjvCvBkUcd7wmreyxJgA42UhpL0WgyZqRwaylt+yJx71GKVU5OJmgzxSauhUqUC hwltBF0QNU2s1Gef10OOA8MDufcZSm8uSespzKVOJZ7tQUxd5uUWC9iZlKDV4AMfEyDd 3CD0AIAWkUIuNUbSnoK44rUUmMkceHW6Kw47YJEcy2SUCfHlR9ATTrBR6cqUSNFFP/2e QF2V8YOsUh4DWkuhg9mddeVBeJC7/7XseiSipnrhDchoujRbBVLJzLVLlUeWiCPhcwvl nLQA== X-Gm-Message-State: AO0yUKUTifhcTEQ92m6k1KGAbGiC7AufFkHaQzUFub+IGvnsYL+JBX23 X0Mst74HcGqD4JFFdDmPXpeXBQVki+BnGCx/+1NnU1i8w4Gqhg== X-Google-Smtp-Source: AK7set9+kBNZ18R4Wzm3M64KaU6BLAd4n5tkF1QsvxCHHQKdjWJvFJgaY+DJcVh0pwjdgg2dZz4WGhTLRFKL9s+Dc2c= X-Received: by 2002:adf:e54a:0:b0:2c3:df41:6e5b with SMTP id z10-20020adfe54a000000b002c3df416e5bmr1233133wrm.7.1677245069643; Fri, 24 Feb 2023 05:24:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: John Kitchin Date: Fri, 24 Feb 2023 08:24:18 -0500 Message-ID: Subject: Re: Links to external targets with (or despite) org-ref To: Sven Bretfeld Cc: Emacs Orgmode Content-Type: multipart/alternative; boundary="00000000000093e34a05f5720cfc" Received-SPF: pass client-ip=2a00:1450:4864:20::42d; envelope-from=jkitchin@andrew.cmu.edu; helo=mail-wr1-x42d.google.com X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: X-Migadu-Queue-Id: A3028FAFE X-Spam-Score: -9.24 X-Migadu-Spam-Score: -9.24 X-Migadu-Scanner: scn0.migadu.com List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-TUID: vXQ1diTNSNIB --00000000000093e34a05f5720cfc Content-Type: text/plain; charset="UTF-8" You are welcome. I also discovered just now that you can do C-u C-u C-c C-l to skip storing functions that are not part of org-core. If anyone knows how to use store functions that do not clobber the build in ones, I would be happy to update org-ref so you can use all the link store options. On Wed, Feb 22, 2023 at 5:20 AM Sven Bretfeld wrote: > Hi John > > That's working well. Thank you very much. And thousand thanks for > org-ref in general. > > Sven > > Am Mon, Feb 20, 2023 at 01:07:49PM -0500 schrieb John Kitchin: > > The quickest thing might be to remove the store properties on the ref > links. > > This should do it. > > > > #+BEGIN_SRC emacs-lisp > > (cl-loop for reflink in '("ref" "pageref" "nameref" "eqref" "autoref" > "cref" > > "Cref" "crefrange" "Crefrange") > > do > > (setf (cdr (assoc reflink org-link-parameters)) > > (org-plist-delete (cdr (assoc reflink org-link-parameters)) > :store))) > > #+END_SRC > > > > I guess I don't have that setup quite right in org-ref, it seems like it > should > > not clobber other ways to store links. > > > > On Sun, Feb 19, 2023 at 10:39 AM Sven Bretfeld <[1]sven.bretfeld@ntnu.no > > > > wrote: > > > > Hi everybody > > > > I'm looking to create labels/links to specific text positions in org > > files (not line number, not header). > > > > I know that [[file:~/path_to_file::target]] can be used to jump to > > <>. That would be fine and works for me -- IF I write the > link > > manually. > > > > However, org-ref which I use for citations seems to overwrite the > > default behaviour of org-store-link and org-insert-link. So when the > > point is on <> and org-store-link is called (C-c l), I get a > > prompt "Store link with (default org-ref-store-ref)". No alternatives > > are offered when TAB is hit. Hiting RET saves the link as > > "Crefrange:target". A corresponding org-insert-link (C-c C-l) > produces > > a link of the form [[Crefrange:target]] which, when in another file, > > of course leads nowhere ("search failed"). How to get the file name > > into these links without manually rewriting the link? > > > > I couldn't find anything on this issue in the org-ref manual or on > the > > internet. > > > > Thanks for help, > > > > Sven > > > > > > > > References: > > > > [1] mailto:sven.bretfeld@ntnu.no > --00000000000093e34a05f5720cfc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You are welcome.

I also discovered just= now that you can do C-u C-u C-c C-l to skip storing functions that are not= part of org-core.

If anyone knows how to use stor= e functions that do not clobber the build in ones, I would be happy to upda= te org-ref so you can use all the link store options.=C2=A0

=
On Wed, Fe= b 22, 2023 at 5:20 AM Sven Bretfeld <sven.bretfeld@ntnu.no> wrote:
Hi John

That's working well. Thank you very much. And thousand thanks for
org-ref in general.

Sven

Am Mon, Feb 20, 2023 at 01:07:49PM -0500 schrieb John Kitchin:
> The quickest thing might be to remove the store properties on the ref = links.
> This should do it.
>
> #+BEGIN_SRC emacs-lisp
> (cl-loop for reflink in '("ref" "pageref" &quo= t;nameref" "eqref" "autoref" "cref"
> "Cref" "crefrange" "Crefrange")
> do
> (setf (cdr (assoc reflink org-link-parameters))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(org-plist-delete (cdr (assoc reflink org-li= nk-parameters)) :store)))
> #+END_SRC
>
> I guess I don't have that setup quite right in org-ref, it seems l= ike it should
> not clobber other ways to store links.
>
> On Sun, Feb 19, 2023 at 10:39 AM Sven Bretfeld <[1]sven.bretfeld@ntnu.no> > wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi everybody
>
>=C2=A0 =C2=A0 =C2=A0I'm looking to create labels/links to specific = text positions in org
>=C2=A0 =C2=A0 =C2=A0files (not line number, not header).
>
>=C2=A0 =C2=A0 =C2=A0I know that [[file:~/path_to_file::target]] can be = used to jump to
>=C2=A0 =C2=A0 =C2=A0<<target>>. That would be fine and work= s for me -- IF I write the link
>=C2=A0 =C2=A0 =C2=A0manually.
>
>=C2=A0 =C2=A0 =C2=A0However, org-ref which I use for citations seems to= overwrite the
>=C2=A0 =C2=A0 =C2=A0default behaviour of org-store-link and org-insert-= link. So when the
>=C2=A0 =C2=A0 =C2=A0point is on <<target>> and org-store-li= nk is called (C-c l), I get a
>=C2=A0 =C2=A0 =C2=A0prompt "Store link with (default org-ref-store= -ref)". No alternatives
>=C2=A0 =C2=A0 =C2=A0are offered when TAB is hit. Hiting RET saves the l= ink as
>=C2=A0 =C2=A0 =C2=A0"Crefrange:target". A corresponding org-i= nsert-link (C-c C-l) produces
>=C2=A0 =C2=A0 =C2=A0a link of the form [[Crefrange:target]] which, when= in another file,
>=C2=A0 =C2=A0 =C2=A0of course leads nowhere ("search failed")= . How to get the file name
>=C2=A0 =C2=A0 =C2=A0into these links without manually rewriting the lin= k?
>
>=C2=A0 =C2=A0 =C2=A0I couldn't find anything on this issue in the o= rg-ref manual or on the
>=C2=A0 =C2=A0 =C2=A0internet.
>
>=C2=A0 =C2=A0 =C2=A0Thanks for help,
>
>=C2=A0 =C2=A0 =C2=A0Sven
>
>
>
> References:
>
> [1] mailto:= sven.bretfeld@ntnu.no
--00000000000093e34a05f5720cfc--