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

[jao <jao@gnu.org>]

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)