[Top][All Lists]

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

Re: [O] patch for custom colored links in org-mode

From: John Kitchin
Subject: Re: [O] patch for custom colored links in org-mode
Date: Sun, 03 Jul 2016 16:57:28 -0400
User-agent: mu4e 0.9.16; emacs

Nicolas Goaziou writes:

> John Kitchin <address@hidden> 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
               (setf (cl-getf
                      (cdr (assoc type org-link-parameters))
    (push `(list ,type ,@parameters) org-link-parameters))


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

reply via email to

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