* Internal links in LaTeX export @ 2010-10-28 20:06 Thomas S. Dye 2010-10-28 20:18 ` Sébastien Vauban 0 siblings, 1 reply; 22+ messages in thread From: Thomas S. Dye @ 2010-10-28 20:06 UTC (permalink / raw To: Org Mode Aloha all, The manual is silent about what happens to external links on export to LaTeX. I'm finding that internal links export to HTML and work as expected there. In the pdf file via LaTeX the internal links are colored, but aren't active. Is this the expected behavior or am I possibly doing something that disables the links on their way to pdf? All the best, Tom ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Internal links in LaTeX export 2010-10-28 20:06 Internal links in LaTeX export Thomas S. Dye @ 2010-10-28 20:18 ` Sébastien Vauban 2010-10-28 20:44 ` Thomas S. Dye 0 siblings, 1 reply; 22+ messages in thread From: Sébastien Vauban @ 2010-10-28 20:18 UTC (permalink / raw To: emacs-orgmode-mXXj517/zsQ Hi Thomas, "Thomas S. Dye" wrote: > The manual is silent about what happens to external links on export to > LaTeX. I'm finding that internal links export to HTML and work as expected > there. In the pdf file via LaTeX the internal links are colored, but aren't > active. Is this the expected behavior or am I possibly doing something that > disables the links on their way to pdf? Internal links always worked for me in PDF, though they more tend(ed) to go to the page rather than really placing me on the section (like what you have in your browser). Questions: - Which PDF reader do you use? That could influence... - Do you want me to test some example file? If yes, send it here, or privately to me -- attention for delays due to spammotel, though. Best regards, Seb -- Sébastien Vauban _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode-mXXj517/zsQ@public.gmane.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: Internal links in LaTeX export 2010-10-28 20:18 ` Sébastien Vauban @ 2010-10-28 20:44 ` Thomas S. Dye 2010-10-28 21:01 ` Jambunathan K 0 siblings, 1 reply; 22+ messages in thread From: Thomas S. Dye @ 2010-10-28 20:44 UTC (permalink / raw To: Sébastien Vauban; +Cc: emacs-orgmode On Oct 28, 2010, at 10:18 AM, Sébastien Vauban wrote: > Hi Thomas, > > "Thomas S. Dye" wrote: >> The manual is silent about what happens to external links on export >> to >> LaTeX. I'm finding that internal links export to HTML and work as >> expected >> there. In the pdf file via LaTeX the internal links are colored, >> but aren't >> active. Is this the expected behavior or am I possibly doing >> something that >> disables the links on their way to pdf? > > Internal links always worked for me in PDF, though they more > tend(ed) to go > to the page rather than really placing me on the section (like what > you have > in your browser). > > Questions: > > - Which PDF reader do you use? That could influence... > > - Do you want me to test some example file? If yes, send it here, or > privately to me -- attention for delays due to spammotel, though. > > Best regards, > Seb Thanks Seb, It doesn't appear to be a reader problem. The links fail in skim and acrobat. I'm getting this in the LaTeX output: \href{sec-2_5}{package loading part} If I read the hyperref documentation correctly, then I think it should be: \hyperref[sec-2_5]{package loading part} If I'm right about what the link should look like in LaTeX, and there is no obvious reason why I'm not getting it in the LaTeX export, then I'll work on finding a minimal example. All the best, Tom ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Internal links in LaTeX export 2010-10-28 20:44 ` Thomas S. Dye @ 2010-10-28 21:01 ` Jambunathan K 2010-10-28 21:19 ` Thomas S. Dye 0 siblings, 1 reply; 22+ messages in thread From: Jambunathan K @ 2010-10-28 21:01 UTC (permalink / raw To: Thomas S. Dye; +Cc: Sébastien Vauban, emacs-orgmode "Thomas S. Dye" <tsd@tsdye.com> writes: > On Oct 28, 2010, at 10:18 AM, Sébastien Vauban wrote: > >> Hi Thomas, >> >> "Thomas S. Dye" wrote: >>> The manual is silent about what happens to external links on export >>> to >>> LaTeX. I'm finding that internal links export to HTML and work as >>> expected >>> there. In the pdf file via LaTeX the internal links are colored, >>> but aren't >>> active. Is this the expected behavior or am I possibly doing >>> something that >>> disables the links on their way to pdf? >> >> Internal links always worked for me in PDF, though they more >> tend(ed) to go >> to the page rather than really placing me on the section (like what >> you have >> in your browser). >> >> Questions: >> >> - Which PDF reader do you use? That could influence... >> >> - Do you want me to test some example file? If yes, send it here, or >> privately to me -- attention for delays due to spammotel, though. >> >> Best regards, >> Seb > > Thanks Seb, > > It doesn't appear to be a reader problem. The links fail in skim and > acrobat. > > I'm getting this in the LaTeX output: > \href{sec-2_5}{package loading part} > > If I read the hyperref documentation correctly, then I think it should > be: > \hyperref[sec-2_5]{package loading part} > > If I'm right about what the link should look like in LaTeX, and there > is no obvious reason why I'm not getting it in the LaTeX export, then > I'll work on finding a minimal example. > Play with this (for now). ,----[ C-h v org-export-latex-hyperref-format RET ] | org-export-latex-hyperref-format is a variable defined in `org-latex.el'. | Its value is "\\href{%s}{%s}" | | Documentation: | 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. | | You can customize this variable. `---- 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. > 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Internal links in LaTeX export 2010-10-28 21:01 ` Jambunathan K @ 2010-10-28 21:19 ` Thomas S. Dye 2010-10-28 22:35 ` Nick Dokos 0 siblings, 1 reply; 22+ messages in thread From: Thomas S. Dye @ 2010-10-28 21:19 UTC (permalink / raw To: Jambunathan K; +Cc: Sébastien Vauban, emacs-orgmode [-- Attachment #1.1: Type: text/plain, Size: 2609 bytes --] On Oct 28, 2010, at 11:01 AM, Jambunathan K wrote: > "Thomas S. Dye" <tsd@tsdye.com> writes: > >> On Oct 28, 2010, at 10:18 AM, Sébastien Vauban wrote: >> >>> Hi Thomas, >>> >>> "Thomas S. Dye" wrote: >>>> The manual is silent about what happens to external links on export >>>> to >>>> LaTeX. I'm finding that internal links export to HTML and work as >>>> expected >>>> there. In the pdf file via LaTeX the internal links are colored, >>>> but aren't >>>> active. Is this the expected behavior or am I possibly doing >>>> something that >>>> disables the links on their way to pdf? >>> >>> Internal links always worked for me in PDF, though they more >>> tend(ed) to go >>> to the page rather than really placing me on the section (like what >>> you have >>> in your browser). >>> >>> Questions: >>> >>> - Which PDF reader do you use? That could influence... >>> >>> - Do you want me to test some example file? If yes, send it here, >>> or >>> privately to me -- attention for delays due to spammotel, though. >>> >>> Best regards, >>> Seb >> >> Thanks Seb, >> >> It doesn't appear to be a reader problem. The links fail in skim and >> acrobat. >> >> I'm getting this in the LaTeX output: >> \href{sec-2_5}{package loading part} >> >> If I read the hyperref documentation correctly, then I think it >> should >> be: >> \hyperref[sec-2_5]{package loading part} >> >> If I'm right about what the link should look like in LaTeX, and there >> is no obvious reason why I'm not getting it in the LaTeX export, then >> I'll work on finding a minimal example. >> > > Play with this (for now). > > ,----[ C-h v org-export-latex-hyperref-format RET ] > | org-export-latex-hyperref-format is a variable defined in `org- > latex.el'. > | Its value is "\\href{%s}{%s}" > | > | Documentation: > | 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. > | > | You can customize this variable. > `---- > > 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. All the best, Tom [-- Attachment #1.2: Type: text/html, Size: 6126 bytes --] [-- Attachment #2: Type: text/plain, Size: 201 bytes --] _______________________________________________ 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: Internal links in LaTeX export 2010-10-28 21:19 ` Thomas S. Dye @ 2010-10-28 22:35 ` Nick Dokos 2010-10-29 0:20 ` Thomas S. Dye 0 siblings, 1 reply; 22+ messages in thread From: Nick Dokos @ 2010-10-28 22:35 UTC (permalink / raw To: Thomas S. Dye Cc: Sébastien Vauban, nicholas.dokos, emacs-orgmode, Jambunathan K Thomas S. Dye <tsd@tsdye.com> 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: Internal links in LaTeX export 2010-10-28 22:35 ` Nick Dokos @ 2010-10-29 0:20 ` Thomas S. Dye 2010-10-29 1:30 ` Jambunathan K 2010-10-29 3:28 ` Nick Dokos 0 siblings, 2 replies; 22+ messages in thread From: Thomas S. Dye @ 2010-10-29 0:20 UTC (permalink / raw To: nicholas.dokos; +Cc: Sébastien Vauban, emacs-orgmode, Jambunathan K On Oct 28, 2010, at 12:35 PM, Nick Dokos wrote: > Thomas S. Dye <tsd@tsdye.com> 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 <schulte.eric@gmail.com> 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: Internal links in LaTeX export 2010-10-29 0:20 ` Thomas S. Dye @ 2010-10-29 1:30 ` Jambunathan K 2010-10-29 2:04 ` Thomas S. Dye 2010-10-29 3:28 ` Nick Dokos 1 sibling, 1 reply; 22+ messages in thread From: Jambunathan K @ 2010-10-29 1:30 UTC (permalink / raw To: Thomas S. Dye; +Cc: Sébastien Vauban, nicholas.dokos, emacs-orgmode 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" <tsd@tsdye.com> writes: > On Oct 28, 2010, at 12:35 PM, Nick Dokos wrote: > >> Thomas S. Dye <tsd@tsdye.com> 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 <schulte.eric@gmail.com> > 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: Internal links in LaTeX export 2010-10-29 1:30 ` Jambunathan K @ 2010-10-29 2:04 ` Thomas S. Dye 2010-10-29 3:22 ` [SOLVED] " Jambunathan K 0 siblings, 1 reply; 22+ messages in thread From: Thomas S. Dye @ 2010-10-29 2:04 UTC (permalink / raw To: Jambunathan K; +Cc: Sébastien Vauban, nicholas.dokos, emacs-orgmode 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" <tsd@tsdye.com> writes: > >> On Oct 28, 2010, at 12:35 PM, Nick Dokos wrote: >> >>> Thomas S. Dye <tsd@tsdye.com> 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 <schulte.eric@gmail.com> >> 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [SOLVED] Re: Internal links in LaTeX export 2010-10-29 2:04 ` Thomas S. Dye @ 2010-10-29 3:22 ` Jambunathan K 2010-10-29 3:58 ` Carsten Dominik 0 siblings, 1 reply; 22+ messages in thread From: Jambunathan K @ 2010-10-29 3:22 UTC (permalink / raw To: Thomas S. Dye; +Cc: Sébastien Vauban, nicholas.dokos, emacs-orgmode "Thomas S. Dye" <tsd@tsdye.com> 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 * 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" <tsd@tsdye.com> writes: >> >>> On Oct 28, 2010, at 12:35 PM, Nick Dokos wrote: >>> >>>> Thomas S. Dye <tsd@tsdye.com> 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 <schulte.eric@gmail.com> >>> 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [SOLVED] Re: Internal links in LaTeX export 2010-10-29 3:22 ` [SOLVED] " Jambunathan K @ 2010-10-29 3:58 ` Carsten Dominik 2010-10-29 5:01 ` Noorul Islam K M 0 siblings, 1 reply; 22+ messages in thread From: Carsten Dominik @ 2010-10-29 3:58 UTC (permalink / raw To: Jambunathan K; +Cc: Sébastien Vauban, nicholas.dokos, emacs-orgmode On Oct 29, 2010, at 5:22 AM, Jambunathan K wrote: > "Thomas S. Dye" <tsd@tsdye.com> 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" <tsd@tsdye.com> writes: >>> >>>> On Oct 28, 2010, at 12:35 PM, Nick Dokos wrote: >>>> >>>>> Thomas S. Dye <tsd@tsdye.com> 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 <schulte.eric@gmail.com> >>>> 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Internal links in LaTeX export 2010-10-29 3:58 ` Carsten Dominik @ 2010-10-29 5:01 ` Noorul Islam K M 2010-10-29 6:38 ` Tom Dye ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Noorul Islam K M @ 2010-10-29 5:01 UTC (permalink / raw To: Carsten Dominik; +Cc: Vauban, nicholas.dokos, emacs-orgmode, Jambunathan K [-- Attachment #1: Type: text/plain, Size: 1498 bytes --] Carsten Dominik <carsten.dominik@gmail.com> writes: > On Oct 29, 2010, at 5:22 AM, Jambunathan K wrote: > >> "Thomas S. Dye" <tsd@tsdye.com> 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 [-- Attachment #2: org-latex.el.txt --] [-- Type: text/plain, Size: 2010 bytes --] 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 [-- Attachment #3: Type: text/plain, Size: 7178 bytes --] >> >> * 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" <tsd@tsdye.com> writes: >>>> >>>>> On Oct 28, 2010, at 12:35 PM, Nick Dokos wrote: >>>>> >>>>>> Thomas S. Dye <tsd@tsdye.com> 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 <schulte.eric@gmail.com> >>>>> 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 [-- Attachment #4: Type: text/plain, Size: 201 bytes --] _______________________________________________ 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: Re: Internal links in LaTeX export 2010-10-29 5:01 ` Noorul Islam K M @ 2010-10-29 6:38 ` Tom Dye 2010-10-29 7:20 ` Nick Dokos 2010-11-13 5:55 ` [Accepted] " Carsten Dominik 2 siblings, 0 replies; 22+ messages in thread From: Tom Dye @ 2010-10-29 6:38 UTC (permalink / raw 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 <carsten.dominik@gmail.com> writes: > >> On Oct 29, 2010, at 5:22 AM, Jambunathan K wrote: >> >>> "Thomas S. Dye" <tsd@tsdye.com> 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" <tsd@tsdye.com> writes: >>>>> >>>>>> On Oct 28, 2010, at 12:35 PM, Nick Dokos wrote: >>>>>> >>>>>>> Thomas S. Dye <tsd@tsdye.com> 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 <schulte.eric@gmail.com> >>>>>> 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: Internal links in LaTeX export 2010-10-29 5:01 ` Noorul Islam K M 2010-10-29 6:38 ` Tom Dye @ 2010-10-29 7:20 ` Nick Dokos 2010-10-29 7:51 ` Noorul Islam 2010-11-13 5:55 ` [Accepted] " Carsten Dominik 2 siblings, 1 reply; 22+ messages in thread From: Nick Dokos @ 2010-10-29 7:20 UTC (permalink / raw To: Noorul Islam K M Cc: nicholas.dokos, emacs-orgmode, Jambunathan K, Carsten Dominik Noorul Islam K M <noorul@noorul.com> wrote: > Carsten Dominik <carsten.dominik@gmail.com> writes: > > > On Oct 29, 2010, at 5:22 AM, Jambunathan K wrote: > > > >> "Thomas S. Dye" <tsd@tsdye.com> 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 > I don't think this patch is correct. I just pulled "Org-mode version 7.01trans (release_7.01h.882.g750f.dirty)" to get Carsten's revert of the previous patch and tested against the following org file: --8<---------------cut here---------------start------------->8--- * Foo Here is a link to section Bar: [[Bar]] * Bar And here is an external link: [[http://www.google.com][google]] --8<---------------cut here---------------end--------------->8--- When I export to LaTeX, I get this: --8<---------------cut here---------------start------------->8--- ... \section{Foo} \label{sec-1} Here is a link to section Bar: \hyperref[sec-2]{Bar} \section{Bar} \label{sec-2} And here is an external link: \href{http://www.google.com}{google} ... --8<---------------cut here---------------end--------------->8--- which I believe is correct - Tom? After I apply the patch, I get this LaTeX output: --8<---------------cut here---------------start------------->8--- ... \section{Foo} \label{sec-1} Here is a link to section Bar: \href{sec-2}{Bar} \section{Bar} \label{sec-2} And here is an external link: \href{http://www.google.com}{google} ... --8<---------------cut here---------------end--------------->8--- which is wrong. Did you test the patch and if so, how? Nick ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: Internal links in LaTeX export 2010-10-29 7:20 ` Nick Dokos @ 2010-10-29 7:51 ` Noorul Islam 2010-10-29 8:34 ` Nick Dokos 0 siblings, 1 reply; 22+ messages in thread From: Noorul Islam @ 2010-10-29 7:51 UTC (permalink / raw To: nicholas.dokos; +Cc: emacs-orgmode, Jambunathan K, Carsten Dominik On Fri, Oct 29, 2010 at 12:50 PM, Nick Dokos <nicholas.dokos@hp.com> wrote: > Noorul Islam K M <noorul@noorul.com> wrote: > >> Carsten Dominik <carsten.dominik@gmail.com> writes: >> >> > On Oct 29, 2010, at 5:22 AM, Jambunathan K wrote: >> > >> >> "Thomas S. Dye" <tsd@tsdye.com> 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 >> > > I don't think this patch is correct. I just pulled "Org-mode version > 7.01trans (release_7.01h.882.g750f.dirty)" to get Carsten's revert of > the previous patch and tested against the following org file: > > --8<---------------cut here---------------start------------->8--- > > * Foo > Here is a link to section Bar: [[Bar]] > > * Bar > > And here is an external link: [[http://www.google.com][google]] > --8<---------------cut here---------------end--------------->8--- > > When I export to LaTeX, I get this: > > --8<---------------cut here---------------start------------->8--- > ... > \section{Foo} > \label{sec-1} > > Here is a link to section Bar: \hyperref[sec-2]{Bar} > \section{Bar} > \label{sec-2} > > > And here is an external link: \href{http://www.google.com}{google} > ... > --8<---------------cut here---------------end--------------->8--- > > which I believe is correct - Tom? > > After I apply the patch, I get this LaTeX output: > > --8<---------------cut here---------------start------------->8--- > ... > \section{Foo} > \label{sec-1} > > Here is a link to section Bar: \href{sec-2}{Bar} > \section{Bar} > \label{sec-2} > > > And here is an external link: \href{http://www.google.com}{google} > ... > --8<---------------cut here---------------end--------------->8--- > > which is wrong. Did you test the patch and if so, how? > For the same thing I get this --8<---------------cut here---------------end--------------->8-- \section{Foo} \label{sec-1} Here is a link to section Bar: \hyperref[sec-2]{Bar} \section{Bar} \label{sec-2} And here is an external link: \href{http://www.google.com}{google} --8<---------------cut here---------------end--------------->8-- Thanks and Regards Noorul ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: Internal links in LaTeX export 2010-10-29 7:51 ` Noorul Islam @ 2010-10-29 8:34 ` Nick Dokos 0 siblings, 0 replies; 22+ messages in thread From: Nick Dokos @ 2010-10-29 8:34 UTC (permalink / raw To: Noorul Islam; +Cc: nicholas.dokos, emacs-orgmode, Carsten Dominik Noorul Islam <noorul@noorul.com> wrote: > > For the same thing I get this > > > \section{Foo} > \label{sec-1} > > Here is a link to section Bar: \hyperref[sec-2]{Bar} > \section{Bar} > \label{sec-2} > > > And here is an external link: \href{http://www.google.com}{google} > > You are right and I'm wrong: M-x org-reload just won't cut it in this case: changed defvars/defcustoms do not change values. And BTW, that's also a flaw in my earlier description of git bisect: org-reload is not enough in general - a new emacs needs to be started to pick up these changes. Time to get some sleep. Sorry for the noise, Nick ^ permalink raw reply [flat|nested] 22+ messages in thread
* [Accepted] Re: Internal links in LaTeX export 2010-10-29 5:01 ` Noorul Islam K M 2010-10-29 6:38 ` Tom Dye 2010-10-29 7:20 ` Nick Dokos @ 2010-11-13 5:55 ` Carsten Dominik 2 siblings, 0 replies; 22+ messages in thread From: Carsten Dominik @ 2010-11-13 5:55 UTC (permalink / raw To: emacs-orgmode Patch 349 (http://patchwork.newartisans.com/patch/349/) is now "Accepted". Maintainer comment: No comment This relates to the following submission: http://mid.gmane.org/%3C871v79h9t3.fsf%40noorul.maa.corp.collab.net%3E Here is the original message containing the patch: > Content-Type: text/plain; charset="utf-8" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Subject: [Orgmode] Re: Internal links in LaTeX export > Date: Fri, 29 Oct 2010 10:01:12 -0000 > From: Noorul Islam <noorul@noorul.com> > X-Patchwork-Id: 349 > Message-Id: <871v79h9t3.fsf@noorul.maa.corp.collab.net> > To: Carsten Dominik <carsten.dominik@gmail.com> > Cc: =?utf-8?Q?S=C3=A9bastien?=@gnu.org, Vauban <wxhgmqzgwmuf@spammotel.com>, > nicholas.dokos@hp.com, emacs-orgmode@gnu.org, > Jambunathan K <kjambunathan@gmail.com> > > Carsten Dominik <carsten.dominik@gmail.com> writes: > > > On Oct 29, 2010, at 5:22 AM, Jambunathan K wrote: > > > >> "Thomas S. Dye" <tsd@tsdye.com> 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 > > >> > >> * 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" <tsd@tsdye.com> writes: > >>>> > >>>>> On Oct 28, 2010, at 12:35 PM, Nick Dokos wrote: > >>>>> > >>>>>> Thomas S. Dye <tsd@tsdye.com> 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 <schulte.eric@gmail.com> > >>>>> 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 > > > 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 > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: Internal links in LaTeX export 2010-10-29 0:20 ` Thomas S. Dye 2010-10-29 1:30 ` Jambunathan K @ 2010-10-29 3:28 ` Nick Dokos 2010-10-29 5:46 ` Nick Dokos 1 sibling, 1 reply; 22+ messages in thread From: Nick Dokos @ 2010-10-29 3:28 UTC (permalink / raw To: Thomas S. Dye Cc: Sébastien Vauban, nicholas.dokos, emacs-orgmode, Jambunathan K Thomas S. Dye <tsd@tsdye.com> wrote: > ... > I did hit on a revision that was neither good nor bad: > > commit 8562273b272024a630a582b0e1b94c481d8abeec > Author: Eric Schulte <schulte.eric@gmail.com> > 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 > Yeah, that was the error that stopped me cold as well, although I hit it on a different commit (I think) - there must be a way to get around the problem but it certainly makes things more difficult. I imagine the way to go is to find a commit before this error was introduced and a commit after it was fixed and try those with your problem: it might allow you to bypass the problematic range (in which case, you might be able to continue bisecting all the way to the end), or it might limit the bad commit to this range - the latter is still valuable to know but certainly not as definitive as "this is the bad commit". And in any case, all of this would fall into the "advanced" appendix in the git bisection book. Sorry it didn't pan out but I hope that you had fun digging, Nick ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: Internal links in LaTeX export 2010-10-29 3:28 ` Nick Dokos @ 2010-10-29 5:46 ` Nick Dokos 2010-10-29 10:17 ` Jambunathan K 0 siblings, 1 reply; 22+ messages in thread From: Nick Dokos @ 2010-10-29 5:46 UTC (permalink / raw To: nicholas.dokos; +Cc: Sébastien Vauban, emacs-orgmode, Jambunathan K Nick Dokos <nicholas.dokos@hp.com> wrote: > Thomas S. Dye <tsd@tsdye.com> wrote: > > > ... > > I did hit on a revision that was neither good nor bad: > > > > commit 8562273b272024a630a582b0e1b94c481d8abeec > > Author: Eric Schulte <schulte.eric@gmail.com> > > 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 > > > > Yeah, that was the error that stopped me cold as well, although I hit it In case it wasn't clear, that was a couple of days ago on a different bisection, while chasing another problem. > on a different commit (I think) - there must be a way to get around the > problem but it certainly makes things more difficult. I imagine the way > to go is to find a commit before this error was introduced and a commit > after it was fixed and try those with your problem: it might allow you > to bypass the problematic range (in which case, you might be able to > continue bisecting all the way to the end), or it might limit the bad > commit to this range - the latter is still valuable to know but > certainly not as definitive as "this is the bad commit". And in any > case, all of this would fall into the "advanced" appendix in the git > bisection book. > > Sorry it didn't pan out but I hope that you had fun digging, > In this instance, I actually bisected it down to the bad commit that Jambunathan K. identified (and Carsten reverted). I guess I was lucky in the sense that I pulled a couple of days ago, so HEAD was 851 commits ahead of 7.01h and the bisection proceeded as follows: release_7.01h-851-gfd9e933 - bad release_7.01h - good release_7.01h-425-gfea9072 - good release_7.01h-638-gd9e4469 - good release_7.01h-744-g3d2aec3 - bad <<<<<< release_7.01h-691-g6b9782d - good release_7.01h-717-gc9bb51e - bad release_7.01h-704-g935c310 - good release_7.01h-710-gc9b0176 - good release_7.01h-713-g8820a25 - good release_7.01h-715-gf5918bd - bad release_7.01h-714-gdf5894c - good and it identified release_7.01h-715-gf5918bd as the first bad commit. From the previous investigation, I know that the result-type error that you ran into, was introduced after commit 750 and resolved before commit 800 (using release_7.01h as the origin), so once I got to the <<<< point above, I was safe: I couldn't possibly end up in the problematic range. OTOH, if you start from say 810, the sequence would be 405, 608, 709, 759 (or so) and you end up in the problematic range, which is probably what happened to you. BTW, I got the bisection sequence (after the fact) with git bisect log and then translated the (40-hex digit SHA1 form) commits to the more readable form above using git describe <commit> This is all 20/20 hindsight of course, but I hope interesting enough as a curiosity. Nick ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: Internal links in LaTeX export 2010-10-29 5:46 ` Nick Dokos @ 2010-10-29 10:17 ` Jambunathan K 2010-10-30 19:56 ` suvayu ali 0 siblings, 1 reply; 22+ messages in thread From: Jambunathan K @ 2010-10-29 10:17 UTC (permalink / raw To: nicholas.dokos; +Cc: emacs-orgmode Nick I hunted down the bug with heuristics. Speaking of bisections, > In this instance, I actually bisected it down to the bad commit that > Jambunathan K. identified (and Carsten reverted). I guess I was lucky > in the sense that I pulled a couple of days ago, so HEAD was 851 > commits ahead of 7.01h and the bisection proceeded as follows: > > release_7.01h-851-gfd9e933 - bad > release_7.01h - good > release_7.01h-425-gfea9072 - good > release_7.01h-638-gd9e4469 - good > release_7.01h-744-g3d2aec3 - bad <<<<<< > release_7.01h-691-g6b9782d - good > release_7.01h-717-gc9bb51e - bad > release_7.01h-704-g935c310 - good > release_7.01h-710-gc9b0176 - good > release_7.01h-713-g8820a25 - good > release_7.01h-715-gf5918bd - bad > release_7.01h-714-gdf5894c - good > > and it identified release_7.01h-715-gf5918bd as the first bad > commit. From the previous investigation, I know that the result-type > error that you ran into, was introduced after commit 750 and resolved > before commit 800 (using release_7.01h as the origin), so once I got to > the <<<< point above, I was safe: I couldn't possibly end up in the > problematic range. OTOH, if you start from say 810, the sequence would > be 405, 608, 709, 759 (or so) and you end up in the problematic range, > which is probably what happened to you. > > BTW, I got the bisection sequence (after the fact) with > > git bisect log > > and then translated the (40-hex digit SHA1 form) commits to the more > readable form above using > > git describe <commit> > Git bisection is wonderful. It is a bit of drag nevertheless - Tag, Test, Tag, Test Tag, Test .... Ah, finally done (or undecided) In the case at hand, it is clear that the issue is with either org-latex.el (or org-exp.el). It is most likely the former because the bug description is backend-specific. I wish there was a way to say this: - "do bisection on the revisions where org-latex.el changed (as opposed to revisions where HEAD moved)" The candidate commits then would have reduced to 30 odd commits rather than 851 that one had to contend with. Hypothetically speaking, even this improved bisection would have left me confused at somepoint because of the churn 'pdflatex & texi2dvi' churn that pdf export process went through in recent times. Jambunathan K. > This is all 20/20 hindsight of course, but I hope interesting > enough as a curiosity. > > Nick ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: Internal links in LaTeX export 2010-10-29 10:17 ` Jambunathan K @ 2010-10-30 19:56 ` suvayu ali 2010-11-02 7:35 ` Jambunathan K 0 siblings, 1 reply; 22+ messages in thread From: suvayu ali @ 2010-10-30 19:56 UTC (permalink / raw To: Jambunathan K; +Cc: nicholas.dokos, emacs-orgmode Hi Jambunathan On 29 October 2010 03:17, Jambunathan K <kjambunathan@gmail.com> wrote: > wish there was a way to say this: > > - "do bisection on the revisions where org-latex.el changed (as opposed > to revisions where HEAD moved)" > > The candidate commits then would have reduced to 30 odd commits rather > than 851 that one had to contend with. > I see in `man git-bisect' a form like this is shown as valid, git bisect start [<bad> [<good>...]] [--] [<paths>...] Wouldn't that do the job? PS: I haven't tried this, just referring to the docs. -- Suvayu Open source is the future. It sets us free. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: Internal links in LaTeX export 2010-10-30 19:56 ` suvayu ali @ 2010-11-02 7:35 ` Jambunathan K 0 siblings, 0 replies; 22+ messages in thread From: Jambunathan K @ 2010-11-02 7:35 UTC (permalink / raw To: suvayu ali; +Cc: nicholas.dokos, emacs-orgmode suvayu ali <fatkasuvayu+linux@gmail.com> writes: > Hi Jambunathan > > On 29 October 2010 03:17, Jambunathan K <kjambunathan@gmail.com> wrote: >> wish there was a way to say this: >> >> - "do bisection on the revisions where org-latex.el changed (as opposed >> to revisions where HEAD moved)" >> >> The candidate commits then would have reduced to 30 odd commits rather >> than 851 that one had to contend with. >> > > I see in `man git-bisect' a form like this is shown as valid, > > git bisect start [<bad> [<good>...]] [--] [<paths>...] > > Wouldn't that do the job? > Indeed. One more tools in the armour. ,---- [Example from Git Bisect Manual] | Cutting down bisection by giving more parameters to bisect start | | You can further cut down the number of trials, if you know what | part of the tree is involved in the problem you are tracking | down, by specifying path parameters when issuing the bisect start | command: | | $ git bisect start -- arch/i386 include/asm-i386 `---- Jambunathan K. ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2010-11-13 5:55 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-10-28 20:06 Internal links in LaTeX export Thomas S. Dye 2010-10-28 20:18 ` Sébastien Vauban 2010-10-28 20:44 ` Thomas S. Dye 2010-10-28 21:01 ` Jambunathan K 2010-10-28 21:19 ` Thomas S. Dye 2010-10-28 22:35 ` Nick Dokos 2010-10-29 0:20 ` Thomas S. Dye 2010-10-29 1:30 ` Jambunathan K 2010-10-29 2:04 ` Thomas S. Dye 2010-10-29 3:22 ` [SOLVED] " Jambunathan K 2010-10-29 3:58 ` Carsten Dominik 2010-10-29 5:01 ` Noorul Islam K M 2010-10-29 6:38 ` Tom Dye 2010-10-29 7:20 ` Nick Dokos 2010-10-29 7:51 ` Noorul Islam 2010-10-29 8:34 ` Nick Dokos 2010-11-13 5:55 ` [Accepted] " Carsten Dominik 2010-10-29 3:28 ` Nick Dokos 2010-10-29 5:46 ` Nick Dokos 2010-10-29 10:17 ` Jambunathan K 2010-10-30 19:56 ` suvayu ali 2010-11-02 7:35 ` Jambunathan K
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.