From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jambunathan K Subject: Re: Re: Internal links in LaTeX export Date: Fri, 29 Oct 2010 15:47:12 +0530 Message-ID: <81fwvpnw0n.fsf@gmail.com> References: <54309AAF-34E2-47F9-9DF2-236DC9BBFA69@tsdye.com> <80y69i5avh.fsf@mundaneum.com> <8439CC4F-8895-43F1-BE6A-D8E5A491A908@tsdye.com> <81tyk6117u.fsf@gmail.com> <18647.1288305308@alphaville.usa.hp.com> <25705B2C-189C-47A3-B6DC-71026E1DAC09@tsdye.com> <9528.1288322915@gamaville.dokosmarshall.org> <15827.1288331162@gamaville.dokosmarshall.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from [140.186.70.92] (port=34389 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBm1W-0006Of-01 for emacs-orgmode@gnu.org; Fri, 29 Oct 2010 06:17:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBm1U-0003Op-RS for emacs-orgmode@gnu.org; Fri, 29 Oct 2010 06:17:25 -0400 Received: from mail-pw0-f41.google.com ([209.85.160.41]:63248) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PBm1U-0003Og-MJ for emacs-orgmode@gnu.org; Fri, 29 Oct 2010 06:17:24 -0400 Received: by pwi1 with SMTP id 1so1367847pwi.0 for ; Fri, 29 Oct 2010 03:17:23 -0700 (PDT) In-Reply-To: <15827.1288331162@gamaville.dokosmarshall.org> (Nick Dokos's message of "Fri, 29 Oct 2010 01:46:02 -0400") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: nicholas.dokos@hp.com Cc: emacs-orgmode@gnu.org Nick I hunted down the bug with heuristics. Speaking of bisections, > In this instance, I actually bisected it down to the bad commit that > Jambunathan K. identified (and Carsten reverted). I guess I was lucky > in the sense that I pulled a couple of days ago, so HEAD was 851 > commits ahead of 7.01h and the bisection proceeded as follows: > > release_7.01h-851-gfd9e933 - bad > release_7.01h - good > release_7.01h-425-gfea9072 - good > release_7.01h-638-gd9e4469 - good > release_7.01h-744-g3d2aec3 - bad <<<<<< > release_7.01h-691-g6b9782d - good > release_7.01h-717-gc9bb51e - bad > release_7.01h-704-g935c310 - good > release_7.01h-710-gc9b0176 - good > release_7.01h-713-g8820a25 - good > release_7.01h-715-gf5918bd - bad > release_7.01h-714-gdf5894c - good > > and it identified release_7.01h-715-gf5918bd as the first bad > commit. From the previous investigation, I know that the result-type > error that you ran into, was introduced after commit 750 and resolved > before commit 800 (using release_7.01h as the origin), so once I got to > the <<<< point above, I was safe: I couldn't possibly end up in the > problematic range. OTOH, if you start from say 810, the sequence would > be 405, 608, 709, 759 (or so) and you end up in the problematic range, > which is probably what happened to you. > > BTW, I got the bisection sequence (after the fact) with > > git bisect log > > and then translated the (40-hex digit SHA1 form) commits to the more > readable form above using > > git describe > Git bisection is wonderful. It is a bit of drag nevertheless - Tag, Test, Tag, Test Tag, Test .... Ah, finally done (or undecided) In the case at hand, it is clear that the issue is with either org-latex.el (or org-exp.el). It is most likely the former because the bug description is backend-specific. I wish there was a way to say this: - "do bisection on the revisions where org-latex.el changed (as opposed to revisions where HEAD moved)" The candidate commits then would have reduced to 30 odd commits rather than 851 that one had to contend with. Hypothetically speaking, even this improved bisection would have left me confused at somepoint because of the churn 'pdflatex & texi2dvi' churn that pdf export process went through in recent times. Jambunathan K. > This is all 20/20 hindsight of course, but I hope interesting > enough as a curiosity. > > Nick