From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thomas S. Dye" Subject: Re: Re: Internal links in LaTeX export Date: Thu, 28 Oct 2010 14:20:59 -1000 Message-ID: <25705B2C-189C-47A3-B6DC-71026E1DAC09@tsdye.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> Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from [140.186.70.92] (port=59317 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBcoM-0001ni-FE for emacs-orgmode@gnu.org; Thu, 28 Oct 2010 20:27:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBcid-0003Nv-T5 for emacs-orgmode@gnu.org; Thu, 28 Oct 2010 20:21:21 -0400 Received: from oproxy2-pub.bluehost.com ([67.222.39.60]:47947) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1PBcid-0003Mt-J7 for emacs-orgmode@gnu.org; Thu, 28 Oct 2010 20:21:19 -0400 In-Reply-To: <18647.1288305308@alphaville.usa.hp.com> 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: =?ISO-8859-1?Q?S=E9bastien_Vauban?= , emacs-orgmode@gnu.org, Jambunathan K On Oct 28, 2010, at 12:35 PM, Nick Dokos wrote: > Thomas S. Dye wrote: > >> On Oct 28, 2010, at 11:01 AM, Jambunathan K wrote: >> >> >> This is a regression. release-7.01h is good. HEAD is bad. I get >> the >> following line with release-7.01h. >> >> Links to \hyperref[sec-1]{Heading1} >> >> Jambunathan K. >> >> Aloha Jambunathan K., >> >> Very many thanks for this information. I have Org-mode version >> 7.01trans >> (release_7.01h.880.g7531f). I take it the problem I'm having is >> due to a relatively recent change >> to Org-mode. If there is anything I can do to help isolate the >> problem, please let me know. >> > > Tom, > > If you have the time and the inclination, you might try bisecting your > way through. Bisecting org-mode problems is actually a very good way > to > practice because the turnaround time is very small. > > Prerequisites: > > * you have a clone of the org-mode git repository. > > * you have an org test file. > > > Steps: > > * [optional, but it makes me feel a little safer] create a test branch > and switch to it: > > git checkout -b test-branch master > > * I clean out all the compiled files while doing a bisection: it's > quicker > than regenerating them every time and I don't have to worry (much) > about > emacs loading a wayward .elc file: > > make clean > > * start the bisection and tell git which commit is known good and > which is known bad: > > git bisect start > > # current version is bad > git bisect bad > > # release_7.01h was good - I got the name with ``git tag'' > git bisect good release_7.01h > > That checks out a revision half-way in between the bad and good > commits: since > there are about 900 commits in between, you'll be at approx the 450- > mark and it > should take about 10 bisections to get it down to a single commit. > > * LOOP Now all you have to do is repeat the following steps: > > # since you did ``make clean'' you don't have to worry about .elc > files > # just reload all the .el files. > M-x org-reload > > visit your org test file, export to LaTeX, check for \href/ > \hyperref (or > whatever other telltale sign shows badness/goodness). > > # tell git about it > git bisect good *OR* git bisect bad > > This last step will check out another revision and in about 10 > repetitions > of the loop, you are done. > > * Tell git you are done, so it can clean up: > > git bisect reset > > Theoretically, you could do all of this in your master branch without > creating a test-branch and this last step will reset everything to the > way it was before ``git start''. > > * Post the offending commit to the list. > > * Get back to your master branch: > > git checkout master > > * If you created a test-branch, clean it out: > > git branch -d test-branch > > * [Optional] Recreate your .elc files and reload them: > > make > M-x org-reload > > > And that's it: a half-hour of fun and games. Unless of course, you > hit upon a revision that is neither good nor bad (in the above > restricted > sense): you might get some other problem that prevents you from being > able to answer. That might or might not be easy to resolve, so I'll > leave that as an advanced topic (truth be told, I came up against this > situation a couple of days ago and I didn't know how to proceed: so > it's ignorance more than anything else that prevents me from saying > anything more). > > If you want to try, I'd be happy to answer questions - I might try the > bisection later on tonight myself in any case. And btw, this is of > course archeology of a different (and much easier) kind, so I imagine > you'll take to it like a fish in water :-) > > HTH, > Nick Hi Nick, Irresistible hook at the end there. I wish this stuff were as easy as archaeology is for me. Your instructions are terrific, though. I did hit on a revision that was neither good nor bad: commit 8562273b272024a630a582b0e1b94c481d8abeec Author: Eric Schulte Date: Sat Oct 16 13:21:47 2010 -0600 ob-ref: don't forget arguments to referenced code blocks * lisp/ob-ref.el (org-babel-ref-resolve): bringing the referent arguments back to their params before evaluation This one puts these lines in *Messages* when I export to LaTeX executing Org code block... if: Symbol's value as variable is void: result-type I tried using different commits for the initial git bisect good, hoping that would skip by the problem, but this one appears to have stuck around a while. My other two tries both ended with this same error, but with different commits. I'm not sure what to do next. This problem isn't yielding to my archaeo-logic. :) All the best, Tom