From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rainer M Krug Subject: Re: [RFC] Standardized code block keywords Date: Tue, 25 Oct 2011 08:44:36 +0200 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> <87lise5muh.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=0016e6551eb275eb4c04b019df20 Return-path: Received: from eggs.gnu.org ([140.186.70.92]:54635) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIakZ-0007wG-Tp for emacs-orgmode@gnu.org; Tue, 25 Oct 2011 02:44:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RIakX-0005jv-FJ for emacs-orgmode@gnu.org; Tue, 25 Oct 2011 02:44:39 -0400 Received: from mail-qy0-f176.google.com ([209.85.216.176]:59655) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIakX-0005jr-93 for emacs-orgmode@gnu.org; Tue, 25 Oct 2011 02:44:37 -0400 Received: by qyk30 with SMTP id 30so138521qyk.0 for ; Mon, 24 Oct 2011 23:44:36 -0700 (PDT) In-Reply-To: <87lise5muh.fsf@gmail.com> 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 --0016e6551eb275eb4c04b019df20 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 21, 2011 at 6:24 PM, Eric Schulte wrote: > > 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). > The problem are not every-day users, but if one is not using org-mode not using for some time, it might be difficult to figure out what has changed - also, I wou't remember in three years time, that these things have changed, and run into problems when trying to open an old org-file (in the case of literae programming not unlikely). But I also see your point - Eric. Would it be an option to include a function which checks if these files do include the old / deprecated keywords, and inform the user? This function could even, in this case here, suggest to do the replacing. This function could be over time extended, whenever in-compatible changes become necessary - it would be a kind of an org-to-org converter or org-version-checker? Concerning voting: Definitely #+call. I don't like the #+srcname, because most of my blocks are not named, and it would look weired (I have never used #+tblname but if I also think that that looks weired if there is no name coming afterwards...). I would vote for: #+src #+object sounds more "modern" then data. Just an idea (): #+object_begin var x = 1 y = 2 #+end could possible be used for as an alternative for :var ? And the #+results should stay for generated data to keep them separate (will / can be programmatically changed) Cheers, Rainer > > > > > 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/ > > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D): +49 - (0)3 21 21 25 22 44 email: Rainer@krugs.de Skype: RMkrug --0016e6551eb275eb4c04b019df20 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Oct 21, 2011 at 6:24 PM, Eric Sc= hulte <schul= te.eric@gmail.com> wrote:
> Just to make it as easy as possible for everyone....=
> Might it be possible to introduce a small flags like "obsolete&qu= ot; 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<= br> >
> #+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).

The problem are not every-day users, but if one is not using or= g-mode not using for some time, it might be difficult to figure out what ha= s changed - also, I wou't remember in three years time, that these thin= gs have changed, and run into problems when trying to open an old org-file = (in the case of literae programming not unlikely).

But I also see your point - Eric.

Would it be an option to incl= ude a function which checks if these files do include the old / deprecated = keywords, and inform the user? This function could even, in this case here,= suggest to do the replacing. This function could be over time extended, wh= enever in-compatible changes become necessary - it would be a kind of an or= g-to-org converter or org-version-checker?


Concerning voting:

Definitely #+call.

I don't lik= e the #+srcname, because most of my blocks are not named, and it would look= weired (I have never used #+tblname but if I also think that that looks we= ired if there is no name coming afterwards...).

I would vote for:

#+src

#+object
sounds more "mod= ern" then data.

Just an idea ():

#+object_begin var
= =A0 x =3D 1
=A0 y =3D 2
#+end

could possible be used for as an= alternative for :var ?


And the #+results should stay for generated data to keep them separ= ate (will / can be programmatically changed)

Cheers,

Rainer=A0

>
> 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<= br> > your boss standing behind you yelling.... print it, print it =A0;)
>
> 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<= br> > 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. =A0AFAIK org-babel does not even come with a ow= n
> 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 th= e
> future. (manual-link)"
>
> To make is short, is is possible to introduce changes "slowly&quo= t;
>

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<= br> > 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. (&quo= t;I
> called the function foo", "Wait, do you call the org-mode fu= nction
> 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 a= cronym is
> something difficult for newbies.
>

noted, thanks

>
> [3]
> I tend to =A0#+results: because it fits more to the entire babel synta= x.
> However, earlier on the mailing list people were pointing out that one=
> is going to change "results" for a unknown source block (tha= t was the
> reason "data" was introduced).... and I think this is a vali= d
> argument. Maybe "data" and "results" should be bot= h 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 o= nly 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



--
Rainer M. K= rug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl= . Phys. (Germany)

Centre of Excellence for Invasion Biology
Stell= enbosch University
South Africa

Tel : =A0 =A0 =A0 +33 - (0)9 53 10 27 44
Cell: =A0 = =A0 =A0 +33 - (0)6 85 62 59 98
Fax (F): =A0 =A0 =A0 +33 - (0)9 58 10 27 = 44

Fax (D): =A0 =A0+49 - (0)3 21 21 25 22 44

email: =A0 =A0 = =A0Rainer@krugs.de=

Skype: =A0 =A0 =A0RMkrug

--0016e6551eb275eb4c04b019df20--