From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: [SOLVED] Re: Internal links in LaTeX export Date: Fri, 29 Oct 2010 05:58:15 +0200 Message-ID: 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> <81zktxllju.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=54892 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBg9V-0007uJ-Tz for emacs-orgmode@gnu.org; Fri, 29 Oct 2010 00:01:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBg6f-000478-Dc for emacs-orgmode@gnu.org; Thu, 28 Oct 2010 23:58:22 -0400 Received: from mail-ey0-f169.google.com ([209.85.215.169]:34152) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PBg6f-000471-3X for emacs-orgmode@gnu.org; Thu, 28 Oct 2010 23:58:21 -0400 Received: by eydd26 with SMTP id d26so1614854eyd.0 for ; Thu, 28 Oct 2010 20:58:20 -0700 (PDT) In-Reply-To: <81zktxllju.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 On Oct 29, 2010, at 5:22 AM, Jambunathan K wrote: > "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 I have just reverted this commit. - Carsten > > * 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 > > _______________________________________________ > 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