Re: Re: Internal links in LaTeX export

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

Aloha Jambunathan K.,

Yes, thanks for that suggestion.  It should work on your example, but  
it breaks external links, like this:

\hyperref[http://www.ctan.org/tex-archive/macros/latex/contrib/koma-script/ 
]{KOMA-script}

External links require the \href{}{} command.  It appears the LaTeX  
export process no longer distinguishes internal and external links, as  
I believe it used to do.

All the best,
Tom

On Oct 28, 2010, at 3:30 PM, Jambunathan K wrote:

>
> Thomas
>
> There was a hint at possible solution (or atleast a partial  
> solution) in
> my original post. Did you try it before jumping in to rough waters or
> digging deeper?
>
> Do
>
> ,----
> | M-x customize-variable RET org-export-latex-hyperref-format'
> `----
>
> so that your .emacs has an entry like this
>
> ,---- [.emacs]
> |
> | (custom-set-variables
> |  '(org-export-latex-hyperref-format "\\hyperref[%s]{%s}"))
> |
> `----
>
> The above setting solves the problem for me with the following simple
> Org file.
>
> * Heading1
>  Make this section as large as possible so that it fills atleast a
>  page.
>
> * Heading2
>  Links to [[Heading1]]
>
> Jambunathan K.
>
> "Thomas S. Dye" <tsd@tsdye.com> writes:
>
>> 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