From: John Kitchin <jkitchin@andrew.cmu.edu>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>, Rasmus <rasmus@gmx.us>
Subject: Re: patch for custom colored links in org-mode
Date: Sun, 03 Jul 2016 16:57:28 -0400 [thread overview]
Message-ID: <m2furq8mo7.fsf@Johns-MacBook-Air.local> (raw)
In-Reply-To: <87a8i1gd2t.fsf@saiph.selenimh>
Nicolas Goaziou writes:
> John Kitchin <jkitchin@andrew.cmu.edu> writes:
>
>> I agree, it doesn't make sense to use it for customization. OTOH, it
>> also adds the link type to org-link-types, rebuilds the regexp and the
>> org-link-protocols.
>
> It is possible to rebuild regexps upon modifying a defcustom.
Do you mean by some automatic method, e.g. a hook? Or by calling a function?
>
>> Do you think we would eliminate `org-link-types' and
>> `org-link-protocols' then? That would be fine with me.
>
> They would contain duplicate data, so they can be removed.
>
>> I think we might still want an org-add-link-type function though, if
>> there are additional things that need to be done after adding to
>> `org-link-type-parameters', e.g. updating regexps. It might even be
>> feasible to keep backward compatibility for code that already uses
>> this.
>
> We already have `org-make-link-regexp'. We can make it call
> `org-element-update-syntax' at its end, so as to become a replacement
> for `org-add-link-type'.
>
> Every customization of `org-link-parameters' would then call
> `org-make-link-regexp'. Users setting the variable by hand, or libraries
> defining new types, would be required to call it explicitly, though.
>
> I'm not sure about `org-add-link-type'. It introduces yet another way to
> configure link, but makes possible to eschew the `org-make-link-regexp'
> call. In any case, it needs to be kept around for
> backward-compatibility, but could also be marked as obsolete, pointing
> to `org-link-parameters' instead.
I am torn here. I thought we could extend org-add-link-type like this:
(cl-defun org-add-link-type (type &optional follow export
&key store complete face))
Which would maintain backward compatibility and provide a function
interface to add new links.
OTOH, a function like this could both add new links and set parameters
on existing links.
(defun org-link-set-parameters (type &rest parameters)
"Set link TYPE properties to PARAMETERS.
If TYPE is not an existing link, add it.
PARAMETERS should be :key val pairs."
(if (cdr (assoc type org-link-parameters))
(cl-loop for (key val) on parameters by #'cddr
do
(setf (cl-getf
(cdr (assoc type org-link-parameters))
key)
val))
(push `(list ,type ,@parameters) org-link-parameters))
Thoughts?
>
> WDYT?
>
>> Presumably we would then eliminate the "org-%s-complete-link"
>> functions?
>
> Indeed.
>
> I think it is possible to proceed in four steps.
>
> 1. First, we create the variable, with appropriate getter, setter and
> default values. At this point it is sufficient to
> support :follow, :export and :completion properties only.
>
> 2. Then we get all the code base to extract information about links
> through this variable instead of various existing ways, namely,
> `org-%s-complete-link', `org-link-protocols' and `org-link-types'.
>
> 3. Then we extend it with new properties, i.e., :display, :echo
> and :face.
>
> 4. Document the changes in the manual and ORG-NEWS file.
>
> You have mostly worked out the third part of the process. Do you want to
> take a stab at any of the other steps? Or do you prefer me to do some
> parts?
>
> 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-03 20:57 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-26 13:35 patch for custom colored links in org-mode John Kitchin
2016-06-27 12:52 ` Christian Wittern
2016-06-28 14:46 ` Nicolas Goaziou
2016-06-28 18:34 ` Thomas S. Dye
2016-06-28 19:23 ` Rasmus
2016-06-28 20:11 ` Nicolas Goaziou
2016-06-28 20:27 ` Rasmus
2016-06-28 20:44 ` John Kitchin
2016-07-01 23:23 ` Nicolas Goaziou
2016-07-06 11:25 ` Rasmus
2016-06-28 20:42 ` John Kitchin
2016-07-01 12:51 ` Nicolas Goaziou
2016-07-01 17:20 ` John Kitchin
2016-07-01 23:20 ` Nicolas Goaziou
2016-07-02 15:46 ` John Kitchin
2016-07-02 22:17 ` Nicolas Goaziou
2016-07-03 20:57 ` John Kitchin [this message]
2016-06-29 0:44 ` John Kitchin
2016-06-30 11:58 ` Nicolas Goaziou
2016-06-30 17:44 ` John Kitchin
-- strict thread matches above, loose matches on Subject: below --
2016-07-02 0:51 John Kitchin
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=m2furq8mo7.fsf@Johns-MacBook-Air.local \
--to=jkitchin@andrew.cmu.edu \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
--cc=rasmus@gmx.us \
/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).