[Accepted] Re: Internal links in LaTeX export

[Carsten Dominik <cdominik@newartisans.com>]

Patch 349 (http://patchwork.newartisans.com/patch/349/) is now "Accepted".

Maintainer comment: No comment

This relates to the following submission:

http://mid.gmane.org/%3C871v79h9t3.fsf%40noorul.maa.corp.collab.net%3E

Here is the original message containing the patch:

> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Subject: [Orgmode] Re: Internal links in LaTeX export
> Date: Fri, 29 Oct 2010 10:01:12 -0000
> From: Noorul Islam <noorul@noorul.com>
> X-Patchwork-Id: 349
> Message-Id: <871v79h9t3.fsf@noorul.maa.corp.collab.net>
> To: Carsten Dominik <carsten.dominik@gmail.com>
> Cc: =?utf-8?Q?S=C3=A9bastien?=@gnu.org, Vauban <wxhgmqzgwmuf@spammotel.com>, 
> 	nicholas.dokos@hp.com, emacs-orgmode@gnu.org,
> 	Jambunathan K <kjambunathan@gmail.com>
> 
> 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
> 
> >>
> >>    * 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
> 
> 
> 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
>