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

[Tom Dye]

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 <address@hidden> writes:
>
> > On Oct 29, 2010, at 5:22 AM, Jambunathan K wrote:
> >
> > > "Thomas S. Dye" <address@hidden> 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" <address@hidden> writes:
> > > > >
> > > > > > On Oct 28, 2010, at 12:35 PM, Nick Dokos wrote:
> > > > > >
> > > > > > > Thomas S. Dye <address@hidden> 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 <address@hidden>
> > > > > > 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.
> > > address@hidden
> > > http://lists.gnu.org/mailman/listinfo/emacs-orgmode
> >
> >
> > _______________________________________________
> > Emacs-orgmode mailing list
> > Please use `Reply All' to send replies to the list.
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/emacs-orgmode
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> address@hidden
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode