On Fri, Oct 21, 2011 at 6:24 PM, Eric Schulte <schulte.e...@gmail.com>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: rai...@krugs.de
Skype: RMkrug
