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
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
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
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
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
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
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
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
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
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
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
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
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