Re: [SOLVED] Re: Internal links in LaTeX export

From: Carsten Dominik <carsten.dominik@gmail.com>
To: Jambunathan K <kjambunathan@gmail.com>
Cc: "Sébastien Vauban" <wxhgmqzgwmuf@spammotel.com>,
	nicholas.dokos@hp.com, emacs-orgmode@gnu.org
Subject: Re: [SOLVED] Re: Internal links in LaTeX export
Date: Fri, 29 Oct 2010 05:58:15 +0200	[thread overview]
Message-ID: <BC647B78-D006-467A-9FD5-EBF0A97513DD@gmail.com> (raw)
In-Reply-To: <81zktxllju.fsf@gmail.com>

On Oct 29, 2010, at 5:22 AM, Jambunathan K wrote:

> "Thomas S. Dye" <tsd@tsdye.com> writes:
>
>> 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.
>>
>
> This is the problematic commit:
>
> commit f5918bdcc05d7924dc204b57307023eb1ef011f0
> parent	df5894cdcb10819560f003c5b94b8f5f2b7d33cf
> Date:   Sun Oct 17 08:29:51 2010 +0000
>
>    LaTeX export: use org-export-latex-hyperref-format

I have just reverted this commit.

- Carsten

>
>    * lisp/org-latex.el (org-export-latex-links) : Replaced hard coded
>    hyperref format with custom
>      variable `org-export-latex-hyperref-format'
>
> Note that href is not same as hyperref.
>
> Jambunthan K.
>
>
>> 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
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode