[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] open link in source code block
From: |
Berry, Charles |
Subject: |
Re: [O] open link in source code block |
Date: |
Thu, 17 Jan 2019 18:38:58 +0000 |
> On Jan 16, 2019, at 3:43 PM, Win Treese <address@hidden> wrote:
>
> [Quoting trimmed for the most relevant context.]
>
>> On Jan 11, 2019, at 7:12 PM, Berry, Charles <address@hidden> wrote:
>>
>>> 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.
>
>>> 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...