Re: Internal link broken when publishing (was org-id with ox-html)
On Monday, 20 September 2021 16:13:24 CEST Max Nikulin wrote: > On 20/09/2021 07:05, chris wrote: > > 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.) > > It is already tracked on https://updates.orgmode.org/ as > "Inconsistent handling of id: links to other file during publish" How awesome!
Re: Internal link broken when publishing (was org-id with ox-html)
On 20/09/2021 07:05, chris wrote: 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.) It is already tracked on https://updates.orgmode.org/ as "Inconsistent handling of id: links to other file during publish"
Re: Internal link broken when publishing (was org-id with ox-html)
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...@lists.gnu.org/ (TEC. > >> [Interest]
Re: Internal link broken when publishing (was org-id with ox-html)
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. 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-heading https://orgmode.org/list/e1jxajq-0004dk...@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.
Re: Internal link broken when publishing (was org-id with ox-html)
On Tuesday, 24 August 2021 17:23:24 CEST Maxim Nikulin wrote: > On 23/08/2021 03:42, inkbottle wrote: > > Links between two different files, like > > `[[id:e54113f9-2ad7-4a86-94be-68ffc696de0b][hello]]`, get broken when > > publishing. (whatever the settings). > > > > I haven't found any workaround. > > > > Being able to move around entries, functionality provided by > > `org-id-link-to- org-use-id`, is pivotal, IMO. > > From my point of view it looks like a bug. > https://code.orgmode.org/bzg/org-mode/src/master/lisp/ox.el#L4381 Thanks a lot for your help, I'm really struggling on this one. Sorry, I was afk for a few days. I believe it's a bug, plain and simple. With a unique org file, the `:ID: e54113f9-2ad7-4a86-94be-68ffc696de0b` are resolved to `orgfa9c151` consistently. Which is the expected behavior: the translation table is consistent. When there are multiple org files, in every example I've tried, every `org-id` based links was broken. 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". That method, would be different from the *upstream* way, consisting in creating a "translation table". IMO the "patch" is more like a temporary workaround which can make the code confusing and difficult to maintain. Because a unique question is solved in different ways by different developers in different files. I think that the fix should happen in https://github.com/emacsmirror/org/blob/master/lisp/ox.el where the translation table is created and used, but I failed to grasp how it works due to my insufficient understanding of emacs-lisp. > 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". > 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-heading > https://orgmode.org/list/e1jxajq-0004dk...@lists.gnu.org/ (TEC. > [Interest] Determanistic Org IDs. Sun, 19 Jul 2020 22:27:31 +0800) > - > https://github.com/alphapapa/unpackaged.el#export-to-html-with-useful-anchor > s > https://orgmode.org/list/CA+G3_POCYTKR6M1K8XUPzUsg5EHd5Tv4FE4X-6MvadCSjSkHi > a...@mail.gmail.com/ (Tom Gillespie. Tue, 8 Dec 2020 20:39:08 -0500, Re: > stability of toc links) - > https://github.com/zzamboni/dot-doom/blob/master/doom.org#capturing-and-crea > ting-internal-org-links > https://orgmode.org/list/CAGY83EcFExvco6TuTOQiywgdDO0cXE+db828LeiDdimxBroVs > g...@mail.gmail.com/ (Diego Zamboni. Wed, 9 Dec 2020 09:45:52 +0100. Re: > stability of toc links) - > http://ivanmalison.github.io/dotfiles/#usemyowndefaultnamingschemefororghead > ings > https://orgmode.org/list/4698cfeb2e415f88bd25e71267f29...@isnotmyreal.name/ > (TRS-80. Sat, 12 Dec 2020 20:25:15 -0500. Re: Better heading links in > org-mode exports) > - https://writequit.org/articles/emacs-org-mode-generate-ids.html 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. org-id is creating a neat framework for navigating between multiple org-files. Also, if I remember correctly, when using `CUSTOM_ID` with several org-files, you have to specify the file, contrary to how org-id work, using a database to find all by itself, the correct file to jump to.
Re: Internal link broken when publishing (was org-id with ox-html)
On 23/08/2021 03:42, inkbottle wrote: Links between two different files, like `[[id:e54113f9-2ad7-4a86-94be-68ffc696de0b][hello]]`, get broken when publishing. (whatever the settings). I haven't found any workaround. Being able to move around entries, functionality provided by `org-id-link-to- org-use-id`, is pivotal, IMO. From my point of view it looks like a bug. https://code.orgmode.org/bzg/org-mode/src/master/lisp/ox.el#L4381 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. 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-heading https://orgmode.org/list/e1jxajq-0004dk...@lists.gnu.org/ (TEC. [Interest] Determanistic Org IDs. Sun, 19 Jul 2020 22:27:31 +0800) - https://github.com/alphapapa/unpackaged.el#export-to-html-with-useful-anchors https://orgmode.org/list/ca+g3_pocytkr6m1k8xupzusg5ehd5tv4fe4x-6mvadcsjsk...@mail.gmail.com/ (Tom Gillespie. Tue, 8 Dec 2020 20:39:08 -0500, Re: stability of toc links) - https://github.com/zzamboni/dot-doom/blob/master/doom.org#capturing-and-creating-internal-org-links https://orgmode.org/list/cagy83ecfexvco6tutoqiywgddo0cxe+db828leiddimxbro...@mail.gmail.com/ (Diego Zamboni. Wed, 9 Dec 2020 09:45:52 +0100. Re: stability of toc links) - http://ivanmalison.github.io/dotfiles/#usemyowndefaultnamingschemefororgheadings https://orgmode.org/list/4698cfeb2e415f88bd25e71267f29...@isnotmyreal.name/ (TRS-80. Sat, 12 Dec 2020 20:25:15 -0500. Re: Better heading links in org-mode exports) - https://writequit.org/articles/emacs-org-mode-generate-ids.html
Re: Internal link broken when publishing (was org-id with ox-html)
Links between two different files, like `[[id:e54113f9-2ad7-4a86-94be-68ffc696de0b][hello]]`, get broken when publishing. (whatever the settings). I haven't found any workaround. Being able to move around entries, functionality provided by `org-id-link-to- org-use-id`, is pivotal, IMO.
Internal link broken when publishing (was org-id with ox-html)
I've done a lot of investigation. I totally agree with internal links not being stable through publishing: `3c5997f1-205a-437e-8722-d5f52239a207` => `"bye.org#orgfa9c151"` I totally agree with what Nicolas Goaziou says there: https://lists.gnu.org/archive/html/emacs-orgmode/2021-05/msg01254.html However, I do have an _internal link_ in the form: `[[id:3c5997f1-205a-437e-8722-d5f52239a207][bye]]` (This link is not hand made at all, it is the result of: `org-id-get-create` `org-store-link` `org-insert-link`.) Which is translated into: `bye` But no target of the corresponding form is created, and that somewhat in accordance with the cited post above. But it breaks the link. As I understand it, in accordance with the cited post, the internal link should be "interpreted" as: `bye` (from: `[[id:3c5997f1-205a-437e-8722-d5f52239a207][bye]]`). For that, there should be some "translation table": `3c5997f1-205a-437e-8722-d5f52239a207 => bye.org#orgfa9c151` (there might already such translation table somewhere). (Actually it is `cache`, in https://github.com/emacsmirror/org/blob/master/lisp/ox.el#L4442) The obvious workaround would be to use `CUSTOM_ID`, which is stable through publishing. But it's not at all a functionality I'm looking for. I've thought of a function using `org-map-entries`, creating a `:CUSTOM_ID:` as a duplicate of `:ID:` everywhere, creating the `:ID:` if necessary. Always using `org-id-get-create`. But maybe there is an _obvious way_ to have it working out of the box. Here is a minimal example: ## file: hello.org * hello :PROPERTIES: :ID: e54113f9-2ad7-4a86-94be-68ffc696de0b :END: [[id:3c5997f1-205a-437e-8722-d5f52239a207][bye]] ## file: bye.org * bye :PROPERTIES: :ID: 3c5997f1-205a-437e-8722-d5f52239a207 :END: Thanks, Chris P.S. I'm pretty sure the minimal example above can work right out of the box with someone, who unlike me, knows how to correctly configure the publishing. However, I mention two other leads, the first one I prefer by far: (to be honest this first one it is not about internal links not breaking at publishing time, which was a "given", but to form more "meaningful" publishing id) 1. Suggestions have been made by Nicolas Goaziou to look in the direction of `org-export-get-reference` (at the level of the "translation table"?) https://github.com/emacsmirror/org/blob/master/lisp/ox.el#L4443 2. Another suggestion is from org-roam https://github.com/org-roam/org-roam/wiki/Hitchhiker's-Rough-Guide-to-Org-roam-V2#export https://gist.github.com/jethrokuan/d6f80caaec7f49dedffac7c4fe41d132