From: John Kitchin <johnrkitchin@gmail.com>
To: John Kitchin <jkitchin@andrew.cmu.edu>,
"emacs-orgmode@gnu org" <emacs-orgmode@gnu.org>,
Rasmus <rasmus@gmx.us>
Subject: Re: patch for custom colored links in org-mode
Date: Fri, 01 Jul 2016 20:51:11 -0400 [thread overview]
Message-ID: <qhkjpkaaiksqbfnswmxcukig.1467420671026@email.android.com> (raw)
If there is no urgency I will take a shot at it next week. I will look through the code and come up with a detailed plan that expands on your 4 steps below and be in touch about it. Thanks in advance for your patience 😉.
On July 1, 2016, at 7:20 PM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
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 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.
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,
next reply other threads:[~2016-07-02 0:51 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-02 0:51 John Kitchin [this message]
-- strict thread matches above, loose matches on Subject: below --
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
2016-06-29 0:44 ` John Kitchin
2016-06-30 11:58 ` Nicolas Goaziou
2016-06-30 17:44 ` 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=qhkjpkaaiksqbfnswmxcukig.1467420671026@email.android.com \
--to=johnrkitchin@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=jkitchin@andrew.cmu.edu \
--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).