Max Nikulin <[email protected]> writes: > On 14/06/2026 7:53 pm, Christian Moe wrote: >>> [[pdf:<path>::(:page 12 :edges (0.240196 0.478535 0.331699 0.494949))]] >> The =::= separator is already in use for line numbers, text search, >> headline names, custom IDs and code references. Its use for metadata >> additions would not be generalizable to 'file:' and 'id:' links where >> this search syntax is useful. > > I think, "::(...)" is unique enough.
You may be right. I failed to consider that surrounding parentheses are stripped from search strings when storing links (org-link--normalize-string), so there's little or no ambiguity. And as long as they can be distinguished, I suppose one could have /both/ a doc-fragment search string /and/ additional metadata with [[linktype:url::searchstring::(:meta data)]] Though taking care to split only on double colons without surrounding spaces, since search strings may contain " :: " from description lists. :) > (...) > Specifically to long attributes like link titles, I would consider new > type of links that are defined outside of paragraphs [[ext:some-link]] > > #+name:some-link > - title :: Example of title > - url :: https://example.com > - rel :: nofollow,noreferrer > Definitions may be hidden from export using a special section or a > drawer. In some sense it is close to org-cite... MarkDown and > reStructuredText allows to avoid long URLs in text paragraphs. That's a really interesting idea! (Btw, I originally took the leap to Emacs because it was the only editor with decent rST support, then quickly abandoned rST for Org. But now that you mention it, this is one of the things I think rST did neatly.) > As to fragments for other formats, I would check if there are RFC or > at least proposals. I discovered the spec for PDF when I noticed a > mention of a proposal for MarkDown. Even discussions of draft > revisions may be available with discarded variants of syntax and > downsides of each option. Yes, sound advice. Regards, Christian
