From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id UPxuNTTKNGZYUwEAe85BDQ:P1 (envelope-from ) for ; Fri, 03 May 2024 13:27:49 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id UPxuNTTKNGZYUwEAe85BDQ (envelope-from ) for ; Fri, 03 May 2024 13:27:48 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=NpgosKAj; 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=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1714735668; 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=9KKnHV9eEmnl86gN4yg5IkJ+Ryxhrda+iga/dKVM5K0=; b=h+tTseugTbYzA5z32WCxJwSAFTNyv2/7wYyD0ThM61wqJsXLEEtxnU9CHI2GQrPuj2zG7/ iv8W8thbYcXnsxDy3Ab6k3OLKYYafCooD7m5kJGk6G47PRjCYvkapHL+6z1bwWn/ObAgMe 7fKElHlx9as8cSLsoDfyUL62ZMMOGh16Iki6cxl8FJPDIOM1nYQaPnkzXRxk/72SmwOREH BHS6YOG3mCFZWXhF0BGDXLpGwtMIVU0F4vJDnIdM8dQvfxZfzuqZ/FN59OPEZyW8qm/k+k Mc2ubmUDH6w2Wax8YLTjOYG3sLcf7PzIbW9epPJHocl1b/8a3UcPc+eCFHBDIg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=NpgosKAj; 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=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1714735668; a=rsa-sha256; cv=none; b=AWsAdURfXx/fHITLFDaRjZuHI9r2bFrLDmddmkzVTrGh6mbSv6RC+hA6QlbIeHJrgDJ2Su biWbBx46y8AJRbi3dhe6EoJ+YC5EEP4ehglq3HppNxMgyUGsrqy/xgwj2Q6hTQvsR9be8o WoVxiSvTguCSEXOW1VL+uiDo5BYVjlNXT8iRxnL2eWfthcFFe8FfHuF/QEHchYniGnatti FzqRoJl77jtatVcf2p0p9rHijUVJky1ISJ6fkgw47+JjpB811sgNzieSPQ/R1rYxlRf3z7 sjIY1UvVzk/LH24VeCv1+auwuiL8wQV9GRR1AVNq74V/Qt1M0xyhtbwcXg3EbA== 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 8E1EA23FF2 for ; Fri, 3 May 2024 13:27:47 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s2r48-00035A-K6; Fri, 03 May 2024 07:27:01 -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 1s2r42-00033u-C4 for emacs-orgmode@gnu.org; Fri, 03 May 2024 07:26:54 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s2r3z-0003y0-Ud for emacs-orgmode@gnu.org; Fri, 03 May 2024 07:26:54 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id B3080240027 for ; Fri, 3 May 2024 13:26:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1714735609; bh=Ol5WdfEupWV9o9e3/Qb+29ie1dxXn9YCAIrRLFmB5Uk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=NpgosKAjFLoLlh3DiuwuHImdbkrsNpqNavcVOaCtGV2NSGxzum2Zho+vSHhGphKvU yZN3CIpbMvlvcDcmgwsBlffjneN4FuofREpZAppMfuKvX+VW9eKV1TfWnC2csIuHXp W51PxANr4SdY8UJHBhwDeLNOPCeg3G+b/u7TSc0kYvzoGPaRDF2C+aYeC60yynZvNy e4VdBtZy7KyX3ZDD//qtdnIsEbrfNhgMvX8uJ3pT9cVdfC7U4wp5CAAjEuZ6H9g9i7 GkXJZE1f2aIp2GqWD7KEImuTboH1TbB63txBtd/eTI56JoJpOKQfab4lK548aRsvWJ +a+t0b86+7evA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4VW7mm510bz9rxD; Fri, 3 May 2024 13:26:48 +0200 (CEST) From: Ihor Radchenko To: Protesilaos Stavrou Cc: emacs-orgmode@gnu.org Subject: Re: [BUG] HTML export does not preserve footnote label [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/)] In-Reply-To: <87bk5nclh4.fsf@protesilaos.com> References: <877chcyz36.fsf@protesilaos.com> <87o7anop4i.fsf@localhost> <87y19lfzwv.fsf@protesilaos.com> <875xwpe1c5.fsf@localhost> <875xwngiwx.fsf@protesilaos.com> <871q79cqgf.fsf@localhost> <87cyqcv9q1.fsf@protesilaos.com> <87a5lgv8qd.fsf@protesilaos.com> <875xw1lqm1.fsf@localhost> <87bk5nclh4.fsf@protesilaos.com> Date: Fri, 03 May 2024 11:28:01 +0000 Message-ID: <87le4rt9ry.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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.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: -8.46 X-Migadu-Queue-Id: 8E1EA23FF2 X-Migadu-Scanner: mx10.migadu.com X-Migadu-Spam-Score: -8.46 X-TUID: rcOmgN0VCXJu Protesilaos Stavrou writes: >>> Since we are now using labels for the HTML export, I think it makes >>> sense to optionally use those for the anchor tags as well. >> ... >> We can indeed add such option, but is it of any practical use? >> Do you have examples of workflows when such new option will be useful? > > An important purpose of using labels is sustainability. If the document > changes, the labels remain (as would CUSTOM_ID). The problem when > numbers are used in the anchor text is that if others want to make a > reference to the footnote (cite it), they will use what they see (not > the ID, which appears in the source only). And if the document changes, > their references will be broken. Sorry, but I am not convinced. I can make the same argument, say, for headline titles: It is very natural to refer to a headline when referencing a document, but when headline changes, such reference is no longer going to work. For headline titles, it is well-known that a more reliable way is to use #anchor in the URL. Anchors are much less likely to change compared to headline titles. With your previous patch, footnote anchors became more stable and people can now reliably link to footnotes using #anchor semantics, given that the page author took care about naming the footnotes. I find it good enough. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at