Hi,
sory for the late reply, I was on a journey!
> I mostly agree with your summary. Unfortunately I do not have a roadmap
> with actionable steps.
Without talking about adding this to the org's code base, I would be already
happy that we agree on main guidelines for metadata in links, or at least
narrow down possibilities.
As I mentioned, I am the author of a package that proposes to build a whole
workflow on org links, so having feedback on link format/use cases is already
valuable.
Hence if there emerges here a format that makes sense and that gathers support,
I will anyway implement it; thus getting more feedback to ultimately add it to
org mode, hopefully.
Let's maybe first discuss what we want for a "degree of compatibility" with web
links.
I see 3 degrees:
1. whenever possible, the link should directly work when pasted into the url
bar (after removing the surrounding [[]] of course)
2. pasting the link into url bar doesnt work. But, whenever possible, there
should be a "trivial" way to convert org links into web links.
I'm thinking of the following. use plists to store metadata, but:
- name the plist's properties with the same keywords as in web links (use
:text for searching string, use :highlight to highlight a given pdf region, etc)
- come up with a systematic way to convert structures, ie, (1 2 3 4) becomes
1,2,3,4 (as needed for the edges of the region to highlight)
Not sure this can be done in a systematic way for other use cases, but
this is merely a guideline idea for now.
- during the conversion process, remove any emacs-specific keyword that
would make the web link crash
etc
3. not care at all about web links and stay inside emacs.
Given your comment on legacy format
>> Notice that the links above do not come with the usual separator "::".
>
> Yes, and Org should treat links in a backward compatible way somehow.
I would say the second option looks best.
Having a separator "::" would make the link unrecognized by firefox anyway, so
why not make it more readable as well then.
Julien
"Max Nikulin" <[email protected]> writes:
> On 18/06/2026 5:19 am, Julien Dallot wrote:
>>
>> Based on what we discussed so far, here are some high-level guidelines we
>> may want to follows:
>> - we want to be able to include arbitrary metadata inside an org link (in
>> plain text form)
>
> "Metadata" is too general to my taste. E.g. position or region in the
> target document is more specific. I do not think, it is reasonable to
> store e.g. author name inside file: or http: links (besides, perhaps, as
> a part of the title attribute).
>
>> - we want to be able to store arbitrary metadata in the org element (once
>> the link was parsed)
>> - whenever possible, we want to follow web standards for links.
>>
>> Based on those criteria, here is a possible alternative for the pdf link I
>> presented at the beg of this thread:
>> [[file:<path>#page=1#highlight=0.240196,0.478535,0.331699,0.494949]]
>
> It was a random example created while looking into the RFC for PDF.
>
>> and here is the "web-compatible" equivalent of current org link with
>> ::<search-text> at the end:
>> [[file:<path>#:~:text=<search-text>]]
>
> There are more options to specify text fragment, some are not supported
> by Org.
>
>> The idea is that the link content (inside [[]]) is an (almost) working web
>> link.
>> As is, it actually works: firefox will open the pdf at the right page (if
>> you take the "highlight" part out).
>
> Firefox supports zoom=z,x,y. One may obtain a link through the
> ">>"/"Current page" menu.
>
>> Note that some post-treatment is necessary to reliably convert any
>> org link to a web link, just to replace white spaces with special
>> characters "%20" for instance --- but it seems major web browsers
>> (firefox and chrome) do this conversion automatically.
>>
>> Notice that the links above do not come with the usual separator "::".
>
> Yes, and Org should treat links in a backward compatible way somehow.
>
>> Although desirable, this compatibility with web seems fragile for many
>> reasons:
>> - adding any keyword that's not recognized by the web browser makes the
>> whole set of keywords useless (as I try rn).
>
> Firefox becomes more tolerant if "&" is used as a separator *between*
> parameters instead of "#". Anyway, parsing fragment may be required for
> other viewers. I have not found docs concerning okular (besides
> "#nameddest"), but it supports "#page=5". I am not sure how to combine
> page number and search text in URL for any viewer. Parameters may be
> passed through command line options though.
>
>> I only did superficial documentation there and may be missing key aspects.
>> But wondering what are your thought on this?
>
> I mostly agree with your summary. Unfortunately I do not have a roadmap
> with actionable steps.
