From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jambunathan K Subject: Re: Re: Internal links in LaTeX export Date: Fri, 29 Oct 2010 07:00:57 +0530 Message-ID: <81r5f9g4z2.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from [140.186.70.92] (port=33675 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBdoJ-0005pa-1f for emacs-orgmode@gnu.org; Thu, 28 Oct 2010 21:31:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBdoG-0005IP-MT for emacs-orgmode@gnu.org; Thu, 28 Oct 2010 21:31:14 -0400 Received: from mail-gx0-f169.google.com ([209.85.161.169]:48477) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PBdoG-0005I8-IU for emacs-orgmode@gnu.org; Thu, 28 Oct 2010 21:31:12 -0400 Received: by gxk2 with SMTP id 2so270626gxk.0 for ; Thu, 28 Oct 2010 18:31:11 -0700 (PDT) In-Reply-To: <25705B2C-189C-47A3-B6DC-71026E1DAC09@tsdye.com> (Thomas S. Dye's message of "Thu, 28 Oct 2010 14:20:59 -1000") 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 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