The (xxx) form for a link target, especially one outside of a block,
doesn't seem to have meaning within the document model that Org
understands. So, yes, this explains *why* I am seeing the error
described above. But I still think there is a legitimate bug report
here, since the behaviour is not likely to be expected by the user.
Someone in my position has no interest in code refs, I was only trying
to link to a bit of text in the buffer. Saying "oh but you can't link
to this *one* kind of text" is perhaps a fair move. On the other
hand, given that "following a link" just means "run a search process",
that search process *could* be smart enough to notice that "no coderef
was found, maybe the user meant to link to some plain text in
parentheses". Then I wouldn't see an error.
On Thu, Apr 20, 2017 at 11:12 PM, Nicolas Goaziou
<m...@nicolasgoaziou.fr> wrote:
> Joe Corneli <holtzerman...@gmail.com> writes:
>
>> In my opinion, capture and/or search should do something different for
>> text beginning "(" and ending with ")", when this text is a link
>> target that is not within a code block.
>
> See below.
>
>> The docs say:
>>
>> "In literal examples, Org will interpret strings like ‘(ref:name)’ as
>> labels"
>>
>> But the text (like this) in my example wasn't inside of a code block,
>> nor was it presented as (ref:like this).
>
> There are two syntaxs: the one within the code block, which is (ref:xxx)
> by default and can be changed, and the one outside the block, which is
> (xxx), and cannot be changed. See the following example from the manual:
>
> #+BEGIN_SRC emacs-lisp -n -r
> (save-excursion (ref:sc)
> (goto-char (point-min))) (ref:jump)
> #+END_SRC
> In line [[(sc)]] we remember the current position. [[(jump)][Line
> (jump)]]
> jumps to point-min.
>
> Regards,
