From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: problems with export and :cache Date: Thu, 29 Oct 2015 18:16:12 +0100 Message-ID: <87k2q5oasj.fsf@nicolasgoaziou.fr> References: <87vb9pyf0l.fsf@gmail.com> <871tcdpxeq.fsf@nicolasgoaziou.fr> <87io5pyaeo.fsf@gmail.com> <87wpu5occ0.fsf@nicolasgoaziou.fr> <87d1vxy5a6.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45383) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrqmT-0004pO-Ab for emacs-orgmode@gnu.org; Thu, 29 Oct 2015 13:14:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZrqmS-0004P5-E2 for emacs-orgmode@gnu.org; Thu, 29 Oct 2015 13:14:29 -0400 Received: from relay4-d.mail.gandi.net ([2001:4b98:c:538::196]:39314) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrqmS-0004Ox-6q for emacs-orgmode@gnu.org; Thu, 29 Oct 2015 13:14:28 -0400 In-Reply-To: <87d1vxy5a6.fsf@gmail.com> (Aaron Ecay's message of "Thu, 29 Oct 2015 17:05:05 +0000") 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-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Andreas Leha Cc: emacs-orgmode@gnu.org Aaron Ecay writes: > But users know that anyway, since it=E2=80=99s implied by the semantics of > :colname-names. Actually the most typical way of accessing the value > of :colname-names in the code is (cdr (assoc :colname-names params)) > (~20 uses, which ought to use assq instead); using o-b-get-header for > :colname-names is an exception. > > The issue is that o-b-g-h gives an API for accessing key-values in a > 1:many mapping. But :var is the only key that can actually be 1:many. > All other keys are singletons, and can be handled through the usual > emacs API for 1:1 mappings (assq and friends) =E2=80=93 and in the existi= ng > codebase they often are. If we provide an API within babel, we should > make it as specific as possible. Ideally, the API should be transparent to the internal representation of parameters used in Babel. Using `assq' means 1) you know that Babel internally uses alists for parameters 2) you hope it will do it forever. In any case, your suggestion is already better than the current situation in Babel. So I'm fine with it. It might not be optimal however. Regards,