bug#42483: 26.1: thing-at-point doesn't recognize org-link urls

bug#42483: 26.1: thing-at-point doesn't recognize org-link urls

[Boruch Baum]

One of the features of function `thing-at-point' is recognition of urls,
so I expected it to be able to recognize org-link urls, but that isn't
the case. Here's an example that when yanked into an org-mode buffer
will display the underlined text 'SageMathCell', and when performing `C-c
C-o' (M-x org-open-at-point) will correctly open the url link. However,
`(thing-at-point 'url)' and `(thing-at-point-url-at-point)' evaluate to
NIL.

   [[https://sagecell.sagemath.org/][SageMathCell]]

I was expecting function `thing-at-point-url-at-point' to check if the
mode was org-mode, and if so, to try something like the following

(defun shamelessly-plagiarized-from-org-open-at-point ()
  (interactive)
      (let* ((context
	      (org-element-lineage
	        (org-element-context) '(link) t))
	     (value (org-element-property :value context))
	     (type (org-element-property :type context))
	     (path (org-link-unescape (org-element-property :path context))))
  (message (concat type ":" path))))

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#42483: 26.1: thing-at-point doesn't recognize org-link urls

[Lars Ingebrigtsen]

Boruch Baum <boruch_baum@gmx.com> writes:

> One of the features of function `thing-at-point' is recognition of urls,
> so I expected it to be able to recognize org-link urls, but that isn't
> the case. Here's an example that when yanked into an org-mode buffer
> will display the underlined text 'SageMathCell', and when performing `C-c
> C-o' (M-x org-open-at-point) will correctly open the url link. However,
> `(thing-at-point 'url)' and `(thing-at-point-url-at-point)' evaluate to
> NIL.
>
>    [[https://sagecell.sagemath.org/][SageMathCell]]
>
> I was expecting function `thing-at-point-url-at-point' to check if the
> mode was org-mode, and if so, to try something like the following
>
> (defun shamelessly-plagiarized-from-org-open-at-point ()
>   (interactive)
>       (let* ((context
> 	      (org-element-lineage
> 	        (org-element-context) '(link) t))
> 	     (value (org-element-property :value context))
> 	     (type (org-element-property :type context))
> 	     (path (org-link-unescape (org-element-property :path context))))
>   (message (concat type ":" path))))

This sounds like something that belongs in org, though, and not in
thingatpt.el, though.  Unfortunately, thing-at-point doesn't have a
mode-based model for working...  but it could grow one?  That is, there
could be a buffer-local thing-at-point-local-things, and Org could set
that to

((url . org--org-url-at-point))

or something like that.

Any opinions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#42483: 26.1: thing-at-point doesn't recognize org-link urls

[Jose A. Ortega Ruiz]

On Fri, Jan 22 2021, Lars Ingebrigtsen wrote:

[...]

> This sounds like something that belongs in org, though, and not in
> thingatpt.el, though.  Unfortunately, thing-at-point doesn't have a
> mode-based model for working...  but it could grow one?  That is, there
> could be a buffer-local thing-at-point-local-things, and Org could set
> that to
>
> ((url . org--org-url-at-point))
>
> or something like that.
>
> Any opinions?

Another context in which something like this could be useful is
emacs-w3m buffers, which are naturally full of links stored in text
properties (or eww, i am guessing).

A strategy i've seen elsewhere (in the embark package) for something
similar is to keep a list of "target finders" that are applied in turn,
until one succeeds returning, say, '(url . "http://foo/bar").  That's
essentially what you're suggesting above, except that one can write
global detectors (the list is not (necessarily) buffer local)

Just an idea,
jao
-- 
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare. - Blair Houghton.

bug#42483: 26.1: thing-at-point doesn't recognize org-link urls

[Lars Ingebrigtsen]

"Jose A. Ortega Ruiz" <jao@gnu.org> writes:

> Another context in which something like this could be useful is
> emacs-w3m buffers, which are naturally full of links stored in text
> properties (or eww, i am guessing).

Yes, that's true -- it would certainly be nice if `(thing-at-point 'url)' 
worked in eww buffers (which it currently doesn't).

> A strategy i've seen elsewhere (in the embark package) for something
> similar is to keep a list of "target finders" that are applied in turn,
> until one succeeds returning, say, '(url . "http://foo/bar").  That's
> essentially what you're suggesting above, except that one can write
> global detectors (the list is not (necessarily) buffer local)

Yup.  Adding this sort of framework to thingatpt looks pretty trivial,
and sounds generally useful, so I'll take a stab at it (using eww as the
first test case).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#42483: 26.1: thing-at-point doesn't recognize org-link urls

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yup.  Adding this sort of framework to thingatpt looks pretty trivial,
> and sounds generally useful, so I'll take a stab at it (using eww as the
> first test case).

Now done, so I guess it's up to Org now to use the mechanism.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#42483: 26.1: thing-at-point doesn't recognize org-link urls

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> Yup.  Adding this sort of framework to thingatpt looks pretty trivial,
>> and sounds generally useful, so I'll take a stab at it (using eww as the
>> first test case).
>
> Now done, so I guess it's up to Org now to use the mechanism.

I've now added Kyle to the CCs; perhaps he has some comments.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#42483: 26.1: thing-at-point doesn't recognize org-link urls

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>>> Yup.  Adding this sort of framework to thingatpt looks pretty trivial,
>>> and sounds generally useful, so I'll take a stab at it (using eww as the
>>> first test case).
>>
>> Now done, so I guess it's up to Org now to use the mechanism.
>
> I've now added Kyle to the CCs; perhaps he has some comments.

The remaining issues here (i.e., making Org use
`thing-at-point-provider-alist') are about org-mode, so I'm reassigning
this bug report to org-mode.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#42483: 26.1: thing-at-point doesn't recognize org-link urls

[jao]

On Sat, Jan 23 2021, Lars Ingebrigtsen wrote:

>> A strategy i've seen elsewhere (in the embark package) for something
>> similar is to keep a list of "target finders" that are applied in turn,
>> until one succeeds returning, say, '(url . "http://foo/bar").  That's
>> essentially what you're suggesting above, except that one can write
>> global detectors (the list is not (necessarily) buffer local)
>
> Yup.  Adding this sort of framework to thingatpt looks pretty trivial,
> and sounds generally useful, so I'll take a stab at it (using eww as the
> first test case).

Excelent, thanks a lot.  I am not sure whether thing-at-point already
has that, but it'd then be useful to be able to retrieve, together with
the thing-at-point, its category (and even also have a thing/s/-at-point
returning all detected things).  

With that metadata available, there's a just a very easy step to have
"actions at point": one could associate to each possible thing at point
type a keymap, and then have a command that retrieves the thing at point
and, for instance, activates that keymap.  Or associate a function
taking the thing at point and doing whatever one wishes.

(For instance, i have a video-url-at-point detector which looks for urls
that are from a video streaming platform, and associate to it actions
that let me play it with vlc or mpv, besides opening them in emacs-w3m,
ewww or firefox, as with other url).

I'm again stealing from embark's ideas, but for a really concise yet
already very useful take on this kind of "do-at-point" functionality,
see https://github.com/jyp/dap (GPL3, just around 200 loc).

Cheers,
jao
-- 
Don't be yourself. Be someone a little nicer.
  -Mignon McLaughlin, journalist and author (1913-1983)

bug#42483: 26.1: thing-at-point doesn't recognize org-link urls

[Lars Ingebrigtsen]

jao <jao@gnu.org> writes:

> Excelent, thanks a lot.  I am not sure whether thing-at-point already
> has that, but it'd then be useful to be able to retrieve, together with
> the thing-at-point, its category (and even also have a thing/s/-at-point
> returning all detected things).  

I'm not sure I follow you here -- you call thing at point with the
category (or "thing", as thingatpt calls it) as the parameter:

(thing-at-point 'url)

thingatpt doesn't try to guess at what type of thing exists under point,
just what the thing is.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#42483: 26.1: thing-at-point doesn't recognize org-link urls

[jao]

On Tue, Jan 26 2021, Lars Ingebrigtsen wrote:

> jao <jao@gnu.org> writes:
>
>> Excelent, thanks a lot.  I am not sure whether thing-at-point already
>> has that, but it'd then be useful to be able to retrieve, together with
>> the thing-at-point, its category (and even also have a thing/s/-at-point
>> returning all detected things).
>
> I'm not sure I follow you here -- you call thing at point with the
> category (or "thing", as thingatpt calls it) as the parameter:
>
> (thing-at-point 'url)
>
> thingatpt doesn't try to guess at what type of thing exists under point,
> just what the thing is.

yes.  i was imagining a convenience funtion, say `anything-at-point',
that would check in turn for possible things for me, and return, for
instance '(url . "http://www.gnu.org"). 

or perhaps simply having a function, say `things-at-point', returning
the list of symbols that denote possible things at point would be good
enough for the use case i'm imagining (dispatching actions on the thing
at point, whatever it is, based on its type).

bug#42483: 26.1: thing-at-point doesn't recognize org-link urls

[Lars Ingebrigtsen]

jao <jao@gnu.org> writes:

> yes.  i was imagining a convenience funtion, say `anything-at-point',
> that would check in turn for possible things for me, and return, for
> instance '(url . "http://www.gnu.org"). 

Sure, a package like that would be nice.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no