From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id OKj0L2niqWTQOgAASxT56A (envelope-from ) for ; Sun, 09 Jul 2023 00:25:45 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id ULLIL2niqWTVAAAAauVa8A (envelope-from ) for ; Sun, 09 Jul 2023 00:25:45 +0200 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 0D7096655F for ; Sun, 9 Jul 2023 00:25:44 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=IKnEgAVL; 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=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1688855145; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=Mc7s9ssQcakl/6bKIRaXUw36SDRIjP5HywLJO2WIK6o=; b=sCEQ23lAlnfaFYQQvJPQ9Nnu53HJbId+4jq8AwTLLNj8F8MlED2bxpVSxA+JlOvUxKFW2v hXNKpmPLDJde/7G0sVKEq5BAOht/bTySBoq6r1dJKkF/DBJWCe5QqL8vvTk1Fdr3vQi6EA Z9kzsaAmwrr1+xxR/w/5pFwlMnUYXsgC9F/YUZ9V2Ya4/lBOK/E8jyDSUy6p/g2Renifjj OLiyKZDu/zmwRz8T1olB+p77AmPMk441ULVu71oNgn0wAXdvclF01xZZl1aExRd4DXxXMB HA6IjY/oTcsNG65g3LMrJedf/Vu98yTyYLok08bWcYQs9GJANbL4eArZE257qQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=IKnEgAVL; 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=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1688855145; a=rsa-sha256; cv=none; b=D7rKFxGkLjc/uiyajUgNJ8aJrtobLqUlL6catWP74c8m+D17IkBkjvEYuUiwQwCjw1wM7N IrwQZE8VzqOeFU0A157bKVpva8DHe55wYUEST0y7Y/Us/aHIjHk80NcBTdyBNR4DxLMx1v HBeCQRuB0UMenQmK6TCFs9gdZuStUddl+fDrSXm3g9aWD93WqV0cJfcdiSJqLVpFb/kRfJ /iWI+AYz83Qj0rSvuQA8JgMR9mCGl1jhyi1sdOqN8O+LYFAQQcdtR90/xHxrS9+tjeR310 k3+frPtc2YoZFJfW1fp9V+8QBhPC83ZhCsGCeq9uqhFzTL5zsE04BIGcigIAIA== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qIGMG-0000do-Ee; Sat, 08 Jul 2023 18:24:52 -0400 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 1qIGMF-0000dR-2o for emacs-orgmode@gnu.org; Sat, 08 Jul 2023 18:24:51 -0400 Received: from mail-oa1-x34.google.com ([2001:4860:4864:20::34]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qIGMD-0001ab-42 for emacs-orgmode@gnu.org; Sat, 08 Jul 2023 18:24:50 -0400 Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-1b45fe36cd9so920881fac.2 for ; Sat, 08 Jul 2023 15:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688855087; x=1691447087; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=Mc7s9ssQcakl/6bKIRaXUw36SDRIjP5HywLJO2WIK6o=; b=IKnEgAVLQSGTMQuKZpTGdKU16alPg/NkXuoTYxRnCcMLof6fgkHGTTz22b/so5KiA7 mWjdoZt6Z2zpB5SNwJ686jLojT6h57+q93HswzVDorDwyEmIRFo67z6OMPrI5X+67aEG Zhekoi3TEhE170l1J9Ww+4PJxzTw/jwomJj9JJerPbQFhcvrhRmNk48L4DNxI9NLY2Fi /FQG3nRBGmOBFZHnUk/K+jJrWDd69LgGeL00chLTSGb4Cohwdz0IjudWTDrdXx5kr7mC L13Jrv65Yjna0iNK1aOk6cCO4hLZXLDT3Q3FF/HFpdeK9kQpIbDrbPmAkpuMGH4zLNYX oVBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688855087; x=1691447087; h=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=Mc7s9ssQcakl/6bKIRaXUw36SDRIjP5HywLJO2WIK6o=; b=TeuHTaXUms/Zg5mMbCcfKrIrwGchJ+y3hAM/eTmfqdq1kmgzmRcvCjK2urXsxi0hPn kyHBqrLbgbIEuC32u2xQnsegFqP+iRgU4kgl2MBqi4l+C+UYqZ8shplvpIB/oEh61ulr atoeka/qV8a+eoKZugsOqdTR8s0UdYOvCGksZzXUkA7atOPsveV4svSHJioLcpdomb4R Goi7svPgjMBNrA3pZEzgMYN50pRoIg0rUqcokxkb6JmnOIJtuEy29eiJGFnhIZGHjjct JpohgmHqbi8S7YxAB7DZZz5l0Gva+V82FucNEHjx/VHIiqvyukAoBlocWVxVtbpkoFCx WBpw== X-Gm-Message-State: ABy/qLY+Jr4cecMX9ng3EvzkyiWJQGhDuAUjJtkfeiaV7jrIVYdGxlKY GcfEMrPfrdDPAlUN9W3jV0bJUr+3VYKwQNhaEAg5D4CY X-Google-Smtp-Source: APBJJlHrzuGtzZWdaAGoPku3FrBenRhcEGkNLBRLu3YAXLJJoxEYi+My6Q4nmIVrpcn7X0CJMbI5DeELnVmJ4YTN268= X-Received: by 2002:a54:4817:0:b0:39b:8121:4e32 with SMTP id j23-20020a544817000000b0039b81214e32mr7024188oij.4.1688855087028; Sat, 08 Jul 2023 15:24:47 -0700 (PDT) MIME-Version: 1.0 References: <877crcxdb0.fsf@localhost> In-Reply-To: <877crcxdb0.fsf@localhost> From: Dan Drake Date: Sat, 8 Jul 2023 17:24:35 -0500 Message-ID: Subject: Re: inconsistency links and code line labels To: emacs-orgmode@gnu.org Content-Type: multipart/alternative; boundary="0000000000008a1d060600013787" Received-SPF: pass client-ip=2001:4860:4864:20::34; envelope-from=dan.drake@gmail.com; helo=mail-oa1-x34.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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: 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-Country: US X-Migadu-Flow: FLOW_IN X-Spam-Score: -9.45 X-Migadu-Queue-Id: 0D7096655F X-Migadu-Spam-Score: -9.45 X-Migadu-Scanner: mx0.migadu.com X-TUID: 7f6FiMaF+jed --0000000000008a1d060600013787 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I should have mentioned that I'm not exporting any of this. I only use org by itself; I never export things to other formats. So the link behavior that I need is for making and following links inside org/emacs; noweb and other things aren't important. The (ahem) link to the org-coderef-label-format is what I was looking for: I set that to just (%s) and now something like the above example works without adding the "ref:" bit. I'll update the emacs.sx post. Thanks! On Fri, Jul 7, 2023 at 4:48=E2=80=AFAM Ihor Radchenko = wrote: > Dan Drake writes: > > > Hello -- I'm wondering about my question from here: > > > > > https://emacs.stackexchange.com/questions/77768/why-the-inconsistency-wit= h-org-mode-code-line-labels-and-links > > > > Copying my question: in a source code special block, I can add code lin= e > > labels, which have ref: in the label -- but when I make a link there, I > > have to omit the ref:. For example: > > ... > > 1047 bar =3D 5; // (ref:my-code-line-label) > > ... > > There's a bug [[(my-code-line-label)][right here]]. > > > > This seems inconsistent. Why do I have to omit the ref: bit? This alway= s > > confuses me; it seems like it would be simpler to just make the label a= nd > > the links to that line of code be exactly the same. I don't see any > > particular reference to this in the org manual ( > > https://orgmode.org/manual/Internal-Links.html). Any insights? > > The way coderefs appear in the code are completely configurable using > org-coderef-label-format ("(ref:%s)" by default) and using -l src code > switch. > > > My idea would be to get rid of the special behavior for code line label= s > > and just make this work with dedicated targets: in regular parts of my > org > > file, I use <> and can make links to that. It would be > simple > > and consistent to make that also work the same when <> is > > inside a code block. > > If you examine 12.6 Literal Examples section of Org manual, you will see > that coderef links are exported specially: > > In literal examples, Org interprets strings like =E2=80=98(ref:nam= e)=E2=80=99 as > labels, and use them as targets for special hyperlinks like > =E2=80=98[[(name)]]=E2=80=99=E2=80=94i.e., the reference name enclose= d in single parenthesis. > In HTML, hovering the mouse over such a link remote-highlights the > corresponding code line, which is kind of cool. > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > --=20 Ceci n'est pas une .signature. --0000000000008a1d060600013787 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I should have mentioned that I'm not exporting an= y of this. I only use org by itself; I never export things to other formats= . So the link behavior that I need is for making and following links inside= org/emacs; noweb and other things aren't important.

The (ahem) link to the org-coderef-label-format is what I was lookin= g for: I set that to just (%s) and now something like the above example wor= ks without adding the "ref:" bit. I'll update the emacs.sx post.

Thanks!
<= div>


On Fri, Jul 7, 2023 at 4:48=E2=80=AFAM Ihor R= adchenko <yantar92@posteo.net= > wrote:
Dan = Drake <dan.drak= e@gmail.com> writes:

> Hello -- I'm wondering about my question from here:
>
> https://emacs.stackexchange.com/questions/77768/why-the-inco= nsistency-with-org-mode-code-line-labels-and-links
>
> Copying my question: in a source code special block, I can add code li= ne
> labels, which have ref: in the label -- but when I make a link there, = I
> have to omit the ref:. For example:
> ...
> 1047=C2=A0 =C2=A0 =C2=A0bar =3D 5; //=C2=A0 (ref:my-code-line-label) > ...
> There's a bug [[(my-code-line-label)][right here]].
>
> This seems inconsistent. Why do I have to omit the ref: bit? This alwa= ys
> confuses me; it seems like it would be simpler to just make the label = and
> the links to that line of code be exactly the same. I don't see an= y
> particular reference to this in the org manual (
> https://orgmode.org/manual/Internal-Links.html). Any insights?

The way coderefs appear in the code are completely configurable using
org-coderef-label-format ("(ref:%s)" by default) and using -l src= code
switch.

> My idea would be to get rid of the special behavior for code line labe= ls
> and just make this work with dedicated targets: in regular parts of my= org
> file, I use <<link-target>> and can make links to that. It= would be simple
> and consistent to make that also work the same when <<link-targe= t>> is
> inside a code block.

If you examine 12.6 Literal Examples section of Org manual, you will see that coderef links are exported specially:

=C2=A0 =C2=A0 =C2=A0 =C2=A0In literal examples, Org interprets strings like= =E2=80=98(ref:name)=E2=80=99 as
=C2=A0 =C2=A0 labels, and use them as targets for special hyperlinks like =C2=A0 =C2=A0 =E2=80=98[[(name)]]=E2=80=99=E2=80=94i.e., the reference name= enclosed in single parenthesis.
=C2=A0 =C2=A0 In HTML, hovering the mouse over such a link remote-highlight= s the
=C2=A0 =C2=A0 corresponding code line, which is kind of cool.

--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,=
or support my work at <https://liberapay.com/yantar92>


--
Ceci n'es= t pas une .signature.
--0000000000008a1d060600013787--