From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: [RFC] Standardized code block keywords Date: Fri, 21 Oct 2011 10:24:12 -0600 Message-ID: <87lise5muh.fsf@gmail.com> 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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:34275) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHHzG-0007Sd-So for emacs-orgmode@gnu.org; Fri, 21 Oct 2011 12:30:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RHHz9-0008Gj-0H for emacs-orgmode@gnu.org; Fri, 21 Oct 2011 12:30:25 -0400 Received: from mail-gx0-f169.google.com ([209.85.161.169]:59485) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHHz8-0008Gf-Pe for emacs-orgmode@gnu.org; Fri, 21 Oct 2011 12:30:18 -0400 Received: by ggnh4 with SMTP id h4so4680012ggn.0 for ; Fri, 21 Oct 2011 09:30:18 -0700 (PDT) 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: Torsten Wagner Cc: Sebastien Vauban , emacs-orgmode@gnu.org > Just to make it as easy as possible for everyone.... > Might it be possible to introduce a small flags like "obsolete" and > "stable" (standard) > Old functions, old syntax, etc., might move first to obsolete before > completely removed... > We could open an older file and if it isn't working, we could try > > #+PROPERTY: babel-function-set obsolete > I think that making use of such a feature is almost as onerous as changing to the new terms (which is a simple search replace, in fact once terms are selected I'll happily share a function on list which can be used to convert all old terms in existing Org-mode files). > > if it works, we have to modify the code, because obviously the code > requires changed to be compatible in the future. However, just for the > moment it is still working. This would give people more time to change > there code accordingly. As murphy law tells us one will notice that > the particular file is broken exact 5 minutes before the meeting with > your boss standing behind you yelling.... print it, print it ;) > > I know git would be perfect to keep the code base frozen for a certain > syntax. However, babel is bundled with org-mode which is bundled with > Emacs. Thus, it might be very difficult to tell people they have to > use org-babel from git with the tag [org-babel_XX] if they want to use > there old style files. AFAIK org-babel does not even come with a own > version numbering, right? > > Alternatively, keep the syntax a little bit longer as it is and create > warning messages to point users to future changes (not sure how much > time left for emacs24) > "Warning: #+lob: in line XX is obsolete, please use #+call: in the > future. (manual-link)" > > To make is short, is is possible to introduce changes "slowly" > I fear this would simply serve to introduce more complexity and confusion. > > As for voting: > [1] > #+function: would be what I would expect from other programming > languages. Where an unnamed source code block would be something like > a lambda function. > However, "function" as a term is heavily used in many target languages > too. This makes parsing, reading and discussing a bit difficult. ("I > called the function foo", "Wait, do you call the org-mode function > foo, or the python function foo?") > Thus, I vote for #+srcname similar to #+tblname to make sure about the > difference between org-babel and the target languages. > > [2] > #+call:, simply because I never can remember "lob" and the acronym is > something difficult for newbies. > noted, thanks > > [3] > I tend to #+results: because it fits more to the entire babel syntax. > However, earlier on the mailing list people were pointing out that one > is going to change "results" for a unknown source block (that was the > reason "data" was introduced).... and I think this is a valid > argument. Maybe "data" and "results" should be both valid if only to > pleasure human thinking. However, if I understood correctly, maybe > data could be changed to be more some type of constant? That is, > #+data: foo can not be changed by a source code block named foo > (because it isn't a "result" but "data") but only by human (as a > "data" input). Does this make sense? > yes, I'll mark you down for "data and results", which I think is a perfectly fine option. Thanks for sharing -- Eric > > Totti > -- Eric Schulte http://cs.unm.edu/~eschulte/