emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tom Dye
Subject: Re: [Orgmode] Re: Internal links in LaTeX export
Date: Thu, 28 Oct 2010 20:38:58 -1000

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]