Nicolas Goaziou writes:
> John Kitchin <jkitc...@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
