Re: Re: Internal links in LaTeX export

["Thomas S. Dye" <tsd@tsdye.com>]

On Oct 28, 2010, at 12:35 PM, Nick Dokos wrote:

> Thomas S. Dye <tsd@tsdye.com> 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 <schulte.eric@gmail.com>
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