From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id UVd/GawIj2CEAAAAgWs5BA (envelope-from ) for ; Sun, 02 May 2021 22:16:44 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 6L1jFKwIj2B+QQAAbx9fmQ (envelope-from ) for ; Sun, 02 May 2021 20:16:44 +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 98B72A726 for ; Sun, 2 May 2021 22:16:43 +0200 (CEST) Received: from localhost ([::1]:45656 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ldIWA-0007k0-Du for larch@yhetil.org; Sun, 02 May 2021 16:16:42 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40592) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ldIVi-0007i9-E3 for emacs-orgmode@gnu.org; Sun, 02 May 2021 16:16:14 -0400 Received: from mail-pl1-x631.google.com ([2607:f8b0:4864:20::631]:41570) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ldIVg-0006or-G7 for emacs-orgmode@gnu.org; Sun, 02 May 2021 16:16:14 -0400 Received: by mail-pl1-x631.google.com with SMTP id e2so1733075plh.8 for ; Sun, 02 May 2021 13:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:in-reply-to:message-id :date:mime-version:content-transfer-encoding; bh=QjTdSznLyowkSohdbnNR7yRTVL0R5aI2i/Gc82BhJMw=; b=JlGba9BS3VqpmHk36GLP2RjFBURh1qGHBQtxbDqZIyVEXWT9zgeVRju6xkpwcUxS6G J8t2d2yyQm/Glg76rtYKwnguwrDY4beEs0/Nj4OuLUkQbFFNwU8cIEDTWA4+oIemtlrc EQqET4I/cqTjL6oQy7SAlemu7F3f5MEeTESMHtI9U12FTVT17qxB6rsj7jfA20E+OQRO +yYnfFwvol5goCChvHifEgKpGTcry813I+mvURRrdkaTC5v2LKoZDOBZYLqe7K0N1Sdi L5NzdoJSm1F8qP1yAmcrzq04s3WWDQdkCnKSRtxIZQuT4jgAjbFVMm3sXMUErLGq5tUY UMUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:message-id:date:mime-version:content-transfer-encoding; bh=QjTdSznLyowkSohdbnNR7yRTVL0R5aI2i/Gc82BhJMw=; b=T7fSR6Fth60W+D46ILQb45ssAbjfhlVTtg/BgnDWxTkfDSAeiyoS4skDosqVJSx/sJ LG2NqSl5WfmkvtAsaHlr5LvIU00aDFsdfNgVbV+aZt3qExUffzO1ygas8McHkYRfe2fb MuaWKUa2im00g+ylPSko4wGbqdG8qbAS+3U8ihiul2cQ6si/PhmCfIl+9+v9bVY+3y1T mXJyFolBvBbvuF3UD2bWOrSq8qIV5Ow9fFmQ/pfFYpCe6Sww+Zu34z/S7d+18TL48hFi oIWyX5WMAKWI/zgaXoe5MelTwqTEYokYDUfOBycfUjmGKtdZXvnkXgg+5eFr06PSzKiV fN7g== X-Gm-Message-State: AOAM533hVp4dGY0bz7eE3m/47HrT8PUalPFea3UIKL/9jXHvbwwENrWw 39Fn1YnbHc4A21deWOuRLS8= X-Google-Smtp-Source: ABdhPJw6LL5EUO33N/RDfQWZQ7O6vcvj4hBF3SoJm7F2DFUljPim4VKD/tx3IE1naJhe7DSWUTvrZQ== X-Received: by 2002:a17:90b:909:: with SMTP id bo9mr7631570pjb.142.1619986570673; Sun, 02 May 2021 13:16:10 -0700 (PDT) Received: from localhost (180-150-91-8.b4965b.per.nbn.aussiebb.net. [180.150.91.8]) by smtp.gmail.com with ESMTPSA id x9sm7212609pfd.66.2021.05.02.13.16.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 May 2021 13:16:09 -0700 (PDT) References: <87wnsx9rcj.fsf@nicolasgoaziou.fr> <87y2dc82ct.fsf@nicolasgoaziou.fr> <87sg3j4vbl.fsf@gmail.com> <33fd87ff1332b56114909973804df669@isnotmyreal.name> <87h7joibxc.fsf@gmail.com> <87pmycay41.fsf@gmail.com> <87h7jouiuk.fsf@nicolasgoaziou.fr> <875z03igpf.fsf@gmail.com> <87tunmskap.fsf@nicolasgoaziou.fr> <87fsz6boxa.fsf@gmail.com> <87fsz6sik0.fsf@nicolasgoaziou.fr> <87czuabm6w.fsf@gmail.com> <871raqsfzp.fsf@nicolasgoaziou.fr> <87a6pebkk8.fsf@gmail.com> <875z019w0r.fsf@nicolasgoaziou.fr> User-agent: mu4e 1.4.15; emacs 28.0.50 From: Timothy To: Nicolas Goaziou Subject: Re: stability of toc links In-reply-to: <875z019w0r.fsf@nicolasgoaziou.fr> Message-ID: <8735v4hoxl.fsf@gmail.com> Date: Mon, 03 May 2021 04:16:06 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::631; envelope-from=tecosaur@gmail.com; helo=mail-pl1-x631.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, 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.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tim Cross , emacs-orgmode@gnu.org, Samuel Loury 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=1619986603; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=QjTdSznLyowkSohdbnNR7yRTVL0R5aI2i/Gc82BhJMw=; b=bora7OycmsyzlWtY0QEKDTipkhuEuyRFi3q1mHIW3QOubYeKxkTpeXbsX4q82J2XMP1AN/ kVy0cBoHu1Ck530KEV0QQLVuwL2FBwi1O4d/u7OR8pNfnclZZKNmxIqAqqvxRTZmFyULGR nJHmvQ69/mRGJOwJRwBJ13Tbw3dbdthWQK/sQ1BWJ0hCPnlLgeqM1eb06kyb08zvi/yhyA brSVaXOawj7B1Q1Erd9WBFX7F4agdM4HfGQ4W281P9Dkzrd8mAWn6v3Zg68v0ZIyaazkjO NcrmglkBbBXyIKqSefTBDIDSA4FeQpf9gZ2nQIytV8CACzmcx7sZw6XbEIN/ZA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1619986603; a=rsa-sha256; cv=none; b=aB++gDU3TrDFzVUBR0/SkwIqnSG59k6cR9DSHGJukCUC4kENRqiUo/B2snL1eq0yqFzsW2 a6TxVbk8kPg9NE9vv2FzrD61Y4u6YblK57WkV5X0IKLFhb8J7AcxV3bzrg2hofYsI09+4p XAUfDuW2e3k2qCyGbUIBTnptTpNA/X2oOmMkCy5h66/rcK7SZTnKIMYHNLD3gksJrIoNN4 rE1kFuo+Zi5DFZgQYxAJ0Ojz6qahgQIOxpjTiXI7Dj0ZuozhZXMVPnjt0EGzSM5LXLc4AB OH6CK0GJ+6IV80ZpNXhAZcsuMkHkq753834PfOL6UUDTyNL9N6yFFn9DszUGvQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=JlGba9BS; 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: -3.16 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=JlGba9BS; dmarc=pass (policy=none) header.from=gmail.com; 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: 98B72A726 X-Spam-Score: -3.16 X-Migadu-Scanner: scn0.migadu.com X-TUID: Dh7qBdpg4/pI Nicolas Goaziou writes: > Please note that those short answers did not help me much. So I did my > homework and looked at your code. I didn't test it thoroughly, so I may > be missing something. It's a pity to hear that I wasn't able to suitably clarify things in my reply. Thank you for being willing to investigate my implementation. > Now, here's the elephant in the room: "puny.el" was included in Emacs > 26.1. Org cannot make use of it yet. Gah. > Also, the bootstring algorithm, and yours, are very much > English-centered, as can attest > `org-reference-contraction-stripped-words'. I insisted on non-latin > languages for a reason: > > (org-reference-contraction "=E3=81=93=E3=82=93=E3=81=AB=E3=81=A1= =E3=81=AF") =3D> "28j2a3ar1p-" > > or, for a not so long title > > (org-reference-contraction "=E3=81=93=E3=82=93=E3=81=AB=E3=81=A1=E3=81= =AF =EF=BD=BA=EF=BE=9D=EF=BE=86=EF=BE=81=EF=BE=8A") =3D> "v8ttbvbva7si998jv= ba0bzb0m-" > > which is arguably worse than "org1234567". Mmmm. This isn't great. I preferred the output of Unidecode (ASCII transliteration) mentioned previously, but that doesn't look like it could easily be used. >>> references are guaranteed to be unique in the document; >> >> The suffixed number I mentioned ensures this. > > Unfortunately, because of them, you cannot guarantee stable links during > export, much like random references. > > For example, if you first export > > * Foo > bar > > and if you later modify your document like this > > * Foo > baz > * Foo > bar > > your link will now point to the "baz" contents instead of "bar". > > As a side note, this the reason why I introduced randomness in > references in the first place. We cannot reference first headline as > "headline-1", second one as "headline-2", i.e., in a monotonic way, > because we cannot assume their order is fixed. >From this I take it you'd rather a broken reference than an incorrect one? I don't think there's any "good" solution here, just pick your poison (and, no surprise, I prefer my way). > More importantly, the above is not limited to headlines with the exact > same title. Since your algorithm truncates output, this will happen in > various, less obvious, situations. While this is technically possible, I think it's worth noting that I have never seen this in practice, and for reference I have documents with hundreds of headings (250 in my config, for example). >>> Also, header content is not stable enough: when you're linking to the >>> custom ID, you may be able to change the title and yet preserve the >>> link. >> >> Custom IDs still work, so I don't quite see the point here. > > How can you be sure? > > The point is that in some export back-ends, e.g., ASCII, you will only > provide a single reference for a headline, i.e., not one for the title > and another one for the custom ID. If your reference is based solely on > the title, the reference will break whenever you modify the title > without touching custom ID. I gave an example in an earlier post > already. This is a regression wrt the current system. I remain rather confused on this point. Say I have a document with the following content: * Some heading :PROPERTIES: :CUSTOM_ID: hey :END: See [[#hey]] or [[Some heading]] In an HTML export I see:
  • 1. Some heading
    • [...] See 1 or 1

    In an ASCII export: 1 Some heading =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 See 1 or 1 In a LaTeX export: \section{Some heading} \label{hey} See \ref{hey} or \ref{hey} etc. I don't see how my code affects custom IDs. > In a nutshell: > > - there are very interesting points in your proposal; Glad you've found some things of interest. > - it is not applicable at the moment; I'm guessing this is solely due to punycode? > - it greatly improves references for English language, it is slightly > better for latin languages, and worse for non-latin ones; > > - it does not guarantee link stability during export; Indeed. However no approach that doesn't cache every heading with every export does, and I find this /significantly/ improves stability. > - it introduces a regression wrt custom ID. See my confusion above. > Link stability is still an issue, even if the proposal gives a false > sense of security in that area. I don't think we can solve it without > creating a cache for export, where you store all previous references for > a given file. Even this is not sufficient, because you can export > buffers not attached to files. To me this is a case of "don't let the perfect be the enemy of the good", though I do see that a false sense of security may be problematic, I consider the benefits to outweigh this. I hope you've found this reply more useful than my last, Timothy.