* Julien Dallot <[email protected]> [2026-06-21 12:53]: > > 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.
Putting metadata into link is wrong. Subject is about arbitrary metadata in org links. Your Three Options ------------------ 1. Full web compatibility — the link works when pasted into a browser 2. Partial web compatibility — the link contains plists that can be translated to web syntax 3. No web compatibility — the link is Emacs-only Option 1 is dead. You already proved it yourself: custom keywords break the fragment directive. Region highlighting is not supported. The web standard does not allow arbitrary metadata in the URL. Option 2 is where we are now. Plists in the link. ::(:page 12 :edges (0.240196 ...)). It works inside Emacs. It can be translated to web syntax for export (stripping Emacs-specific keywords). It is human-readable. It is extensible. Option 3 is where Org currently is: [[pdf:file.pdf::page=12]]. Limited. Not extensible. No arbitrary metadata. Option 2 looks the best but is compromise. The correct approach is not Option 1, 2, or 3. It is Option 4: the link is just an identifier. The metadata is in the database. [[id:127190][Ali Cook - Snake Goddess]] or use UUID, or any other identifier. You do not even need the name, as Org could be made to read the name from the ID or UUID if name not specified. Everything else—the page number, the coordinates, the highlight, the timestamp, the relationships, the tags, the type, the subtype, the author, the date, the version, the viewer preference—lives in PostgreSQL. -- Jean Louis
