Re: [RFC] Standardized code block keywords

[Torsten Wagner <torsten.wagner@gmail.com>]

Hi,

> 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?

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

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"

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.

[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?

Totti