Links in tables and LaTeX export

Links in tables and LaTeX export

[Thomas S. Dye]

Aloha all,

Links in tables have changed recently.

I have this link definition:

#+source: define-citep-link
#+begin_src emacs-lisp :results silent
    (org-add-link-type 
     "citep" 'ebib
     (lambda (path desc format)
       (cond
        ((eq format 'html)
         (format "(<cite>%s</cite>)" path))
        ((eq format 'latex)
         (if (or (not desc) (equal 0 (search "citep:" desc)))
               (format "\\citep{%s}" path)
               (format "\\citep[%s]{%s}" desc path)
  )))))
#+end_src

Links outside of a table export correctly:

[[citep:wagner90][598]] exports to \citep[598]{wagner}

Inside a table the same link exports like this:

[[citep:wagner90]\footnote{DEFINITION NOT FOUND: 598}] 

I'm using Org-mode version 7.5 (release_7.5.566.g8d45).

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: Links in tables and LaTeX export

[Nick Dokos]

Thomas S. Dye <tsd@tsdye.com> wrote:

> Aloha all,
> 
> Links in tables have changed recently.
> 
> I have this link definition:
> 
> #+source: define-citep-link
> #+begin_src emacs-lisp :results silent
>     (org-add-link-type 
>      "citep" 'ebib
>      (lambda (path desc format)
>        (cond
>         ((eq format 'html)
>          (format "(<cite>%s</cite>)" path))
>         ((eq format 'latex)
>          (if (or (not desc) (equal 0 (search "citep:" desc)))
>                (format "\\citep{%s}" path)
>                (format "\\citep[%s]{%s}" desc path)
>   )))))
> #+end_src
> 
> Links outside of a table export correctly:
> 
> [[citep:wagner90][598]] exports to \citep[598]{wagner}
> 
> Inside a table the same link exports like this:
> 
> [[citep:wagner90]\footnote{DEFINITION NOT FOUND: 598}] 
> 
> I'm using Org-mode version 7.5 (release_7.5.566.g8d45).
> 

Reproduced and bisected it to the following commit:

,----
| ab9c52fd7911763a903a3d673dce2876ada9e551 is the first bad commit
| commit ab9c52fd7911763a903a3d673dce2876ada9e551
| Author: Nicolas Goaziou <n.goaziou@gmail.com>
| Date:   Wed May 11 18:02:15 2011 +0200
| 
|     Improve footnotes handling in exporters
|     
|     * lisp/org-exp.el (org-export-footnotes-markers,
|       org-export-footnotes-data): new variables.
|       (org-export-preprocess-string): use a more explicit argument.
|     
|     * lisp/org-html.el (org-export-as-html): initialize new variables.
|     
|     * lisp/org-docbook.el (org-export-as-docbook): initialize new variables.
|     
|     * lisp/org-latex.el (org-export-latex-footmark-seen): new variable.
|       (org-export-as-latex): initialize new variables.
|       (org-export-latex-preprocess): allow to export two or more footnotes
|       in a row. Also permit to have footnotes refering to previously
|       defined footnotes.
|     
|     * lisp/org-ascii.el (org-export-as-ascii): feed org-footnote-normalize
|       with data so it can normalize footnotes before first headline, or
|       footnotes with their definition outside exported region.
| 
| :040000 040000 1fb022cb1d6f845963e80eeb3e165b77c0371f14 9233dfeee6e7889cc389181aaa6995b381fc49c6 M	lisp
`----

Nick

Re: Links in tables and LaTeX export

[Bastien]

Thanks to both of you for the report.

Nicolas, would you have time to take care of this today?  If so, I can
delay 7.6 a bit.  Otherwise I will release 7.6 and we can make a 7.6.1
release shortly with such major bugfixes, then push 7.6.1 to Emacs
trunk.

Best,

-- 
 Bastien

Re: Links in tables and LaTeX export

[Nicolas Goaziou]

Hello,

Bastien <bzg@altern.org> writes:

> Thanks to both of you for the report.
>
> Nicolas, would you have time to take care of this today? 

I'm on it right now.

Regards,

-- 
Nicolas Goaziou

Re: Links in tables and LaTeX export

[Nicolas Goaziou]

Hello,

tsd@tsdye.com (Thomas S. Dye) writes:

> Aloha all,
>
> Links in tables have changed recently.
>
> I have this link definition:
>
> #+source: define-citep-link
> #+begin_src emacs-lisp :results silent
>     (org-add-link-type 
>      "citep" 'ebib
>      (lambda (path desc format)
>        (cond
>         ((eq format 'html)
>          (format "(<cite>%s</cite>)" path))
>         ((eq format 'latex)
>          (if (or (not desc) (equal 0 (search "citep:" desc)))
>                (format "\\citep{%s}" path)
>                (format "\\citep[%s]{%s}" desc path)
>   )))))
> #+end_src
>
> Links outside of a table export correctly:
>
> [[citep:wagner90][598]] exports to \citep[598]{wagner}
>
> Inside a table the same link exports like this:
>
> [[citep:wagner90]\footnote{DEFINITION NOT FOUND: 598}] 

I think I have fixed it in master. Could you confirm this?

Regards,

-- 
Nicolas Goaziou

Re: Links in tables and LaTeX export

[Nick Dokos]

Nicolas Goaziou <n.goaziou@gmail.com> wrote:

> Hello,
> 
> tsd@tsdye.com (Thomas S. Dye) writes:
> 
> > Aloha all,
> >
> > Links in tables have changed recently.
> >
> > I have this link definition:
> >
> > #+source: define-citep-link
> > #+begin_src emacs-lisp :results silent
> >     (org-add-link-type 
> >      "citep" 'ebib
> >      (lambda (path desc format)
> >        (cond
> >         ((eq format 'html)
> >          (format "(<cite>%s</cite>)" path))
> >         ((eq format 'latex)
> >          (if (or (not desc) (equal 0 (search "citep:" desc)))
> >                (format "\\citep{%s}" path)
> >                (format "\\citep[%s]{%s}" desc path)
> >   )))))
> > #+end_src
> >
> > Links outside of a table export correctly:
> >
> > [[citep:wagner90][598]] exports to \citep[598]{wagner}
> >
> > Inside a table the same link exports like this:
> >
> > [[citep:wagner90]\footnote{DEFINITION NOT FOUND: 598}] 
> 
> I think I have fixed it in master. Could you confirm this?
> 

Assuming my simple test is representative, this seems fixed: I get
expected results with a link in either normal text or in a table cell.
I have not tried any other contexts (e.g. inside a list).

Nick

Re: Links in tables and LaTeX export

[Thomas S. Dye]

Aloha Nicolas,

I can confirm that the formerly broken links in my tables work with
Org-mode version 7.5 (release_7.5.596.gea215).

All the best,
Tom

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> tsd@tsdye.com (Thomas S. Dye) writes:
>
>> Aloha all,
>>
>> Links in tables have changed recently.
>>
>> I have this link definition:
>>
>> #+source: define-citep-link
>> #+begin_src emacs-lisp :results silent
>>     (org-add-link-type 
>>      "citep" 'ebib
>>      (lambda (path desc format)
>>        (cond
>>         ((eq format 'html)
>>          (format "(<cite>%s</cite>)" path))
>>         ((eq format 'latex)
>>          (if (or (not desc) (equal 0 (search "citep:" desc)))
>>                (format "\\citep{%s}" path)
>>                (format "\\citep[%s]{%s}" desc path)
>>   )))))
>> #+end_src
>>
>> Links outside of a table export correctly:
>>
>> [[citep:wagner90][598]] exports to \citep[598]{wagner}
>>
>> Inside a table the same link exports like this:
>>
>> [[citep:wagner90]\footnote{DEFINITION NOT FOUND: 598}] 
>
> I think I have fixed it in master. Could you confirm this?
>
> Regards,

-- 
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com

Re: Links in tables and LaTeX export

[Nick Dokos]

Thomas S. Dye <tsd@tsdye.com> wrote:

> I can confirm that the formerly broken links in my tables work with
> Org-mode version 7.5 (release_7.5.596.gea215).
> 

I'm puzzled (and a bit worried about the integrity of my tree): I pulled
a short while ago and ''git describe HEAD'' says:

      baseline-490-gde0fcdf

so it seems I have an extra tag between release_7.5 and HEAD and
although I have no idea where it came from, it does not seem to be much
of a problem[fn:1], since I can get things relative to release_7.5:

      $ git describe --long  --match release_7.5 HEAD
      release_7.5-579-gde0fcdf

But why do I have 579 commits since then and you have 596 (and the HEADs
have different SHA1s)? Are you applying local mods? That would explain
the discrepancy in the commit count, as well as the discrepancy in the
SHA1, but if so, why isn't your version marked ``dirty''?

Just trying to understand,
Nick

Footnotes:

[fn:1] For the record, in my tree, ``baseline'' is related to
release_7.5 like so:

      $ git describe --match release_7.5 --long baseline
      release_7.5-89-g3d802ee

Re: Links in tables and LaTeX export

[Bernt Hansen]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Thomas S. Dye <tsd@tsdye.com> wrote:
>
>> I can confirm that the formerly broken links in my tables work with
>> Org-mode version 7.5 (release_7.5.596.gea215).
>> 
>
> I'm puzzled (and a bit worried about the integrity of my tree): I pulled
> a short while ago and ''git describe HEAD'' says:
>
>       baseline-490-gde0fcdf
>
> so it seems I have an extra tag between release_7.5 and HEAD and
> although I have no idea where it came from, it does not seem to be much
> of a problem[fn:1], since I can get things relative to release_7.5:
>
>       $ git describe --long  --match release_7.5 HEAD
>       release_7.5-579-gde0fcdf
>
> But why do I have 579 commits since then and you have 596 (and the HEADs
> have different SHA1s)? Are you applying local mods? That would explain
> the discrepancy in the commit count, as well as the discrepancy in the
> SHA1, but if so, why isn't your version marked ``dirty''?
>
> Just trying to understand,

Hi Nick,

The tree is only marked 'dirty' if you have uncommitted changes in your
working tree.  If other commits were merged in with master in their
repository (ie. they made local commits and then did git pull which is
fetch + merge on top of their local commits they'll have their commits
in the history and it will change all of the subsequent SHA1s)

I have the same tree as you - my current origin/master is 

--8<---------------cut here---------------start------------->8---
bernt@gollum:~/git/org-mode$ git describe origin/master
release_7.5-580-g301b345
bernt@gollum:~/git/org-mode$ git describe origin/master^
release_7.5-579-gde0fcdf
--8<---------------cut here---------------end--------------->8---

and one commit before my current head is the same SHA1 that you have.

So... your repository is good. :)

git describe will use the closest tag (in your case 'baseline'.  You
can just remove the baseline tag from your repository if you don't want
it.  If it's an exported tag in a repository you fetch from it will be
recreated on a future fetch.  Maybe it came from some repository other
than origin?

-- 
Bernt

Re: Links in tables and LaTeX export

[Nick Dokos]

Bernt Hansen <bernt@norang.ca> wrote:

> Nick Dokos <nicholas.dokos@hp.com> writes:
> 
> > Thomas S. Dye <tsd@tsdye.com> wrote:
> >
> >> I can confirm that the formerly broken links in my tables work with
> >> Org-mode version 7.5 (release_7.5.596.gea215).
> >> 
> >
> > I'm puzzled (and a bit worried about the integrity of my tree): I pulled
> > a short while ago and ''git describe HEAD'' says:
> >
> >       baseline-490-gde0fcdf
> >
> > so it seems I have an extra tag between release_7.5 and HEAD and
> > although I have no idea where it came from, it does not seem to be much
> > of a problem[fn:1], since I can get things relative to release_7.5:
> >
> >       $ git describe --long  --match release_7.5 HEAD
> >       release_7.5-579-gde0fcdf
> >
> > But why do I have 579 commits since then and you have 596 (and the HEADs
> > have different SHA1s)? Are you applying local mods? That would explain
> > the discrepancy in the commit count, as well as the discrepancy in the
> > SHA1, but if so, why isn't your version marked ``dirty''?
> >
> > Just trying to understand,
> 
> Hi Nick,
> 
> The tree is only marked 'dirty' if you have uncommitted changes in your
> working tree.  If other commits were merged in with master in their
> repository (ie. they made local commits and then did git pull which is
> fetch + merge on top of their local commits they'll have their commits
> in the history and it will change all of the subsequent SHA1s)
> 

Ah, OK: for some reason, I thought "dirty" meant "not pristine" (and I guess
it does in some sense, but not here :-) ).

> I have the same tree as you - my current origin/master is 
> 
> bernt@gollum:~/git/org-mode$ git describe origin/master
> release_7.5-580-g301b345
> bernt@gollum:~/git/org-mode$ git describe origin/master^
> release_7.5-579-gde0fcdf
> 
> and one commit before my current head is the same SHA1 that you have.
> 
> So... your repository is good. :)
> 

Phew! 

> git describe will use the closest tag (in your case 'baseline'.  You
> can just remove the baseline tag from your repository if you don't want
> it.  If it's an exported tag in a repository you fetch from it will be
> recreated on a future fetch.  Maybe it came from some repository other
> than origin?
> 

Maybe - or maybe I created it and I don't remember (so what's new?).
I guess I'll play whack-a-mole with it and see.

From what I gather, Tom is getting additional merge commits every time
he pulls (which accounts for the extras and the different SHA1). I think
I used to have that problem, but I don't any more, and I don't remember
(so what's new?)  how it came about and/or I resolved it. Any ideas
about that? I may have just deleted the master branch and recreated it.

Thanks for checking and thanks for the pointers,
Nick

Re: Links in tables and LaTeX export

[Bernt Hansen]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Bernt Hansen <bernt@norang.ca> wrote:
>
>> Nick Dokos <nicholas.dokos@hp.com> writes:
>> 
>> > Thomas S. Dye <tsd@tsdye.com> wrote:
>> >
> From what I gather, Tom is getting additional merge commits every time
> he pulls (which accounts for the extras and the different SHA1). I think
> I used to have that problem, but I don't any more, and I don't remember
> (so what's new?)  how it came about and/or I resolved it. Any ideas
> about that? I may have just deleted the master branch and recreated
> it.

Tom should run 
gitk
on his master branch - then the merge commits (if that is what they
are) will be very obvious.

If Tom create even a single commit in the past and then subsequently
added new commits from origin/master with git pull then he'll get an
extra merge commit for everytime he updates.

There is a write up on worg about how to keep local commits on top of
origin/master by rebasing the local commits each time git pull is run.
http://orgmode.org/worg/org-faq.html#keeping-local-changes-current-with-Org-mode-development

Assuming his has local commits buried in his history somewhere Tom can
'fix' it by doing

  $ git checkout master
  $ git reset --hard origin/master
  $ git cherry-pick <whatever local commits he wants to keep>

so the new commits are on top of origin/master, and set his master
branch to automatically rebase on pulls as described in the link above.

HTH,
-- 
Bernt

Re: Links in tables and LaTeX export

[Nick Dokos]

Bernt Hansen <bernt@norang.ca> wrote:

> Assuming his has local commits buried in his history somewhere Tom can
> 'fix' it by doing
> 
>   $ git checkout master
>   $ git reset --hard origin/master
>   $ git cherry-pick <whatever local commits he wants to keep>
> 
> so the new commits are on top of origin/master, and set his master
> branch to automatically rebase on pulls as described in the link above.
> 

Yup, now that you mention it, I think the first two steps is how I recovered
(I try to keep a pristine master and do local work in branches, but I
must have goofed up my master branch in that instance).

Thanks,
Nick

Re: Links in tables and LaTeX export

[Thomas S. Dye]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Bernt Hansen <bernt@norang.ca> wrote:
>
>> Assuming his has local commits buried in his history somewhere Tom can
>> 'fix' it by doing
>> 
>>   $ git checkout master
>>   $ git reset --hard origin/master
>>   $ git cherry-pick <whatever local commits he wants to keep>
>> 
>> so the new commits are on top of origin/master, and set his master
>> branch to automatically rebase on pulls as described in the link above.
>> 
>
> Yup, now that you mention it, I think the first two steps is how I recovered
> (I try to keep a pristine master and do local work in branches, but I
> must have goofed up my master branch in that instance).
>
> Thanks,
> Nick
>
>

Aloha Nick and Bernt,

Thanks much for the explanation.  git reset --hard origin/master appears
to have restored a pristine tree.  I pulled just now and didn't generate
my own commit in the process, so with a little discretion I can keep it
that way.

All the best,
Tom

-- 
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com