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 OLOoKgOBs2A2OwEAgWs5BA (envelope-from ) for ; Sun, 30 May 2021 14:11:47 +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 SCzjJQOBs2CGYAAAB5/wlQ (envelope-from ) for ; Sun, 30 May 2021 12:11:47 +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 B78BC9825 for ; Sun, 30 May 2021 14:11:46 +0200 (CEST) Received: from localhost ([::1]:36592 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lnKIB-0002hf-UW for larch@yhetil.org; Sun, 30 May 2021 08:11:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42308) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lnKHp-0002hW-8K for emacs-orgmode@gnu.org; Sun, 30 May 2021 08:11:21 -0400 Received: from relay12.mail.gandi.net ([217.70.178.232]:51941) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lnKHm-0008Hf-Hm for emacs-orgmode@gnu.org; Sun, 30 May 2021 08:11:21 -0400 Received: (Authenticated sender: admin@nicolasgoaziou.fr) by relay12.mail.gandi.net (Postfix) with ESMTPSA id 14684200003; Sun, 30 May 2021 12:11:14 +0000 (UTC) From: Nicolas Goaziou To: Tim Cross Subject: Re: HTML export uses anchor ids which change on every export References: <87wnrhl7z7.fsf@catern.com> <87bl8tz5dr.fsf@nicolasgoaziou.fr> <87zgwdl3in.fsf@gmail.com> <878s3xp243.fsf@gmail.com> <87wnrgls2y.fsf@gmail.com> <87r1ho8z6f.fsf@gmail.com> Mail-Followup-To: Tim Cross , Timothy , emacs-orgmode@gnu.org Date: Sun, 30 May 2021 14:11:13 +0200 In-Reply-To: <87r1ho8z6f.fsf@gmail.com> (Tim Cross's message of "Sun, 30 May 2021 16:56:22 +1000") Message-ID: <87czt8xvz2.fsf@nicolasgoaziou.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=217.70.178.232; envelope-from=mail@nicolasgoaziou.fr; helo=relay12.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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: emacs-orgmode@gnu.org, Timothy 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=1622376707; 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; bh=9Br4+3JV9wGlCCoA/Z+3SyED0a6s8dsxL9+7RnoTnfg=; b=nveJgprdyAv1Tk0OfQ5Fk+tiAiFur4QqkfHsdS3yiJGQj552VJueF4PPhE4cLvbJiuDdiz LnWuM+zf8m8G2lJQ9hUJyJ8Roo3IMF4h8tOuIuUvn9mE7HeZyvtwCr6cJfwqv+l+M5VQKW eejMEMyrkEfiExPk/barHFXLV+mTWX9GJG/oIt/Qqa/hfjVEaEsum9C8IWmg/Cx+ZqV0XY LMEkVEJlwqt7XVgQj3OqSPvamQE2Z7lTtqEk88tDvjg0f4tdX1Bk+5ZnoaeuMQMj2PKg0T Sn+oOONm3kmUqHY8brm+Faiu8WWaoQhsCSfLauAF6mdgQSR0eKnL6/PRRsgO5g== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1622376707; a=rsa-sha256; cv=none; b=epWLD9kR/Uvyy639Gr/UM3Gxao3wmCEmkplTejzkzucN4p69pH9elTnjbecifdzfZfdhND IAfQRvqE2d8ooh2b3eitdJM1leXMGDqEeWCLhtQUlFPznQ85h++gtKcPRSs+u5bbYDJV8T QiD5K05Ya4OWOivgsTjokRC+qxD1QePvg9dYJhvvnM20fVdDljm4Z5yaTHcBn8xIK4QTKD Dmn8dFVqRfac2olIH0pfEPRSH86yoHshRP73XjbVAULTnW55KZFTKObhb6uREC0asr2W1B Q0Sgth/q7EiQ70ZGcHjV2wfx472ECnD7GQQwJohdQIpfrh8EIs1tNV0eZ0Ap/w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=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: -2.43 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=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: B78BC9825 X-Spam-Score: -2.43 X-Migadu-Scanner: scn0.migadu.com X-TUID: NrW/g7qz39m+ Hello, Tim Cross writes: > Perhaps I misunderstood. My reading was that none of the proposed > approaches were complete enough (in the sense they either introduced > other issues or, while addressing some corner cases, made it much harder > to address others, broke or failed to cater for other workflows). > > I was left with the general impression that solving this issue required > a significant amount of re-development and a far more sophisticated > approach for tracking, caching/memoizing IDs and attempting to address > the issues just by patching the existing code was only going to make > small improvements while complicating the existing code and making it > harder to maintain. In short, a significant re-design and > re-implementation effort rather than application of patches on the > existing code base is required and until someone can do this work, the > best approach was to use publish instead of export if link stability was > required. I agree on some points, but my analysis is slightly different. In particular, it seems to me the whole topic is conflating problems. And the mistake is to look for a single solution that solves them all. First, _external_ link stability is a solved problem. Users need to use CUSTOM_ID, no matter what they think about it. I do believe there is no other automatic way to solve this. Only approximations of a solution, which will bite you in one way or the other, as you noted. Secondly, _internal_ link stability is not that important. By definition, if you're not going to see them, you don't care about what they look like, as long as they correctly link the expected parts of the document. Current implementation of internal references guarantees all internal links do work, with export or publish, but does not go further. I don't think we need another solution for internal links since they do the job. This is not to say there is no problem to solve, of course. Currently, internal links sometimes leak outside, which understandably bothers users. Even though there is no ultimate solution for this besides manually writing every link going to the outside, it may be possible to mitigate the issue, if users accept to get bitten from time to time. With that in mind, I think Timothy's solution goes in the right direction, but, IMO, attempts to solve the problem at the wrong level, i.e., by trying to unify all links (internal and external) into a single banner. I'm not convinced this is doable, because expectations are so different. However, this kind of solution could be implemented in Org and used by export back-ends generating external links. For example, Org Export could provide, e.g., `org-export-punycode', and Org Export HTML could use instead of internal `org-export-get-reference'. As I wrote already, Org Export Texinfo does something similar for the nodes it generates. Since those are meant to be external references, the back-end tries hard to generate something meaningful (in `org-texinfo--get-node') and, as a last resort, `org-export-get-reference'. Even though I mentioned it in the other thread, it didn't attract much interest. This is, I think, a practical way to improve the actual problem, i.e., how to to generate automatically pseudo-stable external links (note: I'm writing this without contempt). Regards, -- Nicolas Goaziou