From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Kitchin Subject: Re: patch for custom colored links in org-mode Date: Sun, 03 Jul 2016 16:57:28 -0400 Message-ID: References: <87twgdxtfm.fsf@saiph.selenimh> <87lh1pazj9.fsf@gmx.us> <877fd9xecw.fsf@saiph.selenimh> <87eg7dikr9.fsf@saiph.selenimh> <87a8i1gd2t.fsf@saiph.selenimh> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54277) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJoSX-0002yb-5Q for emacs-orgmode@gnu.org; Sun, 03 Jul 2016 16:57:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bJoSS-0007AD-T9 for emacs-orgmode@gnu.org; Sun, 03 Jul 2016 16:57:44 -0400 Received: from mail-qk0-x22b.google.com ([2607:f8b0:400d:c09::22b]:33305) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJoSS-0007A5-Mw for emacs-orgmode@gnu.org; Sun, 03 Jul 2016 16:57:40 -0400 Received: by mail-qk0-x22b.google.com with SMTP id e3so51228797qkd.0 for ; Sun, 03 Jul 2016 13:57:40 -0700 (PDT) In-reply-to: <87a8i1gd2t.fsf@saiph.selenimh> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Nicolas Goaziou Cc: "emacs-orgmode@gnu.org" , Rasmus Nicolas Goaziou writes: > John Kitchin 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