open link in source code block

open link in source code block

[Win Treese]

I suspect that this has come up before, but I couldn’t find anything about it in the mailing list archives.

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.

I don’t know if this is a bug or if it’s the intended behavior. Or if there is a setting I have missed.

Version information: Aquamacs 3.5 on Mac OS 10.13.6, based on Emacs 25.3.50.1, Org version 9.2. Started Aquamacs with -q, then ran (package-initialize) so that it would find the current MELPA version of Org. No other configuration code was run.

Thanks for any insight.

Win Treese
treese@acm.org

Re: open link in source code block

[Eric S Fraga]

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.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.14-1035-gfeb442

Re: open link in source code block

[Win Treese]

> On Jan 5, 2019, at 5:25 AM, Eric S Fraga <esflists@gmail.com> 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.

Thanks,
Win

Re: open link in source code block

[Berry, Charles]

> On Jan 5, 2019, at 7:41 AM, Win Treese <treese@acm.org> wrote:
> 
> 
> 
>> On Jan 5, 2019, at 5:25 AM, Eric S Fraga <esflists@gmail.com> 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

Re: open link in source code block

[Win Treese]

[Quoting trimmed for the most relevant context.]

> On Jan 11, 2019, at 7:12 PM, Berry, Charles <ccberry@ucsd.edu> wrote:
> 
>> On Jan 5, 2019, at 7:41 AM, Win Treese <treese@acm.org> wrote:
>> 
>>> On Jan 5, 2019, at 5:25 AM, Eric S Fraga <esflists@gmail.com> 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. 

>> 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:

[Example code with function added to org-open-at-point-functions elided.]

Chuck,

Thanks for the code. You’re right—the proximate problem is in org-open-at-point.
Unfortunately, org-open-at-point calls org-babel-open-src-block-result first thing,
wrapped by unless, before it gets to running the hook.

Plausible changes would be to treat this as a mouse click issue and change org-open-at-mouse,
or to change the precedence in org-open-at-point, which Eric suggested is a way to look
at the problem.

For the moment, I’m going to use a personal version of org-open-at-mouse, but I still
think that running the code in a block when a URL is clicked is an unusual but 
potentially big problem for someone.

Thanks,
Win

Re: open link in source code block

[Berry, Charles]

> On Jan 16, 2019, at 3:43 PM, Win Treese <treese@acm.org> wrote:
> 
> [Quoting trimmed for the most relevant context.]
> 
>> On Jan 11, 2019, at 7:12 PM, Berry, Charles <ccberry@ucsd.edu> wrote:
>> 
>>> On Jan 5, 2019, at 7:41 AM, Win Treese <treese@acm.org> wrote:
>>> 
>>>> On Jan 5, 2019, at 5:25 AM, Eric S Fraga <esflists@gmail.com> 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. 
> 
>>> 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:
> 
> [Example code with function added to org-open-at-point-functions elided.]
> 
> Chuck,
> 
> Thanks for the code. You’re right—the proximate problem is in org-open-at-point.
> Unfortunately, org-open-at-point calls org-babel-open-src-block-result first thing,
> wrapped by unless, before it gets to running the hook.


TL;DR: "org-open-at-point calls org-babel-open-src-block-result first thing" is not true.

The `unless' COND argument starting around line 5 of the code of `org-open-at-point' runs the hooks in `org-open-at-point-functions'. 

If any hook returns a non-nil then `run-hook-with-args-until-success' returns the value and the BODY forms will not be run.

For example, this: 

	((eq type 'src-block) (org-babel-open-src-block-result))

is part of a BODY form and can only run if all those hooks return nil (or if there is no hook).

The code I provided works as advertised.

HTH,

Chuck

p.s. I am using Org mode version 9.2 (release_9.2-193-ge7901c...

Re: open link in source code block

[Win Treese]

> On Jan 17, 2019, at 1:38 PM, Berry, Charles <ccberry@ucsd.edu> wrote:
> 
> TL;DR: "org-open-at-point calls org-babel-open-src-block-result first thing" is not true.
> 
> The `unless' COND argument starting around line 5 of the code of `org-open-at-point' runs the hooks in `org-open-at-point-functions'. 
> 
> If any hook returns a non-nil then `run-hook-with-args-until-success' returns the value and the BODY forms will not be run.
> 
> For example, this: 
> 
> 	((eq type 'src-block) (org-babel-open-src-block-result))
> 
> is part of a BODY form and can only run if all those hooks return nil (or if there is no hook).
> 
> The code I provided works as advertised.
> 
> HTH,
> 
> Chuck
> 
> p.s. I am using Org mode version 9.2 (release_9.2-193-ge7901c...

Chuck,

Thanks for the help. I seem to have had a problem that crept into the code sometime in the past month or so, was true at least as of version 9.1.14, but now works as you described in version 9.2, which I have now installed. I had thought I was working with the current released version, but I was apparently wrong about that.

I appreciate the help, and sorry for the trouble.

Best,

Win