From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thomas S. Dye" Subject: Re: Re: Internal links in LaTeX export Date: Thu, 28 Oct 2010 16:04:40 -1000 Message-ID: <3E9A955C-3A21-42CE-BE35-D638FF310E57@tsdye.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> Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from [140.186.70.92] (port=49345 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBeKl-0004Nn-06 for emacs-orgmode@gnu.org; Thu, 28 Oct 2010 22:04:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBeKj-0001L8-AM for emacs-orgmode@gnu.org; Thu, 28 Oct 2010 22:04:46 -0400 Received: from oproxy1-pub.bluehost.com ([66.147.249.253]:52718) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1PBeKj-0001Kt-07 for emacs-orgmode@gnu.org; Thu, 28 Oct 2010 22:04:45 -0400 In-Reply-To: <81r5f9g4z2.fsf@gmail.com> 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: Jambunathan K Cc: =?ISO-8859-1?Q?S=E9bastien_Vauban?= , nicholas.dokos@hp.com, emacs-orgmode@gnu.org 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. 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