From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jambunathan K Subject: Re: [SOLVED] Re: Internal links in LaTeX export Date: Fri, 29 Oct 2010 08:52:52 +0530 Message-ID: <81zktxllju.fsf@gmail.com> References: <54309AAF-34E2-47F9-9DF2-236DC9BBFA69@tsdye.com> <80y69i5avh.fsf@mundaneum.com> <8439CC4F-8895-43F1-BE6A-D8E5A491A908@tsdye.com> <81tyk6117u.fsf@gmail.com> <18647.1288305308@alphaville.usa.hp.com> <25705B2C-189C-47A3-B6DC-71026E1DAC09@tsdye.com> <81r5f9g4z2.fsf@gmail.com> <3E9A955C-3A21-42CE-BE35-D638FF310E57@tsdye.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from [140.186.70.92] (port=57595 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBfjL-0002PV-TE for emacs-orgmode@gnu.org; Thu, 28 Oct 2010 23:34:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBfjJ-0008Up-Hs for emacs-orgmode@gnu.org; Thu, 28 Oct 2010 23:34:15 -0400 Received: from mail-iw0-f169.google.com ([209.85.214.169]:39970) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PBfjJ-0008UT-BM for emacs-orgmode@gnu.org; Thu, 28 Oct 2010 23:34:13 -0400 Received: by iwn38 with SMTP id 38so2370714iwn.0 for ; Thu, 28 Oct 2010 20:34:12 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: "Thomas S. Dye" Cc: =?iso-8859-1?Q?S=E9bastien?= Vauban , nicholas.dokos@hp.com, emacs-orgmode@gnu.org "Thomas S. Dye" 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" writes: >> >>> On Oct 28, 2010, at 12:35 PM, Nick Dokos wrote: >>> >>>> Thomas S. Dye 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 >>> 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