From: John Kitchin <jkitchin@andrew.cmu.edu>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: links-9.0 v3
Date: Thu, 07 Jul 2016 09:27:03 -0400 [thread overview]
Message-ID: <m2shvllgt4.fsf@Johns-MacBook-Air.local> (raw)
In-Reply-To: <87k2gxg8qm.fsf@saiph.selenimh>
>
> 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'.
>
> WDYT?
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
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
next prev parent reply other threads:[~2016-07-07 13:27 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-06 14:41 links-9.0 v3 John Kitchin
2016-07-06 22:10 ` Nicolas Goaziou
2016-07-06 23:06 ` John Kitchin
2016-07-07 1:55 ` John Kitchin
2016-07-07 8:20 ` Nicolas Goaziou
2016-07-07 13:27 ` John Kitchin [this message]
2016-07-07 14:56 ` Nicolas Goaziou
2016-07-07 19:17 ` John Kitchin
2016-07-08 21:32 ` Nicolas Goaziou
2016-07-07 19:21 ` John Kitchin
2016-07-08 21:48 ` Nicolas Goaziou
2016-07-08 22:04 ` John Kitchin
2016-07-09 13:27 ` John Kitchin
2016-07-18 12:02 ` Nicolas Goaziou
2016-07-15 1:12 ` John Kitchin
2016-07-18 11:48 ` Nicolas Goaziou
2016-07-18 15:20 ` John Kitchin
2016-07-18 16:05 ` Nicolas Goaziou
2016-07-18 16:55 ` John Kitchin
2016-07-18 21:59 ` Nicolas Goaziou
2016-07-18 23:37 ` John Kitchin
2016-08-06 1:14 ` [PATCH] " Matt Lundin
2016-08-08 0:12 ` John Kitchin
2016-08-08 5:30 ` Robert Klein
2016-08-08 9:21 ` Nicolas Goaziou
2016-08-08 9:08 ` Nicolas Goaziou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2shvllgt4.fsf@Johns-MacBook-Air.local \
--to=jkitchin@andrew.cmu.edu \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).