From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id QNHUMp7QR2H2xgAAgWs5BA (envelope-from ) for ; Mon, 20 Sep 2021 02:06:54 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id qDuTLp7QR2HicAAA1q6Kng (envelope-from ) for ; Mon, 20 Sep 2021 00:06:54 +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 D8C961C149 for ; Mon, 20 Sep 2021 02:06:50 +0200 (CEST) Received: from localhost ([::1]:43906 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mS6pd-0006Sm-0C for larch@yhetil.org; Sun, 19 Sep 2021 20:06:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45430) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mS6ou-0006Se-7e for emacs-orgmode@gnu.org; Sun, 19 Sep 2021 20:06:04 -0400 Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]:36461) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mS6os-0002Sp-86 for emacs-orgmode@gnu.org; Sun, 19 Sep 2021 20:06:03 -0400 Received: by mail-wm1-x32f.google.com with SMTP id l18-20020a05600c4f1200b002f8cf606262so14250792wmq.1 for ; Sun, 19 Sep 2021 17:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=kSakQ7LlLMNoE+Gq9+scvXgmORmz7VhFb5y+ayIsJlM=; b=j/Ai07EESayLoVYKfZzdIgKoClszs2GDOq+9LGfM9Hy8PYXCOpPiVa0eusPbfHTqwY AlEI2tc/PCb5IZBwkUKipu8WdavZfRdNgFN91k3uxou1f2zKvLCNGCYS49ITGAg2kDw3 yJLG3ZWE6UCJCsfA0miXHIGA7Zj4+PtwbnNCH7rSoAsOELMmn9gCJaS0Vfjo3RQZKJCT mryZTKnJ4ay68V1ZrEXRjukCKoYe6buHgleJy0rmQeQWOfBp+LLSRR1kmue5dzJF9W1u v5ZgkvEFZTtZtnG3rVCtT/Sr6PZMZnqFGe18z5OfZvSIL2wDf7qEjrqn6gG6cXgzA2fh FMFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=kSakQ7LlLMNoE+Gq9+scvXgmORmz7VhFb5y+ayIsJlM=; b=s26wJe4KIYPbvKSvpMQdwBqHd5sZfn+/wrtMuXfHYIYzAoDzxT8gHRTFfblFwqNcBA qr2DDO82xtv6l9WkPgfcnMAokj6pU8hK9YP9owdnVKjppGG2fzASiHBvnw04l28F7QR8 pDcSBFjc3oZTAa9l1Tl8rudb5RqEazhHQGmtJ6v+Nz3kAWgngrdNPS8UyvO9jqNP8dfz Nz1/2++Ht1272fp1m5mSUChuy+u6IQz/r7X6JdrAJ9CDlm0GfCsL9blcMHv8+UiKnlG2 LHlwLQBkDAlqCqzdgVHLIxBXRnOc6wCZViOVgq1RPAL5sQEwTzKFyTmb+jx14rR77/Yi xFjA== X-Gm-Message-State: AOAM5320dK/Y7o48QTvs7r6RayL+a44eyLtrIf62b5uBjP/cSFzxIpvT CWIsyx2vekLXq8rxRqp+dd7vQJPfOT4= X-Google-Smtp-Source: ABdhPJxXLfJG/PHSeJ5AxcvYtL32xSn2HC71bg2+uHewkHYMFPSCUAhAeyAY0n0PxHoigDt8SkEHzA== X-Received: by 2002:a1c:4c13:: with SMTP id z19mr21704145wmf.154.1632096358764; Sun, 19 Sep 2021 17:05:58 -0700 (PDT) Received: from pluto.localnet (aaubervilliers-651-1-245-109.w83-200.abo.wanadoo.fr. [83.200.76.109]) by smtp.gmail.com with ESMTPSA id i187sm6157970wma.0.2021.09.19.17.05.58 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Sep 2021 17:05:58 -0700 (PDT) From: chris To: emacs-orgmode@gnu.org Subject: Re: Internal link broken when publishing (was org-id with ox-html) Date: Mon, 20 Sep 2021 02:05:57 +0200 Message-ID: <51009862.OmzxVWrqTf@pluto> In-Reply-To: References: <4617246.m1MCmUpgFQ@pluto> <4827285.5yCLvEFndJ@pluto> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::32f; envelope-from=inkbottle007@gmail.com; helo=mail-wm1-x32f.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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_ENVFROM_END_DIGIT=0.25, 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: , 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=1632096411; 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: 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=kSakQ7LlLMNoE+Gq9+scvXgmORmz7VhFb5y+ayIsJlM=; b=lRxLiZ1UL2az6I8O7hTL6HbCfk0jDagiAM3mWTyxK9+J5ncsWvB1t7xmJ2o3+0pWNUB6CI UJkjCodZAv+8QP5Hp/Q7+7UOIPnqZFMsFgwyVNDai1BwFC/FpqsKiNkxnJKaI4qbGZjaFe vWg0R0kXQZWvlsCSb8K1BgkbcOln5IP2OBfl9CgCX9C7MQVxNCU2XaJ5HVQJ+D1/B3+tJ7 XBX2+br9QuYqZm54yF2BDgAnZBzvT4Gz/Ew6lePrQILQl+uhMbuuYV7jxc2r4LgnQmPwAe sh0u7S32n04KRuTC3CI2a9RZQhkTij9asSPXIWjahiWN5SPctAqrb3u175fjUA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1632096411; a=rsa-sha256; cv=none; b=gHL5JTXZ0g2WBSTm+iptLd6LA9y7eSxzWSXP3XsVtXqYi0wK9my0Rngc+yDSPdMvMoiNwd Mk0FWq3xaoJqC4NSUfn+MDTvcyXeVU3eFO+8lbyVk7JXmOBBRmalcTzVBcCRo2Zj3YIIKy 2WVB6H/JkJEHGvrVmBN88gmdShh1AyUCR7Gz0BOfKoEzICDRCbfg2EWmpyZPRpekk9iO44 d7Ec45Ocs6eg9wl5JByv6N3yAF6nRPWpsJBo7r+eE+t9+OryVPmJvBv9xBS/Al9+5tgwFd J+q3r5XN+OMPwsgTPDqjn8gfe2quM2IP+WK3SR3768FG6e2rJrXD4lB97nkXVA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="j/Ai07EE"; 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-Spam-Score: -0.59 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="j/Ai07EE"; 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: D8C961C149 X-Spam-Score: -0.59 X-Migadu-Scanner: scn0.migadu.com X-TUID: nIkfFZrk5DaN On Tuesday, 14 September 2021 18:33:43 CEST Max Nikulin wrote: > As a kind of summary: > > During publishing of a project > - "id:" links to headings from the same file are exported as short > generated anchors like #org032777e or as anchors to custom ids when the > latter are available > - "Search heading" links to other files are exported as short generated > anchors or as custom ids. > - "id:" links to headings in external files are exported as ID value > with "ID-" prefix. These links are *broken* currently. Thanks a lot. Perfectly functional org-id links between two files are broken when published to HTML. I suppose a bug should be opened about that? (I can do that in a few weeks.) CUSTOM_ID solution is not good because you have to specify what file the ID is in. With plain ID, you specifically do not have to specify in which file the ID is, and therefore you can freely move around entries with ID, even beyond the file boundary, without troubling yourself. Because there is some sort of database behind, taking care of it for you. For the exporting, considering the "ID-db" must be queried, and a translation process must be applied, I don't think there should be any specifications about the way it is implemented. > Expected behavior is the same style of anchors for particular heading, e.g. > - value of custom_id property is used even for "id:" links > - either value of id property or short generated anchor is used for > links to a heading having id property (maybe it should be possible to > customize preferred style) but the same for search heading text fuzzy > links and "id:" links, internal and external ones. > > I do not mind to have both anchors with value of id and custom_id > properties if they are defined for a header. > > My opinion is that value of id property should be used for heading > anchor when available to guarantee stable links from other sites. I > admit that default behavior may be short (perhaps unstable) anchors. > > On 07/09/2021 22:46, chris wrote: > > On Tuesday, 24 August 2021 17:23:24 CEST Maxim Nikulin wrote: > >> On 23/08/2021 03:42, inkbottle wrote: > >> From my point of view it looks like a bug. > >> > >> https://code.orgmode.org/bzg/org-mode/src/master/lisp/ox.el#L4381 > > ... > > > I believe it's a bug, plain and simple. > > I am afraid that its fix would not be so simple. > > > With a unique org file, the `:ID: e54113f9-2ad7-4a86-94be-68ffc696de0b` > > are > > resolved to `orgfa9c151` consistently. > > My opinion (in contradiction to Nicolas) is that anchors should be as > stable as possible even in the absence of cross-references withing the > document. It allows links from other sites to particular sections. That > is why value of ID property is better than random anchor despite the > former is longer. > > > There is a patch here: > > https://gist.github.com/jethrokuan/d6f80caaec7f49dedffac7c4fe41d132 > > but, as I understand it, the workaround consists in treating `:ID:` > > similarly as `:CUSTOM_ID:`, that is, exporting them "verbatim". > > If it were a patch, it would be easier to spot the changed part. This > approach may be implemented in a bit cleaner way but I do not think that > it will allow to use custom_id value for "id:" link if a heading has > both (see `org-html-link' and `org-export-resolve-id-link'). > > >> checks for ID property. > >> https://code.orgmode.org/bzg/org-mode/src/master/lisp/ox-html.el#L1659 > >> queries CUSTOM_ID only. I suppose, ID should be here as well. A subtle > >> point is which one (ID or CUSTOM_ID) should be used if both are defined > >> for some headers. > > > > Yes, "ID should be here as well" => No. > > That is the point I'm advocating above. > > `:CUSTOM_ID:` are meant to be treated in a so-called "stable" way. That is > > to say, the `CUSTOM_ID` you see in your org-file, is what you get in your > > HTML file (also I've done some tests with that method, and I recall it > > wasn't working at all in a multiple org files setting). > > On the other hand, `:ID:` are meant to be treated through a *translation > > table*, and should result in some `orgfa9c151` thing, on the HTML side. > > Weaving the two methods together doesn't seem like "road to success". > > In a general case it is rather hard to get stable anchors, even having > full history of changes. On the other hand I see no reason to avoid > stable IDs where they exist. Looks like a reason for defcustom at least. > I consider random anchors and the cache to make some of them stable as > an unavoidable fallback when there is no better way (users avoid > property drawers). > > >> Maybe it is possible to create workaround as a custom config without > >> touching of Org code. I guess, "nicer" ids may be replaced by values of > >> ID property. Examples (I tried none of them): > >> - > >> https://tecosaur.github.io/emacs-config/config.html#nicer-generated-headi > >> ng > >> https://orgmode.org/list/E1jxAjq-0004Dk-LH@lists.gnu.org/ (TEC. > >> [Interest] Determanistic Org IDs. Sun, 19 Jul 2020 22:27:31 +0800) > > ... > > > The methods above are, as I understand it, all about making more beautiful > > links to export to HTML. > > Not about the "translation table" devised in `ox.el` being broken when > > working with multiple org-files. > > My idea of a workaround was to throw away all code deriving pretty link > and to put ID value instead.