emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Bastien <bzg@gnu.org>
To: nicholas.dokos@hp.com
Cc: Achim Gratz <Stromeko@nexgo.de>, emacs-orgmode@gnu.org
Subject: Re: Problems with (defvar foo) and Emacs 23
Date: Mon, 02 Apr 2012 10:21:54 +0200	[thread overview]
Message-ID: <87mx6u35nh.fsf@gnu.org> (raw)
In-Reply-To: <18469.1333346492@alphaville> (Nick Dokos's message of "Mon, 02 Apr 2012 02:01:32 -0400")

Hi Nick,

Nick Dokos <nicholas.dokos@hp.com> 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.



  reply	other threads:[~2012-04-02  8:20 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-01 18:57 Problems with (defvar foo) and Emacs 23 Bernt Hansen
2012-04-01 20:16 ` Achim Gratz
2012-04-01 20:29   ` [URGENT] " Achim Gratz
2012-04-02  6:15     ` Bastien
2012-04-01 20:37   ` Bastien
2012-04-01 21:18     ` Achim Gratz
2012-04-02  0:53       ` Nick Dokos
2012-04-02  5:31         ` Achim Gratz
2012-04-02  6:01           ` Nick Dokos
2012-04-02  8:21             ` Bastien [this message]
2012-04-02  6:28           ` Bastien
2012-04-02  6:27       ` Bastien
2012-04-02 18:11         ` Achim Gratz
2012-04-03  5:49           ` Bastien
2012-04-03  6:04             ` Achim Gratz
2012-04-04  7:25               ` Bastien
2012-04-02  6:12   ` Bastien
2012-04-07 12:15     ` Matt Lundin
2012-04-09 14:57       ` Bastien
2012-04-01 20:46 ` Nick Dokos
2012-04-01 20:48   ` Bernt Hansen
2012-04-02  6:09   ` Bastien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mx6u35nh.fsf@gnu.org \
    --to=bzg@gnu.org \
    --cc=Stromeko@nexgo.de \
    --cc=emacs-orgmode@gnu.org \
    --cc=nicholas.dokos@hp.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).