Re: Re: Internal links in LaTeX export

[Tom Dye <colleagues@tsdye2.com>]

Many thanks to all of you for figuring this out and fixing it.  I can  
confirm that internal and external links both work in the pdf file  
compiled from the Org-mode LaTeX export, which is way cool and seems  
miraculous to a dirt archaeologist.

All the best,
Tom

On Oct 28, 2010, at 7:01 PM, Noorul Islam K M wrote:

> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> 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
>>
> Looks like time to change the variable name which is actually  
> confusing.
>
> Since href and hyperref are two different things, I renamed the  
> existing
> `org-export-latex-hyperref-format' variable as
> `org-export-latex-href-format' and introduced a new one
> `org-export-latex-hyperref-format'.
>
> * org-latex.el (org-export-latex-hyperref-format): New option.
> (org-export-latex-href-format): Renamed the existing variable
> `org-export-latex-hyperref-format' as `org-export-latex-href-format'
> (org-export-latex-links): Use `org-export-latex-hyperref-format' and
> `org-export-latex-href-format'
>
> Thanks and Regards
> Noorul
>
> diff --git a/lisp/org-latex.el b/lisp/org-latex.el
> index cdc240c..8f0e0ea 100644
> --- a/lisp/org-latex.el
> +++ b/lisp/org-latex.el
> @@ -295,7 +295,14 @@ markup defined, the first one in the  
> association list will be used."
> :group 'org-export-latex
> :type 'string)
>
> -(defcustom org-export-latex-hyperref-format "\\href{%s}{%s}"
> +(defcustom org-export-latex-href-format "\\href{%s}{%s}"
> +  "A printf format string to be applied to href links.
> +The format must contain two %s instances.  The first will be filled  
> with
> +the link, the second with the link description."
> +  :group 'org-export-latex
> +  :type 'string)
> +
> +(defcustom org-export-latex-hyperref-format "\\hyperref[%s]{%s}"
> "A printf format string to be applied to hyperref links.
> The format must contain two %s instances.  The first will be filled  
> with
> the link, the second with the link description."
> @@ -2016,10 +2023,10 @@ The conversion is made depending of STRING- 
> BEFORE and STRING-AFTER."
> 	      (insert (format
> 		       (org-export-get-coderef-format path desc)
> 		       (cdr (assoc path org-export-code-refs)))))
> -	     (radiop (insert (format "\\hyperref[%s]{%s}"
> +	     (radiop (insert (format org-export-latex-hyperref-format
> 				     (org-solidify-link-text raw-path) desc)))
> 	     ((not type)
> -	      (insert (format "\\hyperref[%s]{%s}"
> +	      (insert (format org-export-latex-hyperref-format
> 			      (org-remove-initial-hash
> 			       (org-solidify-link-text raw-path))
> 			      desc)))
> @@ -2030,7 +2037,7 @@ The conversion is made depending of STRING- 
> BEFORE and STRING-AFTER."
> 		;; a LaTeX issue, but we here implement a work-around anyway.
> 		(setq path (org-export-latex-protect-amp path)
> 		      desc (org-export-latex-protect-amp desc)))
> -	      (insert (format org-export-latex-hyperref-format path desc)))
> +	      (insert (format org-export-latex-href-format path desc)))
>
> 	     ((functionp (setq fnc (nth 2 (assoc type org-link-protocols))))
> 	      ;; The link protocol has a function for formatting the link
>
>>>
>>> * 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
>>
>>
>> _______________________________________________
>> 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
> _______________________________________________
> 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