[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] links-9.0 v3

From: John Kitchin
Subject: Re: [O] links-9.0 v3
Date: Thu, 07 Jul 2016 09:27:03 -0400
User-agent: mu4e 0.9.16; emacs

> That's great. I realized there's one gotcha left.
>>                (let* ((option (org-element-property :search-option link))
>>                       (app (org-element-property :application link))
>>                       (dedicated-function
>> -                      (nth 1 (assoc app org-link-protocols))))
>> +                      (org-link-get-parameter type :follow)))
>>                  (if dedicated-function
> Here is the gotcha. `type' is "file", not "file+sys" or "file+emacs",
> so, when checking `dedicated-function' first, we cannot tell the
> difference between "file+sys" and "file+emacs".

I don't follow this. Why can't these be three types? They
define 3 different follow actions right? Those are basically equal to
pressing RET, C-u RET and C-u C-u RET on a link. We could just define
three :follow functions, and one :export function for them.

With the patches I sent, the three types actually work as they used to,
e.g. file:some.pptx opens the powerpoint file in emacs (not convenient
;), file+sys:some.pptx opens it in powerpoint. This seems to be because
org-element-context (via org-element-link-parser) sees file+sys and
file+emacs as a file type.

Overall, this is an inconsistency to me. On one hand, we need file+sys
and file+emacs in org-link-parameters so that they are built into the
link regexps (or they would have to be hard-coded in the function that
makes the regexp. E.g. (cons "coderef" (org-link-types)) is already done
that way for some reason). On the other hand, the org-open-at-point
function bypasses the link properties, so it is not possible to change
the :follow function for file+sys and file+emacs.

> One solution is to swap the logic order. First, if app is non-nil, we
> use it. If it isn't, we look after `dedicated-function'.
> Another solution is to add an optional parameter to the signature of
> the :follow function, which would be the "app" (e.g. "emacs", "sys",
> "docview"...) to use. I tend to think this solution is slightly better,
> since it doesn't require to hard-code logic in `org-open-at-point'.

I am not crazy about this solution, since it only applies to one type of
link, and I can't see how to use it for other follow functions. It would be
better IMO to define :follow functions maybe like this:

"file" :follow #'org-open-at-point
"file+sys" :follow (lambda (_) (org-open-at-point '(4)))
"file+emacs" :follow (lambda (_) (org-open-at-point '(16)))

and make them be honored in org-open-at-point. Then we could eliminate
the logic code in org-open-at-point.

>>    (let ((data (assoc type org-link-parameters)))
>> -    (if data
>> -    (cl-loop for (key val) on parameters by #'cddr
>> -             do
>> -             (setf (cl-getf (cdr data) key)
>> -                   val))
>> +    (if data (setcdr data (org-combine-plists (cdr data) parameters))
>>        (push (cons type parameters) org-link-parameters)
>>        (org-make-link-regexps)
>>        (org-element-update-syntax))))
> This change can be merged with `org-link-set-parameters' definition.

I am not sure how to do that. It is like a hunk in one commit that I
want to move to another commit.

>> +(defcustom org-link-parameters
>> +  '(("http") ("https") ("ftp") ("mailto")
>> +    ("file" :complete 'org-file-complete-link)
>> +    ("file+emacs") ("file+sys")
>> +    ("news") ("shell") ("elisp")
>> +    ("doi") ("message") ("help"))
> See above about "file+emacs" and "file+sys", which are not valid types.

Those either need to be here for link regexps, or hard-coded somewhere
else though. Speaking of which, should coderef be a link type, so it can
be removed as a hard-coded string that I referenced above?

> Regards,

Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213

reply via email to

[Prev in Thread] Current Thread [Next in Thread]