From: Noorul Islam K M <noorul@noorul.com>
To: Carsten Dominik <carsten.dominik@gmail.com>
Cc: Vauban <wxhgmqzgwmuf@spammotel.com>,
nicholas.dokos@hp.com, emacs-orgmode@gnu.org,
"Jambunathan K" <kjambunathan@gmail.com>
Subject: Re: Internal links in LaTeX export
Date: Fri, 29 Oct 2010 10:31:12 +0530 [thread overview]
Message-ID: <871v79h9t3.fsf@noorul.maa.corp.collab.net> (raw)
In-Reply-To: <BC647B78-D006-467A-9FD5-EBF0A97513DD@gmail.com> (Carsten Dominik's message of "Fri, 29 Oct 2010 05:58:15 +0200")
[-- Attachment #1: Type: text/plain, Size: 1498 bytes --]
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
[-- Attachment #2: org-latex.el.txt --]
[-- Type: text/plain, Size: 2010 bytes --]
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
[-- Attachment #3: Type: text/plain, Size: 7178 bytes --]
>>
>> * 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
[-- Attachment #4: Type: text/plain, Size: 201 bytes --]
_______________________________________________
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
next prev parent reply other threads:[~2010-10-29 5:04 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-28 20:06 Internal links in LaTeX export Thomas S. Dye
2010-10-28 20:18 ` Sébastien Vauban
2010-10-28 20:44 ` Thomas S. Dye
2010-10-28 21:01 ` Jambunathan K
2010-10-28 21:19 ` Thomas S. Dye
2010-10-28 22:35 ` Nick Dokos
2010-10-29 0:20 ` Thomas S. Dye
2010-10-29 1:30 ` Jambunathan K
2010-10-29 2:04 ` Thomas S. Dye
2010-10-29 3:22 ` [SOLVED] " Jambunathan K
2010-10-29 3:58 ` Carsten Dominik
2010-10-29 5:01 ` Noorul Islam K M [this message]
2010-10-29 6:38 ` Tom Dye
2010-10-29 7:20 ` Nick Dokos
2010-10-29 7:51 ` Noorul Islam
2010-10-29 8:34 ` Nick Dokos
2010-11-13 5:55 ` [Accepted] " Carsten Dominik
2010-10-29 3:28 ` Nick Dokos
2010-10-29 5:46 ` Nick Dokos
2010-10-29 10:17 ` Jambunathan K
2010-10-30 19:56 ` suvayu ali
2010-11-02 7:35 ` Jambunathan K
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871v79h9t3.fsf@noorul.maa.corp.collab.net \
--to=noorul@noorul.com \
--cc=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=kjambunathan@gmail.com \
--cc=nicholas.dokos@hp.com \
--cc=wxhgmqzgwmuf@spammotel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.