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). 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). >> 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
