From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rainer M Krug Subject: Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines Date: Wed, 2 Nov 2011 12:12:06 +0100 Message-ID: References: <87pqhrih3s.fsf@gmail.com> <87zkgvgxe7.fsf@gmail.com> <1405.1319147324@alphaville.dokosmarshall.org> <87zkgvfhra.fsf@gmail.com> <2127.1319148505@alphaville.dokosmarshall.org> <87vcrjfgt1.fsf@gmail.com> <80sjmmvm60.fsf@somewhere.org> <4EA129DB.4070006@christianmoe.com> <8762ji5jr6.fsf@gmail.com> <4EA1D4F9.5010302@christianmoe.com> <4ea1de9c.67b4ec0a.553d.122a@mx.google.com> <87aa8t10np.fsf@gmail.com> <4ea5a95b.059dec0a.606e.0c92@mx.google.com> <874nypkn6y.fsf@gmail.com> <87obwwkia5.fsf@gmail.com> <87boswk4vj.fsf@gmail.com> <8627.1320157576@alphaville.dokosmarshall.org> <9991.1320159724@alphaville.dokosmarshall.org> <87hb2nj2ic.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001485ee82eee3cf4704b0be8a95 Return-path: Received: from eggs.gnu.org ([140.186.70.92]:52331) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLYjr-00073T-BL for emacs-orgmode@gnu.org; Wed, 02 Nov 2011 07:12:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RLYjo-0005dc-UV for emacs-orgmode@gnu.org; Wed, 02 Nov 2011 07:12:11 -0400 Received: from mail-qy0-f169.google.com ([209.85.216.169]:37929) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLYjo-0005dM-Nx for emacs-orgmode@gnu.org; Wed, 02 Nov 2011 07:12:08 -0400 Received: by qyk15 with SMTP id 15so1705428qyk.0 for ; Wed, 02 Nov 2011 04:12:07 -0700 (PDT) In-Reply-To: <87hb2nj2ic.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: nicholas.dokos@hp.com, emacs-orgmode@gnu.org --001485ee82eee3cf4704b0be8a95 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 1, 2011 at 4:17 PM, Eric Schulte wrote: > Nick Dokos writes: > > > Nick Dokos wrote: > > > > > >> Can we please back off this path? > > > > In order to prevent confusion or needless argument: the path I think we > > should back off of is the committing of these changes to master - I think > > the work should be done in a branch and cooked thoroughly before merging > > it to master. > > > Partly agree here - I was bitten by the changes, and have suspended work on one project until this issue stabilizes - I do not want to change my files after each change. > > I would agree that these changes should be happening in branches if the > problems were technical, however the issues that need to be addressed > are social issues of consensus, and for better or worse pushing changes > to the master branch is the best way to alert all interested actors and > begin the consensus-building process. > > If these changes had been pushed up to a branch they would be sitting > happily in that branch with no-one noticing or objecting. They had been > discussed at length on list before their implementation and commitance, > but this most recent round of discussion was caused by a push to the > master branch. > > You are definitely right about that - but it is kind of forcing the issue on to users after telling them they should use git as org is very dynamic, which is a risky business, as it might put users of - consider a new org user who realizes that regularly things are changing which affect him, and he / she has to change aspects of their org files. I would say it is a double edged sword. This is also after all the development repository, and while I do try > very hard never to break this head of this repository at the same time I > think it is an acceptable place to try out new functionality. > Again - true, but it is always recommended on the org-list to use the git repo, as it contains all bug fixes. > > > > I did not mean to imply (although I think one could easily get that > impression > > from my mail) backing off the property implementation (despite my > personal > > reservations about that). > > > > OK, good, because I *do* think that properties are a natural fit for > specifying code block parameters. The use of subtree properties has > already proven itself, and file-wide properties are a natural extension > (much more natural than the introduction of a #+BABEL: header argument). > Then one should possibly also think of merging #+LATEX into #+PROPERTY - which I think would make it more consistent (and this is a serious suggestion). So: all file-wide properties, #+PROPERTIES is used. What would be really important, is to have one page on worg, on which this process is documented - i.e. how files need to be changed, to be used with which version of org. I definitely have no idea, how I have to modify my files at the moment (there was the discussion abour source_name, name, ... and then the #+PROPERTY - I hope I haven't missed anything?). As I said - I have the luck, that I can wait until it stabilizes (at least I hope) - but a regularly updated summary with changes would be very welcome (and I guess I can speak for many org users). Even if this step is painful for many (especially the ones not to familiar with the inner workings of org and babel (this definitely includes me)), I am sure that the best solution will be found (hopefully soon) and we will have a better and stronger org-mode at hand. Cheers, Rainer > While there is certainly some pain in this process I think it is nailing > down both the needs for code block properties as well as the scope of > what is and is not desirable functionality for properties in general. > > Best -- Eric > > > > > Nick > > > > > > > > > > > > > > > > > > > > > > -- > 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 --001485ee82eee3cf4704b0be8a95 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Nov 1, 2011 at 4:17 PM, Eric Sch= ulte <schult= e.eric@gmail.com> wrote:
Nick Dokos <n= icholas.dokos@hp.com> writes:

> Nick Dokos <nicholas.dokos= @hp.com> wrote:
>
>
>> Can we please back off this path?
>
> In order to prevent confusion or needless argument: the path I think w= e
> should back off of is the committing of these changes to master - I th= ink
> the work should be done in a branch and cooked thoroughly before mergi= ng
> it to master.
>

Partly agree here - I was bitten by the= changes, and have suspended work on one project until this issue stabilize= s - I do not want to change my files after each change.
=A0

I would agree that these changes should be happening in branches if t= he
problems were technical, however the issues that need to be addressed
are social issues of consensus, and for better or worse pushing changes
to the master branch is the best way to alert all interested actors and
begin the consensus-building process.

If these changes had been pushed up to a branch they would be sitting
happily in that branch with no-one noticing or objecting. =A0They had been<= br> discussed at length on list before their implementation and commitance,
but this most recent round of discussion was caused by a push to the
master branch.

=A0
You are definitely right abo= ut that - but it is kind of forcing the issue on to users after telling the= m they should use git as org is very dynamic, which is a risky business, as= it might put users of - consider a new org user who realizes that regularl= y things are changing which affect him, and he / she has to change aspects = of their org files. I would say it is a double edged sword.

This is also after all the development repository, and while I do try
very hard never to break this head of this repository at the same time I think it is an acceptable place to try out new functionality.

Again - true, but it is always recommended on the org-list to u= se the git repo, as it contains all bug fixes.


>
> I did not mean to imply (although I think one could easily get that im= pression
> from my mail) backing off the property implementation (despite my pers= onal
> reservations about that).
>

OK, good, because I *do* think that properties are a natural fit for<= br> specifying code block parameters. =A0The use of subtree properties has
already proven itself, and file-wide properties are a natural extension
(much more natural than the introduction of a #+BABEL: header argument).

Then one should possibly also think of merging #+LAT= EX into #+PROPERTY - which I think would make it more consistent (and this = is a serious suggestion).
So: all file-wide properties, #+PROPERTIES is used.
=A0
What would be= really important, is to have one page on worg, on which this process is do= cumented - i.e. how files need to be changed, to be used with which version= of org. I definitely have no idea, how I have to modify my files at the mo= ment (there was the discussion abour source_name, name, ... and then the #+= PROPERTY - I hope I haven't missed anything?). As I said - I have the l= uck, that I can wait until it stabilizes (at least I hope) - but a regularl= y updated summary with changes would be very welcome (and I guess I can spe= ak for many org users).

Even if this step is painful for many (especially the ones not to famil= iar with the inner workings of org and babel (this definitely includes me))= , I am sure that the best solution will be found (hopefully soon) and we wi= ll have a better and stronger org-mode at hand.

Cheers,

Rainer


While there is certainly some pain in this process I think it is nailing down both the needs for code block properties as well as the scope of
what is and is not desirable functionality for properties in general.

Best -- Eric

>
> Nick
>
>
>
>
>
>
>
>
>
>

--
Eric Schulte
http://cs.unm.= edu/~eschulte/




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

--001485ee82eee3cf4704b0be8a95--