Le ven. 29 mai 2026 à 05:36, Christian Moe <[email protected]> a écrit : > > Hi, > > I see you've already canceled this. Still, I don't at all think you were > 'completely wrong' about this as you say. You had a working solution to > a problem. And you make good points below, so I'd like to respond to > them anyway, but feel free to ignore the noise if you've moved on. > > > I agree, perhaps simply "url" would be a better name. I will add that > > while this patch is mostly useful for root relative urls, with this > > new link type, you can also export links like "examples/babel.org". > > Links like "examples/babel.org" can't be exported unless you prefix > > them with file: anyways. > > That is, to download an uploaded 'babel.org' file, not an exported > 'babel.html' one, even if org-html-link-org-files-as-html is non-nil. > That would indeed be an additional use for your link type that my > approach does not cover, and -- if you implemented the features you > mentioned below -- it could be better for completability/followability > than current workarounds (absolute https links or relative links in > verbatim HTML).
Yes, completion was one of the reasons that I thought this approach would be worthwhile. With a good completion function, users would have been able to get completion for relative urls for their current directory. I wasn't going to just reuse the file completion function. > > It might also appeal to people who want 'clean' urls without extensions, > which was also implied in Khalid's post. (But for that I very much think > export filters are the better way to go.) > > >> I'm not sure a new link type is the best approach. If you wanted to add > >> this link the simple way, with 'C-u C-c C-l', you'd need to edit out the > >> 'file:~/path/to/folder' bit afterwards. And then, in order to follow the > >> link between Org files, the user needs to supply the base URL they had > >> to edit out in the previous step. > > > > I don't understand what you are saying here. If you have an absolute > > url, why would you convert it into a relative url? > > Example 'file' link with current file completion: > > file:~/path/to/www-folder/en/index.org > > The root-relative 'rel-url' you'd want in HTML on the server: > > rel-url:/en/index.org > > > This is for people who would like to just write a relative url. > > I think this is mostly a problem for people who have a whole project to > export with a folder hierarchy several levels deep, though. > > > I would be open to adding a key binding specifically for this link > > type as well as completion code. I would also be open to adding code > > that automatically detected a base url from a header or file property > > drawer, so that the user didn't always have to enter the base url. > > This is just the base implementation, I didn't want to add any more > > code until I got confirmation that this was an acceptable solution. > > That would address my objections, but at the cost of some duplication of > functionality and code. I think my proposed approach might be simpler, > (though I'm sure it would grow in implementation). Yes, I also no longer think this is worth doing and likely would've asked too much from the user for too little gain. > > >> I think a better solution to this problem is to export ordinary file > >> links in such a way that the local file path to the base directory > >> (containing the Org source files for the web pages) is replaced with > >> "/". This could be done automatically for any links matching the > >> :base-directory of a current publishing process, as well as any other > >> directories listed in a new user variable. > > > > I understand what you are saying, but I really wanted to avoid this > > approach. First, I want to give users the ability to mix the current > > behavior and my new addition without having to use another custom > > variable. > > Fair. But I'm not sure another custom variable with a base url is more > demanding on users than needing to remember to use another link type, > especially if they have to specify a base url anyway to get completion. > And I think the :base-directory of the active publishing project would > be a sane default, so those using org-publish might not need to > customize anything. > > > This way we can take advantage of the fact that users know > > exactly which links should be treated as relative urls ahead of time > > and allow ox to just focus on exporting. > > There is an advantage to that granularity and user agency; here I'd > still go for what I see as the relative simplicity and convenience of a > url-filtering approach. > > Regards, > Christian Yes, I'm just going to implement export filters.
