From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines Date: Tue, 01 Nov 2011 09:17:31 -0600 Message-ID: <87hb2nj2ic.fsf@gmail.com> 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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:52562) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLG5u-0003dr-8o for emacs-orgmode@gnu.org; Tue, 01 Nov 2011 11:17:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RLG5o-0000aH-6L for emacs-orgmode@gnu.org; Tue, 01 Nov 2011 11:17:42 -0400 Received: from mail-gy0-f169.google.com ([209.85.160.169]:49942) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLG5o-0000aC-0m for emacs-orgmode@gnu.org; Tue, 01 Nov 2011 11:17:36 -0400 Received: by gyg10 with SMTP id 10so93771gyg.0 for ; Tue, 01 Nov 2011 08:17:35 -0700 (PDT) In-Reply-To: <9991.1320159724@alphaville.dokosmarshall.org> (Nick Dokos's message of "Tue, 01 Nov 2011 11:02:04 -0400") 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: nicholas.dokos@hp.com Cc: emacs-orgmode@gnu.org 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. > 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. 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. > > 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). 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/