Possible bug: Can not search for text in links - only description

Possible bug: Can not search for text in links - only description

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]

Hi

I got an error as follow when I tried to export:

,----
| org-babel-exp process R at line 5495...
| Evaluation of this R code-block is disabled.
| user-error: Unable to resolve link "*uLELFit"
`----

I thought "OK - I'll search for uLELFit and just fix this link - but I
could do what I wanted, I did not manage to find the link.

I figured out that I can not search for text in the link.

Thins is quite annoying, especially as I even thought of opening the
file in another texteditor, search for the string, and save it again.

As an example: if this link is in an org-mode file, A search for "exa"
does not return any results.

[[*Examples][Link to exp]]

Is this a problem on my side?
,----
| Org-mode version 8.3beta (release_8.3beta-927-ge0b19d @ /Users/rainerkrug/.emacs.d/org-mode/lisp/)
| GNU Emacs 24.4.1 (x86_64-apple-darwin14.0.0, Carbon Version 157 AppKit 1343.16) of 2015-02-02 on Rainers-MacBook-Pro-4.local
`----

Thanks,

Rainer

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 494 bytes --]

Re: Possible bug: Can not search for text in links - only description

[Richard Lawrence]

Hi Rainer,

Rainer M Krug <Rainer@krugs.de> writes:

> I figured out that I can not search for text in the link.
>
> Thins is quite annoying, especially as I even thought of opening the
> file in another texteditor, search for the string, and save it again.
>
> As an example: if this link is in an org-mode file, A search for "exa"
> does not return any results.
>
> [[*Examples][Link to exp]]
>
> Is this a problem on my side?

No, I confirm that that's how it works for me, too.  

I am not sure if this counts as a bug or not, so someone else should
still address this question.  Maybe this is the desired behavior, given
that the link text is hidden?  Or maybe it's just not possible to search
in hidden text?

There's a less-drastic solution than switching to another editor though!
You can just turn off Org mode...try M-x fundamental-mode, then run the
search.

Best,
Richard

Re: Possible bug: Can not search for text in links - only description

[Sebastien Vauban]

Richard Lawrence wrote:
> Rainer M Krug <Rainer-vfylz/Ys1k4@public.gmane.org> writes:
>
>> I figured out that I can not search for text in the link.
>>
>> Thins is quite annoying, especially as I even thought of opening the
>> file in another texteditor, search for the string, and save it again.
>>
>> As an example: if this link is in an org-mode file, A search for "exa"
>> does not return any results.
>>
>> [[*Examples][Link to exp]]
>>
>> Is this a problem on my side?
>
> No, I confirm that that's how it works for me, too.  
>
> I am not sure if this counts as a bug or not, so someone else should
> still address this question.  Maybe this is the desired behavior, given
> that the link text is hidden?  Or maybe it's just not possible to search
> in hidden text?
>
> There's a less-drastic solution than switching to another editor though!
> You can just turn off Org mode...try M-x fundamental-mode, then run the
> search.

M-x visible-mode is your friend here.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Possible bug: Can not search for text in links - only description

[Alexis]

On 2015-03-21T01:59:07+1100, Richard Lawrence 
<richard.lawrence@berkeley.edu> said:

 RL> I am not sure if this counts as a bug or not, so someone else 
 RL> should still address this question.  Maybe this is the 
 desired RL> behavior, given that the link text is hidden?  Or 
 maybe it's just RL> not possible to search in hidden text?

Cf. the `search-invisible` variable:

    search-invisible is a variable defined in `isearch.el'.  Its 
    value is open 
 
    Documentation: If t incremental search/query-replace can match 
    hidden text.  A nil value means don't match invisible text. 
    When the value is `open', if the text matched is made 
    invisible by an overlay having an `invisible' property and 
    that overlay has a property `isearch-open-invisible', then 
    incremental search will show the contents.  (This applies when 
    using `outline.el' and `hideshow.el'.) 
 
    To temporarily change the value for an active incremental 
    search, use M-s i. 


Alexis.

Re: Possible bug: Can not search for text in links - only description

[Jacob Gerlach]

On Fri, Mar 20, 2015 at 9:44 AM, Rainer M Krug <Rainer@krugs.de> wrote:
> Hi
>
> I got an error as follow when I tried to export:
>
> ,----
> | org-babel-exp process R at line 5495...
> | Evaluation of this R code-block is disabled.
> | user-error: Unable to resolve link "*uLELFit"
> `----
>
> I thought "OK - I'll search for uLELFit and just fix this link - but I
> could do what I wanted, I did not manage to find the link.
>
> I figured out that I can not search for text in the link.

`org-toggle-link-display' is very helpful here. See [1] for a
discussion of the patch and new behavior.

It is perhaps worth considering to change the error message to show
the link description (when it exists) rather than the link itself to
make it easier to find the bad link.

Regards,
Jake

[1] http://comments.gmane.org/gmane.emacs.orgmode/90891

Re: Possible bug: Can not search for text in links - only description

[Ken Mankoff]

It would be nice to be able to search in links without extra work to change modes. Without this, you cannot even search for a cite key! 

  -k. 

Please excuse brevity. Sent from pocket computer with tiny non-haptic feedback keyboard. 

> On Mar 20, 2015, at 11:38, Jacob Gerlach <jacobgerlach@gmail.com> wrote:
> 
>> On Fri, Mar 20, 2015 at 9:44 AM, Rainer M Krug <Rainer@krugs.de> wrote:
>> Hi
>> 
>> I got an error as follow when I tried to export:
>> 
>> ,----
>> | org-babel-exp process R at line 5495...
>> | Evaluation of this R code-block is disabled.
>> | user-error: Unable to resolve link "*uLELFit"
>> `----
>> 
>> I thought "OK - I'll search for uLELFit and just fix this link - but I
>> could do what I wanted, I did not manage to find the link.
>> 
>> I figured out that I can not search for text in the link.
> 
> `org-toggle-link-display' is very helpful here. See [1] for a
> discussion of the patch and new behavior.
> 
> It is perhaps worth considering to change the error message to show
> the link description (when it exists) rather than the link itself to
> make it easier to find the bad link.
> 
> Regards,
> Jake
> 
> [1] http://comments.gmane.org/gmane.emacs.orgmode/90891
> 

Re: Possible bug: Can not search for text in links - only description

[Charles C. Berry]

On Fri, 20 Mar 2015, Ken Mankoff wrote:

> It would be nice to be able to search in links without extra work to 
> change modes. Without this, you cannot even search for a cite key!

You *can* search in links without changing modes.

<menu-bar> <edit> <search> <search-forward> Exa RET

runs nonincremental-search-forward on "Exa" and  finds Rainier's 
`*Example' if point preceeds it.

M-x occur RET Exa RET

finds the link, too.

Chuck

>
>  -k.
>
> Please excuse brevity. Sent from pocket computer with tiny non-haptic feedback keyboard.
>
>> On Mar 20, 2015, at 11:38, Jacob Gerlach <jacobgerlach@gmail.com> wrote:
>>
>>> On Fri, Mar 20, 2015 at 9:44 AM, Rainer M Krug <Rainer@krugs.de> wrote:
>>> Hi
>>>
>>> I got an error as follow when I tried to export:
>>>
>>> ,----
>>> | org-babel-exp process R at line 5495...
>>> | Evaluation of this R code-block is disabled.
>>> | user-error: Unable to resolve link "*uLELFit"
>>> `----
>>>
>>> I thought "OK - I'll search for uLELFit and just fix this link - but I
>>> could do what I wanted, I did not manage to find the link.
>>>
>>> I figured out that I can not search for text in the link.
>>
>> `org-toggle-link-display' is very helpful here. See [1] for a
>> discussion of the patch and new behavior.
>>
>> It is perhaps worth considering to change the error message to show
>> the link description (when it exists) rather than the link itself to
>> make it easier to find the bad link.
>>
>> Regards,
>> Jake
>>
>> [1] http://comments.gmane.org/gmane.emacs.orgmode/90891
>>
>
>

Charles C. Berry                 Dept of Family Medicine & Public Health
cberry at ucsd edu               UC San Diego / La Jolla, CA 92093-0901
http://famprevmed.ucsd.edu/faculty/cberry/

Re: Possible bug: Can not search for text in links - only description

[Jacob Gerlach]

On Sat, Mar 21, 2015 at 7:34 PM, Alexis <flexibeast@gmail.com> wrote:
>
> On 2015-03-21T01:59:07+1100, Richard Lawrence
> <richard.lawrence@berkeley.edu> said:
>
> RL> I am not sure if this counts as a bug or not, so someone else
> RL> should still address this question.  Maybe this is the desired
> RL> behavior, given that the link text is hidden?  Or maybe it's just
> RL> not possible to search in hidden text?
>
> Cf. the `search-invisible` variable:

`search-invisible' is less helpful that one might think.

I think that the difficulty arises from the fact that links use the
invisibility text property. Folded trees, OTOH, use an invisibility
overlay. Overlay invisibility is searched (and expanded for matches)
when `search-invisible' is set to `open' (the default). While you can
/search/ invisible text, AFAICT, isearch has no machinery to /show/
invisible text (just to "open" invisibility overlays). You can set
`search-invisible' to `t', but then your search is likely to end up on
the ellipses for a folded subtree (since it will no longer unfold).

With `search-invisible' set to `t', point does end up on (still
invisible) matches. I tried cobbling together a hack like:

(add-hook 'isearch-update-post-hook
          (lambda ()
            (if isearch-hidden
                (org-remove-from-invisibility-spec '(org-link))
              (add-to-invisibility-spec '(org-link)))))

(defun jg/isearch ()
  (interactive)
  (let ((search-invisible t))
    (isearch-forward)))

But besides not opening overlays, I think you'd need a similar
function on a couple more isearch hooks to make this work.

On Fri, Mar 20, 2015 at 2:06 PM, Charles C. Berry <ccberry@ucsd.edu> wrote:
> You *can* search in links without changing modes.
>
> <menu-bar> <edit> <search> <search-forward> Exa RET
>
> runs nonincremental-search-forward on "Exa" and  finds Rainier's `*Example'
> if point preceeds it.

search-forward suffers from the same problem as setting
`search-invisible' to `t' - folded subtrees don't open. I suppose you
could expand the whole tree first and then use it.

> M-x occur RET Exa RET

This worked well for me.

On Sat, Mar 21, 2015 at 7:45 PM, Randomcoder <randomcoder1@gmail.com> wrote:
> In terms of searching through all open buffers,
> here is what I use (helm and helm-multi-occur):
Can you comment on the capability to search invisible text (such as
the invisible path for an org link)? For the problem at hand, there's
no need to search multiple buffers, just to search the invisible text
in a given buffer.

For the (hopefully) infrequent case of finding a mistyped link,
`org-toggle-link-display' or M-x occur should be adequate.

Re: Possible bug: Can not search for text in links - only description

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 2105 bytes --]

"Charles C. Berry" <ccberry@ucsd.edu> writes:

> On Fri, 20 Mar 2015, Ken Mankoff wrote:
>
>> It would be nice to be able to search in links without extra work to
>> change modes. Without this, you cannot even search for a cite key!
>
> You *can* search in links without changing modes.
>
> <menu-bar> <edit> <search> <search-forward> Exa RET
>
> runs nonincremental-search-forward on "Exa" and  finds Rainier's
> `*Example' if point preceeds it.
>
> M-x occur RET Exa RET

Ah - occur is nice - very nice. I like the output and also that it shows
me all hits - I'll use this more often!

Rainer

>
> finds the link, too.
>
> Chuck
>
>>
>>  -k.
>>
>> Please excuse brevity. Sent from pocket computer with tiny non-haptic feedback keyboard.
>>
>>> On Mar 20, 2015, at 11:38, Jacob Gerlach <jacobgerlach@gmail.com> wrote:
>>>
>>>> On Fri, Mar 20, 2015 at 9:44 AM, Rainer M Krug <Rainer@krugs.de> wrote:
>>>> Hi
>>>>
>>>> I got an error as follow when I tried to export:
>>>>
>>>> ,----
>>>> | org-babel-exp process R at line 5495...
>>>> | Evaluation of this R code-block is disabled.
>>>> | user-error: Unable to resolve link "*uLELFit"
>>>> `----
>>>>
>>>> I thought "OK - I'll search for uLELFit and just fix this link - but I
>>>> could do what I wanted, I did not manage to find the link.
>>>>
>>>> I figured out that I can not search for text in the link.
>>>
>>> `org-toggle-link-display' is very helpful here. See [1] for a
>>> discussion of the patch and new behavior.
>>>
>>> It is perhaps worth considering to change the error message to show
>>> the link description (when it exists) rather than the link itself to
>>> make it easier to find the bad link.
>>>
>>> Regards,
>>> Jake
>>>
>>> [1] http://comments.gmane.org/gmane.emacs.orgmode/90891
>>>
>>
>>
>
> Charles C. Berry                 Dept of Family Medicine & Public Health
> cberry at ucsd edu               UC San Diego / La Jolla, CA 92093-0901
> http://famprevmed.ucsd.edu/faculty/cberry/
>
>

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 494 bytes --]

Re: Possible bug: Can not search for text in links - only description

[Achim Gratz]

Rainer M Krug <Rainer <at> krugs.de> writes:
> > M-x occur RET Exa RET
> 
> Ah - occur is nice - very nice. I like the output and also that it shows
> me all hits - I'll use this more often!

It even has a key binding: "M-s o".  If you like a function and wonder if it
has a key binding: "C-h w <function name> RET" will tell you (use it in the
mode you'll want to use that function in, it may not have a key binding in
other modes).


Regards,
Achim

Re: Possible bug: Can not search for text in links - only description

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

Achim Gratz <Stromeko@NexGo.DE> writes:

> Rainer M Krug <Rainer <at> krugs.de> writes:
>> > M-x occur RET Exa RET
>> 
>> Ah - occur is nice - very nice. I like the output and also that it shows
>> me all hits - I'll use this more often!
>
> It even has a key binding: "M-s o".  If you like a function and wonder if it
> has a key binding: "C-h w <function name> RET" will tell you (use it in the
> mode you'll want to use that function in, it may not have a key binding in
> other modes).

Very nice - learning each day something new.

Thanks,

Rainer

>
>
> Regards,
> Achim
>
>
>

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 494 bytes --]

Re: Possible bug: Can not search for text in links - only description

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

Jacob Gerlach <jacobgerlach@gmail.com> writes:

> On Fri, Mar 20, 2015 at 9:44 AM, Rainer M Krug <Rainer@krugs.de> wrote:
>> Hi
>>
>> I got an error as follow when I tried to export:
>>
>> ,----
>> | org-babel-exp process R at line 5495...
>> | Evaluation of this R code-block is disabled.
>> | user-error: Unable to resolve link "*uLELFit"
>> `----
>>
>> I thought "OK - I'll search for uLELFit and just fix this link - but I
>> could do what I wanted, I did not manage to find the link.
>>
>> I figured out that I can not search for text in the link.
>
> `org-toggle-link-display' is very helpful here. See [1] for a
> discussion of the patch and new behavior.
>
> It is perhaps worth considering to change the error message to show
> the link description (when it exists) rather than the link itself to
> make it easier to find the bad link.

Agreed. But I think that showing both would be the d=best solution here.

>
> Regards,
> Jake
>
> [1] http://comments.gmane.org/gmane.emacs.orgmode/90891
>
>

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 494 bytes --]

Re: Possible bug: Can not search for text in links - only description

[Samuel Wales]

hmm:

===
search-invisible is a variable defined in `isearch.el'.
Its value is open

Documentation:
If t incremental search/query-replace can match hidden text.
A nil value means don't match invisible text.
When the value is `open', if the text matched is made invisible by
an overlay having an `invisible' property and that overlay has a property
`isearch-open-invisible', then incremental search will show the contents.
(This applies when using `outline.el' and `hideshow.el'.)
...
===

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

Ramsay's disease DOES progress.  MANY people have died from it.  And
ANYBODY can get it.

Denmark: free Karina Hansen NOW.

Re: Possible bug: Can not search for text in links - only description

[Jacob Gerlach]

org-show-context-detail may also be relevant:

org-show-context-detail is a variable defined in `org.el'.
Its value is ((isearch . lineage)
 (bookmark-jump . lineage)
 (default . ancestors))


Documentation:
Alist between context and visibility span when revealing a location.

Some actions may move point into invisible
locations.  As a consequence, Org always expose a neighborhood
around point.  How much is shown depends on the initial action,
or context.  Valid contexts are

  agenda         when exposing an entry from the agenda
  org-goto       when using the command `org-goto' (C-c C-j)
  occur-tree     when using the command `org-occur' (C-c / /)
  tags-tree      when constructing a sparse tree based on tags matches
  link-search    when exposing search matches associated with a link
  mark-goto      when exposing the jump goal of a mark
  bookmark-jump  when exposing a bookmark location
  isearch        when exiting from an incremental search
  default        default for all contexts not set explicitly
...


but I haven't followed through to see exactly how to use it.

Re: Possible bug: Can not search for text in links - only description

[Ken Mankoff]

On 2015-03-20 at 13:53, Samuel Wales <samologist@gmail.com> wrote:
> hmm:
>
> ===
> search-invisible is a variable defined in `isearch.el'.
> Its value is open
>
> Documentation:
> If t incremental search/query-replace can match hidden text.
> A nil value means don't match invisible text.
> When the value is `open', if the text matched is made invisible by
> an overlay having an `invisible' property and that overlay has a property
> `isearch-open-invisible', then incremental search will show the contents.
> (This applies when using `outline.el' and `hideshow.el'.)
> ...
> ===


Note that setting search-invisible to t means that collapsed segments no longer expand.

  -k.
  

Re: Possible bug: Can not search for text in links - only description

[Samuel Wales]

hi ken,

that's right, my point was that perhaps it is relevant, not that one
would set the variable.

for example, perhaps there is a way that timestamps can have an
invisible property and thus be subject to this variable.

of course, it might not be possible, if timestamps do not use
overlays, but it might inspire a more general fix.


samuel

On 3/31/15, Ken Mankoff <mankoff@gmail.com> wrote:
>
> On 2015-03-20 at 13:53, Samuel Wales <samologist@gmail.com> wrote:
>> hmm:
>>
>> ===
>> search-invisible is a variable defined in `isearch.el'.
>> Its value is open
>>
>> Documentation:
>> If t incremental search/query-replace can match hidden text.
>> A nil value means don't match invisible text.
>> When the value is `open', if the text matched is made invisible by
>> an overlay having an `invisible' property and that overlay has a property
>> `isearch-open-invisible', then incremental search will show the contents.
>> (This applies when using `outline.el' and `hideshow.el'.)
>> ...
>> ===
>
>
> Note that setting search-invisible to t means that collapsed segments no
> longer expand.
>
>   -k.
>
>


-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

Ramsay's disease DOES progress.  MANY people have died from it.  And
ANYBODY can get it.

Denmark: free Karina Hansen NOW.

Re: Possible bug: Can not search for text in links - only description

[Randomcoder]

Hi Rainer,

In terms of searching through all open buffers,
here is what I use (helm and helm-multi-occur):

,----
| (setq helm-M-x-requires-pattern 0)
|
| ;; http://emacs.stackexchange.com/a/740
| (require 'helm-regexp)
| (eval-after-load "helm-regexp"
|   '(setq helm-source-moccur
|          (helm-make-source "Moccur" 'helm-source-multi-occur :follow 1)))
| (defun my-helm-multi-occur-buffers ()
|   "multi-occur in all buffers backed by files."
|   (interactive)
|   (helm-multi-occur
|    (delq nil
|          (mapcar (lambda (b)
|                    (when (buffer-file-name b) (buffer-name b)))
|                  (buffer-list)))))
| (global-set-key (kbd "C-x C-p") (lambda ()
|                                   (interactive)
|                                   (helm-mode 1)
|                                   (my-helm-multi-occur-buffers) 
|                                   (helm-mode 0)
|                                   ))
`----

There are other solutions to this such as org-velocity:

- http://orgmode.org/worg/org-contrib/org-velocity.html
- https://github.com/Fuco1/org-velocity

Both helm + helm-multi-occur and org-velocity offer auto-complete
search functionality.

Best regards


On Fri, Mar 20, 2015 at 02:44:29PM +0100, Rainer M Krug wrote:
> Hi
> 
> I got an error as follow when I tried to export:
> 
> ,----
> | org-babel-exp process R at line 5495...
> | Evaluation of this R code-block is disabled.
> | user-error: Unable to resolve link "*uLELFit"
> `----
> 
> I thought "OK - I'll search for uLELFit and just fix this link - but I
> could do what I wanted, I did not manage to find the link.
> 
> I figured out that I can not search for text in the link.
> 
> Thins is quite annoying, especially as I even thought of opening the
> file in another texteditor, search for the string, and save it again.
> 
> As an example: if this link is in an org-mode file, A search for "exa"
> does not return any results.
> 
> [[*Examples][Link to exp]]
> 
> Is this a problem on my side?
> ,----
> | Org-mode version 8.3beta (release_8.3beta-927-ge0b19d @ /Users/rainerkrug/.emacs.d/org-mode/lisp/)
> | GNU Emacs 24.4.1 (x86_64-apple-darwin14.0.0, Carbon Version 157 AppKit 1343.16) of 2015-02-02 on Rainers-MacBook-Pro-4.local
> `----
> 
> Thanks,
> 
> Rainer
> 
> -- 
> Rainer M. Krug
> email: Rainer<at>krugs<dot>de
> PGP: 0x0F52F982

Re: Possible bug: Can not search for text in links - only description

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 1580 bytes --]

Thanks everybody - many useful comments and ideas.

First I must say it makes sense to give the error message, although I
was quite surprised.

But the message should contain a string one can easily search for. And I
guess the most used search function is C-s I think the message should be
changes to the description of the link and the target in brackets. This
would make searching easier.

Thanks,

Rainer


Rainer M Krug <Rainer@krugs.de> writes:

> Hi
>
> I got an error as follow when I tried to export:
>
> ,----
> | org-babel-exp process R at line 5495...
> | Evaluation of this R code-block is disabled.
> | user-error: Unable to resolve link "*uLELFit"
> `----
>
> I thought "OK - I'll search for uLELFit and just fix this link - but I
> could do what I wanted, I did not manage to find the link.
>
> I figured out that I can not search for text in the link.
>
> Thins is quite annoying, especially as I even thought of opening the
> file in another texteditor, search for the string, and save it again.
>
> As an example: if this link is in an org-mode file, A search for "exa"
> does not return any results.
>
> [[*Examples][Link to exp]]
>
> Is this a problem on my side?
> ,----
> | Org-mode version 8.3beta (release_8.3beta-927-ge0b19d @ /Users/rainerkrug/.emacs.d/org-mode/lisp/)
> | GNU Emacs 24.4.1 (x86_64-apple-darwin14.0.0, Carbon Version 157
> | AppKit 1343.16) of 2015-02-02 on Rainers-MacBook-Pro-4.local
> `----
>
> Thanks,
>
> Rainer

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 494 bytes --]

Re: Possible bug: Can not search for text in links - only description

[Jacob Gerlach]

On Mon, Mar 23, 2015 at 8:45 AM, Rainer M Krug <Rainer@krugs.de> wrote:
> First I must say it makes sense to give the error message, although I
> was quite surprised.
>
> But the message should contain a string one can easily search for. And I
> guess the most used search function is C-s I think the message should be
> changes to the description of the link and the target in brackets. This
> would make searching easier.

FWIW, I completely agree. I would be happy to provide a patch for
this, but I'm not sure how to get the link's description inside
org-export-resolve-fuzzy-link. AFAICT, the `link' object passed to
this function has properties as determined by
`org-element-link-parser'. The properties listed in the docstring
don't include the description.

Could anyone provide a hint on how to get the link's description?

Regards,
Jake