[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [RFC] Standardized code block keywords

From: Eric Schulte
Subject: Re: [O] [RFC] Standardized code block keywords
Date: Fri, 21 Oct 2011 10:24:12 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)

> 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

> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]