From mboxrd@z Thu Jan 1 00:00:00 1970 From: Noorul Islam K M Subject: Re: Internal links in LaTeX export Date: Fri, 29 Oct 2010 10:31:12 +0530 Message-ID: <871v79h9t3.fsf@noorul.maa.corp.collab.net> 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 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from [140.186.70.92] (port=35668 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBh8X-000405-2U for emacs-orgmode@gnu.org; Fri, 29 Oct 2010 01:04:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBh7Q-00045Z-HV for emacs-orgmode@gnu.org; Fri, 29 Oct 2010 01:03:14 -0400 Received: from mail-yx0-f169.google.com ([209.85.213.169]:50002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PBh7Q-00045T-Dw for emacs-orgmode@gnu.org; Fri, 29 Oct 2010 01:03:12 -0400 Received: by yxm34 with SMTP id 34so2147065yxm.0 for ; Thu, 28 Oct 2010 22:03:11 -0700 (PDT) In-Reply-To: (Carsten Dominik's message of "Fri, 29 Oct 2010 05:58:15 +0200") 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: Carsten Dominik Cc: =?utf-8?Q?S=C3=A9bastien?=, Vauban , nicholas.dokos@hp.com, emacs-orgmode@gnu.org, Jambunathan K --=-=-= 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 --=-=-= Content-Disposition: inline; filename=org-latex.el.txt 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 --=-=-= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --=-=-=--