From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Dye Subject: Re: Re: Internal links in LaTeX export Date: Thu, 28 Oct 2010 20:38:58 -1000 Message-ID: <9FA91306-6EFF-45A1-8E0C-783AF6996371@tsdye2.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> <81zktxllju.fsf@gmail.com> <871v79h9t3.fsf@noorul.maa.corp.collab.net> 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=34367 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBicG-0003oK-NH for emacs-orgmode@gnu.org; Fri, 29 Oct 2010 02:39:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBicB-0000cu-My for emacs-orgmode@gnu.org; Fri, 29 Oct 2010 02:39:08 -0400 Received: from oproxy3-pub.bluehost.com ([69.89.21.8]:44680) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1PBicB-0000cl-CN for emacs-orgmode@gnu.org; Fri, 29 Oct 2010 02:39:03 -0400 In-Reply-To: <871v79h9t3.fsf@noorul.maa.corp.collab.net> 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: Noorul Islam K M Cc: Vauban Vauban , Nick Dokos , Org Mode , Jambunathan K , Carsten Dominik Many thanks to all of you for figuring this out and fixing it. I can confirm that internal and external links both work in the pdf file compiled from the Org-mode LaTeX export, which is way cool and seems miraculous to a dirt archaeologist. All the best, Tom On Oct 28, 2010, at 7:01 PM, Noorul Islam K M wrote: > Carsten Dominik writes: > >> 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 >> > Looks like time to change the variable name which is actually > confusing. > > Since href and hyperref are two different things, I renamed the > existing > `org-export-latex-hyperref-format' variable as > `org-export-latex-href-format' and introduced a new one > `org-export-latex-hyperref-format'. > > * org-latex.el (org-export-latex-hyperref-format): New option. > (org-export-latex-href-format): Renamed the existing variable > `org-export-latex-hyperref-format' as `org-export-latex-href-format' > (org-export-latex-links): Use `org-export-latex-hyperref-format' and > `org-export-latex-href-format' > > Thanks and Regards > Noorul > > diff --git a/lisp/org-latex.el b/lisp/org-latex.el > index cdc240c..8f0e0ea 100644 > --- a/lisp/org-latex.el > +++ b/lisp/org-latex.el > @@ -295,7 +295,14 @@ markup defined, the first one in the > association list will be used." > :group 'org-export-latex > :type 'string) > > -(defcustom org-export-latex-hyperref-format "\\href{%s}{%s}" > +(defcustom org-export-latex-href-format "\\href{%s}{%s}" > + "A printf format string to be applied to href links. > +The format must contain two %s instances. The first will be filled > with > +the link, the second with the link description." > + :group 'org-export-latex > + :type 'string) > + > +(defcustom org-export-latex-hyperref-format "\\hyperref[%s]{%s}" > "A printf format string to be applied to hyperref links. > The format must contain two %s instances. The first will be filled > with > the link, the second with the link description." > @@ -2016,10 +2023,10 @@ The conversion is made depending of STRING- > BEFORE and STRING-AFTER." > (insert (format > (org-export-get-coderef-format path desc) > (cdr (assoc path org-export-code-refs))))) > - (radiop (insert (format "\\hyperref[%s]{%s}" > + (radiop (insert (format org-export-latex-hyperref-format > (org-solidify-link-text raw-path) desc))) > ((not type) > - (insert (format "\\hyperref[%s]{%s}" > + (insert (format org-export-latex-hyperref-format > (org-remove-initial-hash > (org-solidify-link-text raw-path)) > desc))) > @@ -2030,7 +2037,7 @@ The conversion is made depending of STRING- > BEFORE and STRING-AFTER." > ;; a LaTeX issue, but we here implement a work-around anyway. > (setq path (org-export-latex-protect-amp path) > desc (org-export-latex-protect-amp desc))) > - (insert (format org-export-latex-hyperref-format path desc))) > + (insert (format org-export-latex-href-format path desc))) > > ((functionp (setq fnc (nth 2 (assoc type org-link-protocols)))) > ;; The link protocol has a function for formatting the link > >>> >>> * 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 >> >> >> _______________________________________________ >> 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 > _______________________________________________ > 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