From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: patch for custom colored links in org-mode Date: Sat, 02 Jul 2016 01:20:42 +0200 Message-ID: <87a8i1gd2t.fsf@saiph.selenimh> References: <87twgdxtfm.fsf@saiph.selenimh> <87lh1pazj9.fsf@gmx.us> <877fd9xecw.fsf@saiph.selenimh> <87eg7dikr9.fsf@saiph.selenimh> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50094) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJ7jv-0007q2-NY for emacs-orgmode@gnu.org; Fri, 01 Jul 2016 19:20:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bJ7ju-0004it-AB for emacs-orgmode@gnu.org; Fri, 01 Jul 2016 19:20:51 -0400 Received: from relay3-d.mail.gandi.net ([2001:4b98:c:538::195]:55090) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJ7ju-0004il-48 for emacs-orgmode@gnu.org; Fri, 01 Jul 2016 19:20:50 -0400 In-Reply-To: (John Kitchin's message of "Fri, 01 Jul 2016 13:20:29 -0400") 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: John Kitchin Cc: "emacs-orgmode@gnu.org" , Rasmus 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 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,