emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jambunathan K <kjambunathan@gmail.com>
To: "Thomas S. Dye" <tsd@tsdye.com>
Cc: "Sébastien Vauban" <wxhgmqzgwmuf@spammotel.com>,
	nicholas.dokos@hp.com, emacs-orgmode@gnu.org
Subject: Re: [SOLVED] Re: Internal links in LaTeX export
Date: Fri, 29 Oct 2010 08:52:52 +0530	[thread overview]
Message-ID: <81zktxllju.fsf@gmail.com> (raw)
In-Reply-To: 3E9A955C-3A21-42CE-BE35-D638FF310E57@tsdye.com

"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
    
    * 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

  reply	other threads:[~2010-10-29  3:34 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                 ` Jambunathan K [this message]
2010-10-29  3:58                   ` [SOLVED] " Carsten Dominik
2010-10-29  5:01                     ` Noorul Islam K M
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

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=81zktxllju.fsf@gmail.com \
    --to=kjambunathan@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=nicholas.dokos@hp.com \
    --cc=tsd@tsdye.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 public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).