From mboxrd@z Thu Jan 1 00:00:00 1970 From: tsd@tsdye.com (Thomas S. Dye) Subject: Re: [RFC] Standardized code block keywords Date: Fri, 21 Oct 2011 08:02:46 -1000 Message-ID: References: <87pqhrih3s.fsf@gmail.com> <30891.1319141196@alphaville.dokosmarshall.org> <87fwinifqu.fsf@gmail.com> <32184.1319143892@alphaville.dokosmarshall.org> <808vofwf1w.fsf@somewhere.org> <87y5wfgwn7.fsf_-_@gmail.com> <878voe71fl.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([140.186.70.92]:50970) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHJQl-0000Vk-L5 for emacs-orgmode@gnu.org; Fri, 21 Oct 2011 14:02:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RHJQk-00045x-73 for emacs-orgmode@gnu.org; Fri, 21 Oct 2011 14:02:55 -0400 Received: from oproxy4-pub.bluehost.com ([69.89.21.11]:58339) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1RHJQj-00045p-U7 for emacs-orgmode@gnu.org; Fri, 21 Oct 2011 14:02:54 -0400 In-Reply-To: <878voe71fl.fsf@gmail.com> (Eric Schulte's message of "Fri, 21 Oct 2011 10:05:25 -0600") 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: Eric Schulte Cc: Sebastien Vauban , emacs-orgmode@gnu.org Eric Schulte writes: > tsd@tsdye.com (Thomas S. Dye) writes: > >> Eric Schulte writes: >> >>>> [1] I have the same "annoying" feelings with #+SOURCE, #+SRCNAME, #+FUNCTION, >>>> #+CALL, #+LOB, and SBE, some of which are interchangeable; some >>>> not. I'd prefer >>>> deprecating an old form when a better one is found. >>> >>> This point of view has been raised previously both on the mailing list >>> and in the #org-mode IRC chat room. I think it is time that we decided >>> as a community what we want to do about the prevalence of code block >>> synonyms -- we should make this decision before the release of Emacs24 >>> after which syntax will become harder to change. >>> >>> There are currently a number of instances of synonymous keywords when >>> dealing with code blocks, specifically. >>> >>> named code blocks [1] -- "source" "srcname" "function" >>> calling external functions [2] -- "call" "lob" >>> named data [3] -- "tblname" "resname" "results" "data" >>> >>> Ideally if we limit each of the above to only one alternative we could >>> simplify the specification of code blocks in Org-mode making them easier >>> to learn and use and removing some of the mystery around their syntax. >>> >>> What does everyone think? >>> >>> Are there suggestions for the best names for each code block entity >>> (either in the list or not in the list)? >>> >>> Are there cases where we want to continue to allow synonyms (e.g., in >>> named data so that "results" can be used for code block results but >>> "data" can be used for hand-written data)? >>> >>> Thanks -- Eric >>> >>> Footnotes: >>> [1] named code blocks >>> >>> #+source: foo >>> #+begin_src emacs-lisp >>> 'foo >>> #+end_src >>> >>> #+srcname: foo >>> #+begin_src emacs-lisp >>> 'foo >>> #+end_src >>> >>> #+function: foo >>> #+begin_src emacs-lisp >>> 'foo >>> #+end_src >>> >>> [2] calling external functions >>> >>> #+call: foo() >>> >>> #+lob: foo() >>> >>> [3] named data >>> >>> #+data: something >>> : something >>> #+results: something >>> : something >>> >>> etc... >> >> Hi Eric, >> >> named code blocks [1] "source" >> calling external functions [2] "call" >> named data [3] "object" >> > > Noted, thanks, your choices for 1 and 2 are my favorite as well. > >> >> My motivation for [3] "object" instead of the suggested alternates is >> the hope that it will be possible to name things like lists and >> paragraphs (that aren't results or data) and pass these objects to >> source code blocks. >> > > I would say that I would consider paragraphs and lists to be "data" as > well, but I think object is a fine alternative. Also, lists are already > a supported data type. > > #+data: something > - 1 > - 2 > - 3 > > #+begin_src emacs-lisp :var it=something :results list > (reverse it) > #+end_src > > #+results: > - 3 > - 2 > - 1 > > Thanks for sharing -- Eric > >> >> All the best, >> Tom Hi Eric, Let me help revise the documentation when the dust settles and the syntax changes are in place. As it stands now, #+data: doesn't show up in the index to the manual, and the entry for #+tblname: leads only to a description of its use in spreadsheets. I should have known lists are already supported. Great work! All the best, Tom -- Thomas S. Dye http://www.tsdye.com