patch for custom colored links in org-mode

patch for custom colored links in org-mode

[John Kitchin]

Hi all,

I tried this aproach to enable custom colored links in org-mode if an
org-link-type face is defined. If no face is applied, then it just gets
the default org-link face

For example this will make all doi links red.

(defface org-link-doi
  `((t (:inherit org-link
                 :foreground "red")))
  "Color for doi links.")

It seems to work pretty well for me. What do you think about making this
a feature in org-mode?

diff --git a/lisp/org.el b/lisp/org.el
index af68539..f1c500d 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5851,14 +5851,19 @@ prompted for."
   "Add link properties for plain links."
   (when (and (re-search-forward org-plain-link-re limit t)
             (not (org-in-src-block-p)))
-    (let ((face (get-text-property (max (1- (match-beginning 0)) (point-min))
-                                  'face))
-         (link (org-match-string-no-properties 0)))
+    (let* ((face (get-text-property (max (1- (match-beginning 0)) (point-min))
+                                   'face))
+          (link (org-match-string-no-properties 0))
+          (type (org-match-string-no-properties 1))
+          (link-face-symbol (intern (format "org-link-%s" type)))
+          (link-face (if (facep link-face-symbol)
+                         link-face-symbol
+                       'org-link)))
       (unless (if (consp face) (memq 'org-tag face) (eq 'org-tag face))
        (org-remove-flyspell-overlays-in (match-beginning 0) (match-end 0))
        (add-text-properties (match-beginning 0) (match-end 0)
                             (list 'mouse-face 'highlight
-                                  'face 'org-link
+                                  'face link-face
                                   'htmlize-link `(:uri ,link)
                                   'keymap org-mouse-map))
        (org-rear-nonsticky-at (match-end 0))
@@ -6340,8 +6345,8 @@ needs to be inserted at a specific position in the font-lock sequence.")
           ;; Links
           (if (memq 'tag lk) '(org-activate-tags (1 'org-tag prepend)))
           (if (memq 'angle lk) '(org-activate-angle-links (0 'org-link t)))
-          (if (memq 'plain lk) '(org-activate-plain-links (0 'org-link t)))
-          (if (memq 'bracket lk) '(org-activate-bracket-links (0 'org-link t)))
+          (if (memq 'plain lk) '(org-activate-plain-links (0 'org-link)))
+          (if (memq 'bracket lk) '(org-activate-bracket-links (0 'org-link)))
           (if (memq 'radio lk) '(org-activate-target-links (1 'org-link t)))
           (if (memq 'date lk) '(org-activate-dates (0 'org-date t)))
           (if (memq 'footnote lk) '(org-activate-footnote-links))


-- 
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

Re: patch for custom colored links in org-mode

[Christian Wittern]

Dear John,

I was wishing for this feature for a couple of years and would very much 
like for this to become possible! While I do not exactly understand how you 
are doing it, if it works that should be good enough.

Thanks a lot!

Christian

On 06/26/2016 10:35 PM, John Kitchin wrote:
> Hi all,
>
> I tried this aproach to enable custom colored links in org-mode if an
> org-link-type face is defined. If no face is applied, then it just gets
> the default org-link face
>
> For example this will make all doi links red.
>
> (defface org-link-doi
>    `((t (:inherit org-link
>                   :foreground "red")))
>    "Color for doi links.")
>
> It seems to work pretty well for me. What do you think about making this
> a feature in org-mode?
>
> diff --git a/lisp/org.el b/lisp/org.el
> index af68539..f1c500d 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -5851,14 +5851,19 @@ prompted for."
>     "Add link properties for plain links."
>     (when (and (re-search-forward org-plain-link-re limit t)
>               (not (org-in-src-block-p)))
> -    (let ((face (get-text-property (max (1- (match-beginning 0)) (point-min))
> -                                  'face))
> -         (link (org-match-string-no-properties 0)))
> +    (let* ((face (get-text-property (max (1- (match-beginning 0)) (point-min))
> +                                   'face))
> +          (link (org-match-string-no-properties 0))
> +          (type (org-match-string-no-properties 1))
> +          (link-face-symbol (intern (format "org-link-%s" type)))
> +          (link-face (if (facep link-face-symbol)
> +                         link-face-symbol
> +                       'org-link)))
>         (unless (if (consp face) (memq 'org-tag face) (eq 'org-tag face))
>          (org-remove-flyspell-overlays-in (match-beginning 0) (match-end 0))
>          (add-text-properties (match-beginning 0) (match-end 0)
>                               (list 'mouse-face 'highlight
> -                                  'face 'org-link
> +                                  'face link-face
>                                     'htmlize-link `(:uri ,link)
>                                     'keymap org-mouse-map))
>          (org-rear-nonsticky-at (match-end 0))
> @@ -6340,8 +6345,8 @@ needs to be inserted at a specific position in the font-lock sequence.")
>             ;; Links
>             (if (memq 'tag lk) '(org-activate-tags (1 'org-tag prepend)))
>             (if (memq 'angle lk) '(org-activate-angle-links (0 'org-link t)))
> -          (if (memq 'plain lk) '(org-activate-plain-links (0 'org-link t)))
> -          (if (memq 'bracket lk) '(org-activate-bracket-links (0 'org-link t)))
> +          (if (memq 'plain lk) '(org-activate-plain-links (0 'org-link)))
> +          (if (memq 'bracket lk) '(org-activate-bracket-links (0 'org-link)))
>             (if (memq 'radio lk) '(org-activate-target-links (1 'org-link t)))
>             (if (memq 'date lk) '(org-activate-dates (0 'org-date t)))
>             (if (memq 'footnote lk) '(org-activate-footnote-links))
>
>


-- 
Christian Wittern, Kyoto

Re: patch for custom colored links in org-mode

[Nicolas Goaziou]

Hello,

John Kitchin <jkitchin@andrew.cmu.edu> writes:

> I tried this aproach to enable custom colored links in org-mode if an
> org-link-type face is defined. If no face is applied, then it just gets
> the default org-link face
>
> For example this will make all doi links red.
>
> (defface org-link-doi
>   `((t (:inherit org-link
>                  :foreground "red")))
>   "Color for doi links.")
>
> It seems to work pretty well for me. What do you think about making this
> a feature in org-mode?

This sounds like a good idea. Thank you for submitting it.

However, I'm not convinced by the UI, i.e., creating a face specifically
named to trigger the feature. As a user, it doesn't seem very natural to
me.

At first I thought it was better to extend `org-add-link-type' with
a FACE definition, but we wouldn't have caught default link types.

So, maybe it is more reasonable to create a new variable, e.g.,
`org-link-display-parameters', which would hold an alist between link
types and property lists (or something else), e.g.,

  ("doi" :face my-special-face :display full)
  ("special" :display path)

Note that :display is a way to include your other idea about link
visibility. Default value for :face and :display would be, respectively,
`org-link' and `description'.

Of course, we can also create two variables, one for the face, the other
for the visibility.

WDYT?

Regards,

-- 
Nicolas Goaziou

Re: patch for custom colored links in org-mode

[Thomas S. Dye]

Nicolas Goaziou writes:

> Hello,
>
> John Kitchin <jkitchin@andrew.cmu.edu> writes:
>
>> I tried this aproach to enable custom colored links in org-mode if an
>> org-link-type face is defined. If no face is applied, then it just gets
>> the default org-link face
>>
>> For example this will make all doi links red.
>>
>> (defface org-link-doi
>>   `((t (:inherit org-link
>>                  :foreground "red")))
>>   "Color for doi links.")
>>
>> It seems to work pretty well for me. What do you think about making this
>> a feature in org-mode?
>
> This sounds like a good idea. Thank you for submitting it.
>
> However, I'm not convinced by the UI, i.e., creating a face specifically
> named to trigger the feature. As a user, it doesn't seem very natural to
> me.
>
> At first I thought it was better to extend `org-add-link-type' with
> a FACE definition, but we wouldn't have caught default link types.
>
> So, maybe it is more reasonable to create a new variable, e.g.,
> `org-link-display-parameters', which would hold an alist between link
> types and property lists (or something else), e.g.,
>
>   ("doi" :face my-special-face :display full)
>   ("special" :display path)
>
> Note that :display is a way to include your other idea about link
> visibility. Default value for :face and :display would be, respectively,
> `org-link' and `description'.
>
> Of course, we can also create two variables, one for the face, the other
> for the visibility.

Great idea.  Thanks to John and Nicolas for bringing it up.

A single variable seems sufficient to me and easier to configure.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: patch for custom colored links in org-mode

[Rasmus]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> However, I'm not convinced by the UI, i.e., creating a face specifically
> named to trigger the feature. As a user, it doesn't seem very natural to
> me.

Aside: This is what is done for specially colored source blocks.  But we
can change that UI if you think.

-- 
Send from my Emacs

Re: patch for custom colored links in org-mode

[Nicolas Goaziou]

Hello,

Rasmus <rasmus@gmx.us> writes:

> Aside: This is what is done for specially colored source blocks.

Duh. This totally eluded me.

> But we can change that UI if you think.

I think it would be nice to find a decent UI for that feature, indeed.
With that naming convention rule, you get neither docstring nor
customization UI.

Of course, this is documented in the manual, but very often, looking at
defcustoms in a library is of invaluable help.


Regards,

-- 
Nicolas Goaziou

Re: patch for custom colored links in org-mode

[Rasmus]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Rasmus <rasmus@gmx.us> writes:
>
>> Aside: This is what is done for specially colored source blocks.
>
> Duh. This totally eluded me.
>
>> But we can change that UI if you think.
>
> I think it would be nice to find a decent UI for that feature, indeed.
> With that naming convention rule, you get neither docstring nor
> customization UI.
>
> Of course, this is documented in the manual, but very often, looking at
> defcustoms in a library is of invaluable help.

Maybe a defcustom consisting of an alist of anonymous faces:

'((R ((:background "red")))
  (emacs-lisp ((:background "blue"))))


-- 
Need more coffee. . .

Re: patch for custom colored links in org-mode

[John Kitchin]

That is also nice looking.


Rasmus writes:

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> Hello,
>>
>> Rasmus <rasmus@gmx.us> writes:
>>
>>> Aside: This is what is done for specially colored source blocks.
>>
>> Duh. This totally eluded me.
>>
>>> But we can change that UI if you think.
>>
>> I think it would be nice to find a decent UI for that feature, indeed.
>> With that naming convention rule, you get neither docstring nor
>> customization UI.
>>
>> Of course, this is documented in the manual, but very often, looking at
>> defcustoms in a library is of invaluable help.
>
> Maybe a defcustom consisting of an alist of anonymous faces:
>
> '((R ((:background "red")))
>   (emacs-lisp ((:background "blue"))))


-- 
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

Re: patch for custom colored links in org-mode

[Nicolas Goaziou]

Hello,

Rasmus <rasmus@gmx.us> writes:

> Maybe a defcustom consisting of an alist of anonymous faces:
>
> '((R ((:background "red")))
>   (emacs-lisp ((:background "blue"))))

Sounds good, even if a string as the key might be better (languages are
stored as strings in the parse tree). Also why limit ourselves to
anonymous faces?

Regards,

-- 
Nicolas Goaziou

Re: patch for custom colored links in org-mode

[Rasmus]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Rasmus <rasmus@gmx.us> writes:
>
>> Maybe a defcustom consisting of an alist of anonymous faces:
>>
>> '((R ((:background "red")))
>>   (emacs-lisp ((:background "blue"))))
>
> Sounds good, even if a string as the key might be better (languages are
> stored as strings in the parse tree). Also why limit ourselves to
> anonymous faces?

I've changed it to take an anonymous face, a face or a color string which
then becomes the background.  I’ll just have to get the darn customize
interface working properly.

Rasmus

-- 
Vote for proprietary math!

Re: patch for custom colored links in org-mode

[John Kitchin]

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]

Indeed, I based this approach off a patch Rasmus posted some time ago for
colored blocks ;)

It is also similar to some other approaches in org-mode, e.g.
the "org-%s-complete-link" functions.

I am ok with a single variable that is an a-list that combines face and
display.

Would you consider expanding org-add-link-type like this to set those in
the special variable?

(org-add-link-type "somename" 'click-func 'export-func :face some-face
:display path)

You could always add them manually to the variable for links already
defined somewhere else.



John

-----------------------------------
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


On Tue, Jun 28, 2016 at 4:11 PM, Nicolas Goaziou <mail@nicolasgoaziou.fr>
wrote:

> Hello,
>
> Rasmus <rasmus@gmx.us> writes:
>
> > Aside: This is what is done for specially colored source blocks.
>
> Duh. This totally eluded me.
>
> > But we can change that UI if you think.
>
> I think it would be nice to find a decent UI for that feature, indeed.
> With that naming convention rule, you get neither docstring nor
> customization UI.
>
> Of course, this is documented in the manual, but very often, looking at
> defcustoms in a library is of invaluable help.
>
>
> Regards,
>
> --
> Nicolas Goaziou
>
>

[-- Attachment #2: Type: text/html, Size: 2357 bytes --]

Re: patch for custom colored links in org-mode

[Nicolas Goaziou]

Hello,

John Kitchin <jkitchin@andrew.cmu.edu> writes:

> Indeed, I based this approach off a patch Rasmus posted some time ago for
> colored blocks ;)
>
> It is also similar to some other approaches in org-mode, e.g.
> the "org-%s-complete-link" functions.

This is yet another obscure part of Org, IMO. I really think we need to
normalize link customization, for an improved user experience.

> Would you consider expanding org-add-link-type like this to set those in
> the special variable?

I don't like much `org-add-link-type' because, it inherently only
operates on additional link types, so it is not sufficient to handle all
customization needs. I'd rather have a single way to control link
behaviour.

I think we could rename `org-link-display-parameters' into
`org-link-type-parameters' and control links from that location. More
explicitly, the value for a given link type (string) could be a plist
with the following properties
- :follow
- :export
- :face
- :display
- :completion
- :echo

The value would contain every link type, including internal ones. Its
value would probably be daunting at first (compared, e.g., with
a boolean) but it would give full control over links.

WDYT?


Regards,

-- 
Nicolas Goaziou

Re: patch for custom colored links in org-mode

[John Kitchin]

+1 for all this.

Nicolas Goaziou writes:

> Hello,
>
> John Kitchin <jkitchin@andrew.cmu.edu> writes:
>
>> Indeed, I based this approach off a patch Rasmus posted some time ago for
>> colored blocks ;)
>>
>> It is also similar to some other approaches in org-mode, e.g.
>> the "org-%s-complete-link" functions.
>
> This is yet another obscure part of Org, IMO. I really think we need to
> normalize link customization, for an improved user experience.
>
>> Would you consider expanding org-add-link-type like this to set those in
>> the special variable?
>
> I don't like much `org-add-link-type' because, it inherently only
> operates on additional link types, so it is not sufficient to handle all
> customization needs. I'd rather have a single way to control link
> behaviour.

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.

Do you think we would eliminate `org-link-types' and
`org-link-protocols' then? That would be fine with me.

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.

Presumably we would then eliminate the "org-%s-complete-link" functions?
There don't seem to be many (not including the auto-generated org-ref
related ones ;)

>
> I think we could rename `org-link-display-parameters' into
> `org-link-type-parameters' and control links from that location. More
> explicitly, the value for a given link type (string) could be a plist
> with the following properties
> - :follow
> - :export
> - :face
> - :display
> - :completion
> - :echo
>
> The value would contain every link type, including internal ones. Its
> value would probably be daunting at first (compared, e.g., with
> a boolean) but it would give full control over links.

I like it.

>
> WDYT?
>
>
> 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

Re: patch for custom colored links in org-mode

[Nicolas Goaziou]

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,

Re: patch for custom colored links in org-mode

[John Kitchin]

>
> 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.

Would it make sense to use a defstruct for the link? Then we get getters
and setters automatically. We would still use an a-list of ("type"
org-link-struct). I see defstruct is an alias for cl-defstruct, does
that have Emacs version implications?

E.g.

#+BEGIN_SRC emacs-lisp
(defstruct org-link  follow export completion face display echo)
#+END_SRC

#+RESULTS:
: org-link

A getter:

#+BEGIN_SRC emacs-lisp
(let ((new-link (make-org-link :follow nil :face '(:background "red"))))
  (org-link-face new-link))
#+END_SRC

#+RESULTS:
| :background | red |

A setter:

#+BEGIN_SRC emacs-lisp
(let ((new-link (make-org-link :follow nil :face '(:background "red"))))
  (setf (org-link-face new-link) '(:background "blue"))
  (org-link-face new-link))
#+END_SRC

#+RESULTS:
| :background | blue |

To get the follow property on a link it would look like:

(org-link-follow (cdr (assoc "type" org-link-parameters)))

It isn't that different from this:

(plist-get (cdr (assoc "type" org-link-parameters)) :follow)

and I suppose it might be nice to have

(org-link--get "type" :follow) instead.

WDYT?


> 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

Re: patch for custom colored links in org-mode

[Nicolas Goaziou]

Hello,

John Kitchin <jkitchin@andrew.cmu.edu> writes:

> Would it make sense to use a defstruct for the link?

I thought about that. Unfortunately, defstructs are not customize
friendly. If we are going to give direct access to
`org-link-parameters', i.e., make it a defcustom, this is not an option.

> Then we get getters and setters automatically. We would still use an
> a-list of ("type" org-link-struct). I see defstruct is an alias for
> cl-defstruct, does that have Emacs version implications?

Org 9.0 minimal requirement is Emacs 24.3, so "cl-lib" is fine.

> To get the follow property on a link it would look like:
>
> (org-link-follow (cdr (assoc "type" org-link-parameters)))
>
> It isn't that different from this:
>
> (plist-get (cdr (assoc "type" org-link-parameters)) :follow)

This is not very different, but the value you are manipulating is
slightly more opaque in the first case.

> and I suppose it might be nice to have
>
> (org-link--get "type" :follow) instead.

`org-link-get-parameter' and `org-link-set-parameter', or some such. We
should make them public.

> WDYT?

As I said above, if `org-link-parameters' is a defcustom, we need to use
a plist. This is, however, not mandatory.

Indeed, we can also treat `org-link--parameters' as an internal variable
and force users, and libraries, to manipulate these parameters only
through a set of functions (e.g., `org-link-get-parameter',
`org-link-set-parameter', `org-link-add-parameters' and
`org-link-show-parameters').

Nevertheless, I tend to think the former is clearer for users, simply
because plists are simpler to grasp than structs. OTOH, /you/ are
customizing links and I'm not, so your opinion on the subject is
probably more accurate.


Regards,

-- 
Nicolas Goaziou

Re: patch for custom colored links in org-mode

[John Kitchin]

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

Re: patch for custom colored links in org-mode

[John Kitchin]

I took a stab at this implementation here:

https://github.com/jkitchin/org-mode/compare/master...colored-link-2?expand=1

I wasn't too sure of the defcustom :type syntax.

I also wasn't sure about this line
https://github.com/jkitchin/org-mode/compare/master...colored-link-2?expand=1#diff-cfe1a32c56525d13db03755dbd7b4a01R6069

I set the invisible spec to whatever you set :display to, or 'org-link.
However, if you set :display to t, it still gets folded. I thought any
non-nil value that wasn't 'org-link would work, but apparently not.

What do you think about this?

With that patch, you can do this:

Run this to set the display of doi links
#+BEGIN_SRC emacs-lisp
(setq org-link-display-parameters
 '(("doi"  :face (:foreground "red" :underline t :weight bold) :display 'full)))
#+END_SRC

And then the doi links are bold, underlined red, and not folded in
descriptive mode.

  doi:10.1021

 bracketed:  [[doi:test][what]]                             
 bracketed file link: [[file:test.org][test]]



Nicolas Goaziou writes:

> Hello,
>
> John Kitchin <jkitchin@andrew.cmu.edu> writes:
>
>> I tried this aproach to enable custom colored links in org-mode if an
>> org-link-type face is defined. If no face is applied, then it just gets
>> the default org-link face
>>
>> For example this will make all doi links red.
>>
>> (defface org-link-doi
>>   `((t (:inherit org-link
>>                  :foreground "red")))
>>   "Color for doi links.")
>>
>> It seems to work pretty well for me. What do you think about making this
>> a feature in org-mode?
>
> This sounds like a good idea. Thank you for submitting it.
>
> However, I'm not convinced by the UI, i.e., creating a face specifically
> named to trigger the feature. As a user, it doesn't seem very natural to
> me.
>
> At first I thought it was better to extend `org-add-link-type' with
> a FACE definition, but we wouldn't have caught default link types.
>
> So, maybe it is more reasonable to create a new variable, e.g.,
> `org-link-display-parameters', which would hold an alist between link
> types and property lists (or something else), e.g.,
>
>   ("doi" :face my-special-face :display full)
>   ("special" :display path)
>
> Note that :display is a way to include your other idea about link
> visibility. Default value for :face and :display would be, respectively,
> `org-link' and `description'.
>
> Of course, we can also create two variables, one for the face, the other
> for the visibility.
>
> WDYT?
>
> 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

Re: patch for custom colored links in org-mode

[Nicolas Goaziou]

Hello,

John Kitchin <jkitchin@andrew.cmu.edu> writes:

> I took a stab at this implementation here:
>
> https://github.com/jkitchin/org-mode/compare/master...colored-link-2?expand=1

Thank you.

Could you send the patch on the ML instead? It is better for commenting
and archiving. Also make sure to patch against master branch (e.g.
`org-match-string-no-properties' -> 'match-string-no-properties').


Regards,

-- 
Nicolas Goaziou

Re: patch for custom colored links in org-mode

[John Kitchin]

[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

I think I have attached the right patch that does this.

Let me know what you think.

Nicolas Goaziou writes:

> Hello,
>
> John Kitchin <jkitchin@andrew.cmu.edu> writes:
>
>> I took a stab at this implementation here:
>>
>> https://github.com/jkitchin/org-mode/compare/master...colored-link-2?expand=1
>
> Thank you.
>
> Could you send the patch on the ML instead? It is better for commenting
> and archiving. Also make sure to patch against master branch (e.g.
> `org-match-string-no-properties' -> 'match-string-no-properties').
>
>
> 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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: colored-link.patch --]
[-- Type: text/x-patch, Size: 2929 bytes --]

diff --git a/lisp/org.el b/lisp/org.el
index 89b72bc..48b6748 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -1867,6 +1867,18 @@ return the description to use."
   :tag "Org Store Link"
   :group 'org-link)
 
+(defcustom org-link-display-parameters nil 
+  "An alist of properties to display a link with.
+The first element in each list is a string of the link
+type. Subsequent optional elements make up a p-list. :face can be
+used to change the face on the link (the default is
+`org-link'. If :display is 'full the full link will show in
+descriptive link mode."
+  :type '(alist :tag "Link display paramters"
+		:key-type 'string
+		:value-type '(plist))
+  :group 'org-link)
+
 (defcustom org-url-hexify-p t
   "When non-nil, hexify URL when creating a link."
   :type 'boolean
@@ -5864,14 +5876,19 @@ prompted for."
   "Add link properties for plain links."
   (when (and (re-search-forward org-plain-link-re limit t)
 	     (not (org-in-src-block-p)))
+
     (let ((face (get-text-property (max (1- (match-beginning 0)) (point-min))
 				   'face))
-	  (link (match-string-no-properties 0)))
+	  (link (match-string-no-properties 0))
+	  (type (match-string-no-properties 1)))
       (unless (if (consp face) (memq 'org-tag face) (eq 'org-tag face))
 	(org-remove-flyspell-overlays-in (match-beginning 0) (match-end 0))
 	(add-text-properties (match-beginning 0) (match-end 0)
 			     (list 'mouse-face 'highlight
-				   'face 'org-link
+				   'face (or (plist-get
+					      (cdr (assoc type org-link-display-parameters))
+					      :face)
+					     'org-link)
 				   'htmlize-link `(:uri ,link)
 				   'keymap org-mouse-map))
 	(org-rear-nonsticky-at (match-end 0))
@@ -6065,7 +6082,10 @@ by a #."
 	     (not (org-in-src-block-p)))
     (let* ((hl (match-string-no-properties 1))
 	   (help (concat "LINK: " (save-match-data (org-link-unescape hl))))
-	   (ip (list 'invisible 'org-link
+	   (ip (list 'invisible (or (plist-get
+				     (cdr (assoc type org-link-display-parameters))
+				     :display)
+				    'org-link)
 		     'keymap org-mouse-map 'mouse-face 'highlight
 		     'font-lock-multiline t 'help-echo help
 		     'htmlize-link `(:uri ,hl)))
@@ -6362,8 +6382,8 @@ needs to be inserted at a specific position in the font-lock sequence.")
 	   ;; Links
 	   (when (memq 'tag lk) '(org-activate-tags (1 'org-tag prepend)))
 	   (when (memq 'angle lk) '(org-activate-angle-links (0 'org-link t)))
-	   (when (memq 'plain lk) '(org-activate-plain-links (0 'org-link t)))
-	   (when (memq 'bracket lk) '(org-activate-bracket-links (0 'org-link t)))
+	   (when (memq 'plain lk) '(org-activate-plain-links (0 'org-link)))
+	   (when (memq 'bracket lk) '(org-activate-bracket-links (0 'org-link)))
 	   (when (memq 'radio lk) '(org-activate-target-links (1 'org-link t)))
 	   (when (memq 'date lk) '(org-activate-dates (0 'org-date t)))
 	   (when (memq 'footnote lk) '(org-activate-footnote-links))

Re: patch for custom colored links in org-mode

[John Kitchin]

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,