> I may be wrong, but my reading of Julien's proposal is that it should be
> like
>
> [[linktype:url::(:search string :meta data)]]
Yes, but not exactly. Any field should be allowed depending on the specifics of
the link.
Here are some links that I use, for instance.
- For a pdf link:
[[pdf:<path>::(:page 4 :search <some text> :edges (0.176471 0.301768 0.441176
0.32197))]]
- to start a music
[[music:<path>::(:timestamp 00:03:11)]]
- to search for a specific id in a file
[[file:<path>::(:inline-id 20260605T215800 :search 20260605T215800)]]
I added the :search field in the pdf and file links for illustrative purpose.
But I guess such a field could be added there as a backup search option. Say,
if highlighting specific regions is not supported, for the pdf link case.
Some feedbacks advocating for this "concept of arbitrary field", without format
consideration.
The plist's fields are not only useful to provide multiple metadata, they are
also important to handle the metadata properly.
For instance, the metadata of the last link I show (to search for id) cannot be
a simple :search one for reliability reasons. I tried it, and every now and
then following the link would not get me where the search string is, but rather
stay put on the link (since the search string is in there as well).
However, we could still have a :search field, less reliable, in case the emacs'
running instance doesnt know about the :inline-id field.
> However I see no reason to demand support of :meta from each link type.
> Earlier, brainstorming, I tried to add "wrap:" link type (with plist, it
> was easier to implement) on the top of other links without modification
> of code related to specific types. Unlike Samuel Wale's and John
I assume you're talking about the :metadata field I proposed earlier?
There I was not talking about what's inside the link, but rather how the parsed
links are stored by org (so as an org element).
Org elements for links typically have fields :path, :raw-path ... and :search.
But I saw nothing relevant to store additional (arbitrary) metadata, thus my
proposal to have such a field there.
> Do pdf-tools support this kind of addressing? (Or was there a feature
> request for that?)
Not officially, and I dont know of a feature request for this.
However, it can definitely be done without problem (I did it by reusing the
isearch code).
I'd be glad to do a request for this at some point.
About format to highlight a region in pdf-tools.
Pdf tools can highlight a specific region provided four coordinates (called
edges). I am unsure what those edges represent exactly, they are not part of
the documentation (the readme) afaik.
Here is the comment in pdf-tools' code (pdf-isearch.el, l238) that explains it
is in "image-space" coordinates, not sure what this means.
;; The function receives one argument: a list of matches, each
;; being a list of edges. It should return a subset of this list.
;; Edge coordinates are in image-space.")
Julien
"Max Nikulin" <[email protected]> writes:
> On 14/06/2026 9:10 pm, Julien Dallot wrote:
>> - with "#xywh=<coordinates>" for highlighting a given area in a pdf
>> (and not to search text, which is less reliable).
>
> At first glance, the RFC allows to combine #viewrect=... (or
> #highlight=...) and #search=...
>
> Do pdf-tools support this kind of addressing? (Or was there a feature
> request for that?)
>
> On 16/06/2026 1:36 am, Christian Moe wrote:
>> 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)]]
>
> I may be wrong, but my reading of Julien's proposal is that it should be
> like
>
> [[linktype:url::(:search string :meta data)]]
>
> However I see no reason to demand support of :meta from each link type.
> Earlier, brainstorming, I tried to add "wrap:" link type (with plist, it
> was easier to implement) on the top of other links without modification
> of code related to specific types. Unlike Samuel Wale's and John
> Kitchin's approach, it does not require extension of Org syntax:
>
> Max Nikulin. Links & images with different attributes in the same
> paragraph. Sat, 11 Nov 2023 22:54:37 +0700.
> <https://list.orgmode.org/[email protected]>
>
>> Max Nikulin writes:
>>> 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!
>
> Then, back to the original post, we need to decide how to specify
> fragment (search) part of URLs: should it be in the "url" item or we
> allow (but perhaps do not require) to use a separate item. The latter
> adds some complications and flexibility:
>
> #+name:org-faq
> - url :: https://orgmode.org/worg/org-faq.html
> - title :: Org-mode Frequently Asked Questions
>
> #+name:org-faq-mailto
> - ref :: org-faq
> - title :: Org-mode is not opening mailto links in my default mail client
> - fragment :: #mailto-links
>
> #+name:org-faq-mid-handler
> - ref :: org-faq
> - title :: Can I create links to Thunderbirds emails?
> - fragment ::
> - id :: mid-url-handler
>
>> (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.)
>
> I recall a thread requesting wrapping links links like in rST
>
> Steven Penny. Re: Long links. Sun, 5 Jan 2020 08:02:23 -0600
> <https://list.orgmode.org/caaxzdlvoanyeqr7t_egft9ryvys3x8ugoq0wufsrqksyc11...@mail.gmail.com/>
