Re: [O] open link in source code block

[Berry, Charles]

> On Jan 5, 2019, at 7:41 AM, Win Treese <address@hidden> wrote:
> 
> 
> 
>> On Jan 5, 2019, at 5:25 AM, Eric S Fraga <address@hidden> wrote:
>> 
>> On Friday,  4 Jan 2019 at 19:38, Win Treese wrote:
>>> Suppose I have the following Org file contents:
>>> 
>>> * test
>>> 
>>> #+BEGIN_SRC emacs-lisp
>>> (setq yyy 3)
>>> ;; See https://www.gnu.org
>>> #+END_SRC
>>> 
>>> The URL for gnu.org is highlighted as a clickable link. But if I click
>>> it, the source block is evaluated. This seems rather unexpected,
>>> especially since my intention was to open the link.
>> 
>> Probably expected albeit maybe not your preferred behaviour; all about
>> precedence.  In any case, I would suggest that the easy solution would
>> be to move such links out of the src block.  I usually put these as org
>> comments, along the lines of
>> 
>> # See https://www.gnu.org
>> #+BEGIN_SRC emacs-lisp
>> (setq yyy 3)
>> #+END_SRC
>> 
>> My approach to literate programming is to have no (significant) comments
>> in the code segments themselves.  Each code block is small and has all
>> commentary in the text, not the code.
> 
> Thanks for the note, Eric.
> 
> I think the style you describe is good in most cases. I stumbled over this in 
> a
> more complicated situation in which rearranging things doesn’t work.
> 
> This seems like a slightly bigger problem, though: clicking on a highlighted
> link doesn’t just fail to open the link, it executes the source block, which 
> can
> have very unintended side effects.
> 
> I wonder if the issue is an artifact of implementation rather than intentional
> design: org-open-at-mouse sets point to the location of the click and then
> calls org-open-at-point. The documentation at points says that C-c C-o in 
> a source block opens the results of evaluation (fair enough, although the
> docstring does not).
> 
> So the problem seems to be about the mouse click behavior, not the basic
> function of org-open-at-point.

AFAICS, the issue is with org-open-at-point.

If you really want to `fix' this, there is a hook that allows customization of 
the behavior of org-open-at-point.

This snippet will add a function to that hook that will attempt to follow a 
link, when you click on a link in a src-block:

#+begin_src emacs-lisp
  (defun org-follow-link-in-src-block-hook ()
    (and
     (eq 'src-block (org-element-type (org-element-context)))
     (let ((link-be (org-in-regexp org-any-link-re)))
       (if link-be
           (org-open-link-from-string
            (buffer-substring-no-properties (car link-be)
                                            (cdr link-be))))
       link-be)))
  (add-hook 'org-open-at-point-functions 'org-follow-link-in-src-block-hook)
#+end_src

Beware that this might not be what is wanted if you have code that matches 
`org-any-link-re' and you happen to click on it.  

For example, if you have code that uses double brackets to denote subscripts 
(like R), this can cause havoc when you try to edit a subscript in the org 
buffer (rather than in an edit buffer) by clicking on it.  Without this hook 
function, clicking on a bracket subscript will prompt for evaluation which is 
annoying, but maybe less so than interpreting the subscript as a link.

You might use a more limited regex or add a query in 
`org-follow-link-in-src-block-hook' to be sure following a link is really  what 
you want.

HTH,

Chuck