From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: Problems with (defvar foo) and Emacs 23 Date: Mon, 02 Apr 2012 10:21:54 +0200 Message-ID: <87mx6u35nh.fsf@gnu.org> References: <87sjgngtzk.fsf@norang.ca> <87aa2vp5ri.fsf@Rainer.invalid> <87aa2vw5mq.fsf@gnu.org> <87y5qfp2wd.fsf@Rainer.invalid> <15968.1333328036@alphaville> <87wr5yg0nd.fsf@Rainer.invalid> <18469.1333346492@alphaville> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:32936) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SEcVN-0008A4-55 for emacs-orgmode@gnu.org; Mon, 02 Apr 2012 04:20:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SEcVH-0000fh-7i for emacs-orgmode@gnu.org; Mon, 02 Apr 2012 04:20:48 -0400 Received: from mail-we0-f169.google.com ([74.125.82.169]:50668) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SEcVG-0000eI-LI for emacs-orgmode@gnu.org; Mon, 02 Apr 2012 04:20:43 -0400 Received: by werj55 with SMTP id j55so2009908wer.0 for ; Mon, 02 Apr 2012 01:20:40 -0700 (PDT) In-Reply-To: <18469.1333346492@alphaville> (Nick Dokos's message of "Mon, 02 Apr 2012 02:01:32 -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: Achim Gratz , emacs-orgmode@gnu.org Hi Nick, Nick Dokos writes: > Agreed, but the point is that each and every variable renaming will need > to be checked in the light of these criteria. Bugs like this have the > potential of creating havoc for a long time to come. > > It may be easier to start from a working state than to try to fix the > current broken state piecemeal. The thing is... Org is working fine here. Of course, I'm not a "thousand eyes" by myself and some features might be broken in the current state, I will continue trying to catch them. > Besides, I'd rather have a single commit > in the history that does the right thing: having one commit that creates > the initial buggy state and then N commits at various times to fix the > brokenness might create all sorts of problems (breaking bisectability > e.g.) Theoretically agreed. But again: if you look at the diffs from the list of commits you sent, most of them are okay. Let's try to fix the ones that are *not* okay instead of going backward? I will revert the commits if things are really broken. Best, -- Bastien