bug in org-element-footnote-definition-parser?

bug in org-element-footnote-definition-parser?

[Mark Edgington]

[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]

I have encountered the following error message when trying to export
to latex the attached example org file:

org-element-footnote-definition-parser: Invalid search bound (wrong
side of point)

What is curious is that changing the number of "xxxx"'s in [fn:1] to 2
instead of 3 allows it to compile.  Likewise, just changing the number
of 'words' in the second macro (5th column of the table) also can
eliminate the error and allow the document to compile.  Also, getting
rid of the #+BEGIN line also allows it to compile...

I have omitted the tree which contains data for generating the table,
which isn't relevant for reproducing the error / bug.  All of the
above comments are based on using git rev. 95416856 (Dec 26).

I also recently updated to d310a87605 (Jan 8), and instead get the error:

byte-code: Wrong number of arguments: #[(tree data) ...[binary
omitted]... [tree cl-struct-avl-tree--tags data avl-tree--do-delete 0
error "avl-tree--cmpfun accessing a non-avl-tree-" 2
"avl-tree--dummyroot accessing a non-avl-tree-" 1] 5
("/usr/share/emacs/23.3/lisp/emacs-lisp/avl-tree.elc" . 14229)], 4

Is there something wrong with my org-file? -- it seems like it
shouldn't be so hard to get it to compile, and that the errors
shouldn't be so obscure.

Regards,

Mark

[-- Attachment #2: fails_to_export_as_latex.org --]
[-- Type: text/x-org, Size: 1219 bytes --]

* Schedule
#+LATEX: {}\begin{landscape}
xxxxx xxxxx xxxxxx.
#+BEGIN: propview :id "sched_table" :defaultval "" :conds ((not (string= A ""))) :cols (A B C D E) :noquote t :colnames ("xxxx x" xxx "xxxxxxxx xxxxxxx" "xxxxxxxx[fn:1]" "xxxxxxxxx xxxxxxxxxxx / xxxxxxxx[fn:2]")
#+ATTR_LaTeX: :environment longtable :align lllp{3cm}l
| xxxx x | xxx | xxxxxxxx xxxxxxx      | xxxxxxxx[fn:1] | xxxxxxxxx xxxxxxxxxxx / xxxxxxxx[fn:2]             |
|--------+-----+-----------------------+----------------+----------------------------------------------------|
|      x | x   | xxxx {{{c(xxxxxxx)}}} |          xxxxx | xxxxx {{{c(xxx xxxxxx xxxxx xxx)}}} |
|--------+-----+-----------------------+----------------+----------------------------------------------------|
#+END:
#+LATEX: \end{landscape}

[fn:1] xxxx xxxx xxxx
[fn:2] xx xx 


* File Options                                                      :ARCHIVE:
** Export
#+LaTeX_HEADER: \usepackage[margin=0.75in]{geometry}
#+LaTeX_HEADER: \setlength{\marginparwidth}{1cm}
#+LaTeX_HEADER: \usepackage{lscape}
#+OPTIONS: toc:nil
#+EXPORT_SELECT_TAGS: export
#+EXPORT_EXCLUDE_TAGS: noexport
#+OPTIONS: arch:nil
#+OPTIONS: ^:{}
** Macros
#+MACRO: c 

Re: bug in org-element-footnote-definition-parser?

[Nicolas Goaziou]

Hello,

Mark Edgington <edgimar@gmail.com> writes:

> I have encountered the following error message when trying to export
> to latex the attached example org file:
>
> org-element-footnote-definition-parser: Invalid search bound (wrong
> side of point)
>
> What is curious is that changing the number of "xxxx"'s in [fn:1] to 2
> instead of 3 allows it to compile.  Likewise, just changing the number
> of 'words' in the second macro (5th column of the table) also can
> eliminate the error and allow the document to compile.  Also, getting
> rid of the #+BEGIN line also allows it to compile...
>
> I have omitted the tree which contains data for generating the table,
> which isn't relevant for reproducing the error / bug.  All of the
> above comments are based on using git rev. 95416856 (Dec 26).

I cannot reproduce the error in either master or maint branch.

> I also recently updated to d310a87605 (Jan 8), and instead get the error:
>
> byte-code: Wrong number of arguments: #[(tree data) ...[binary
> omitted]... [tree cl-struct-avl-tree--tags data avl-tree--do-delete 0
> error "avl-tree--cmpfun accessing a non-avl-tree-" 2
> "avl-tree--dummyroot accessing a non-avl-tree-" 1] 5
> ("/usr/share/emacs/23.3/lisp/emacs-lisp/avl-tree.elc" . 14229)], 4

You need to restart Emacs. I changed the structure of the cache in
master branch.


Regards,

-- 
Nicolas Goaziou

Re: bug in org-element-footnote-definition-parser?

[Nick Dokos]

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

> Hello,
>
> Mark Edgington <edgimar@gmail.com> writes:
>
>> I have encountered the following error message when trying to export
>> to latex the attached example org file:
>>
>> org-element-footnote-definition-parser: Invalid search bound (wrong
>> side of point)
>>

I 'm not sure but I believe this was a bug in emacs that Eli Zaretskii
fixed recently.  You will need to update your emacs. In the git mirror I
use, the commit appears like this:

commit b2b5f414358a7835b56613f67d2b0278ee804290
Author: Eli Zaretskii <eliz@gnu.org>
Date:   Wed Jan 1 19:44:48 2014 +0200

    Fix bug #16265 with buffer caches when modifying text in indirect buffers.
    
     src/search.c (newline_cache_on_off, find_newline): In indirect
     buffers, use the newline cache of the base buffer.
     src/insdel.c (invalidate_buffer_caches): If BUF is an indirect
     buffer, invalidate the caches of its base buffer.
     src/indent.c (width_run_cache_on_off, compute_motion): In indirect
     buffers, use the width-run cache of the base buffer.
     src/xdisp.c (redisplay_window): When the window displays an indirect
     buffer, and the character widths in the display table have
     changed, invalidate the width-run cache of the corresponding base
     buffer.
     src/fileio.c (Finsert_file_contents): When invalidating the newline
     cache, consider the case of inserting into indirect buffer.
     src/bidi.c (bidi_paragraph_cache_on_off, bidi_find_paragraph_start):
     In indirect buffers, use the paragraph cache of the base buffer.

Nick

Re: bug in org-element-footnote-definition-parser?

[Mark Edgington]

Nick Dokos <ndokos <at> gmail.com> writes:

> 
> Nicolas Goaziou <n.goaziou <at> gmail.com> writes:
> 
> > Hello,
> >
> > Mark Edgington <edgimar <at> gmail.com> writes:
> >
> >> I have encountered the following error message when trying to export
> >> to latex the attached example org file:
> >>
> >> org-element-footnote-definition-parser: Invalid search bound (wrong
> >> side of point)
> >>
> 
> I 'm not sure but I believe this was a bug in emacs that Eli Zaretskii
> fixed recently.  You will need to update your emacs. In the git mirror I
> use, the commit appears like this:
> 
> commit b2b5f414358a7835b56613f67d2b0278ee804290
> Author: Eli Zaretskii <eliz <at> gnu.org>
> Date:   Wed Jan 1 19:44:48 2014 +0200

Hi Nick,

I can confirm that updating emacs to 24.3.1 does eliminate the problem. 
But, what this means is that the problem will exist for any users who are
still using Emacs 23 -- and maybe this shouldn't concern anyone since
normally using bleeding-edge org-mode code would coincide with using newer
versions of emacs...

Regards,

Mark

Re: bug in org-element-footnote-definition-parser?

[Nick Dokos]

Mark Edgington <edgimar@gmail.com> writes:

> Nick Dokos <ndokos <at> gmail.com> writes:
>
>> 
>> Nicolas Goaziou <n.goaziou <at> gmail.com> writes:
>> 
>> > Hello,
>> >
>> > Mark Edgington <edgimar <at> gmail.com> writes:
>> >
>> >> I have encountered the following error message when trying to export
>> >> to latex the attached example org file:
>> >>
>> >> org-element-footnote-definition-parser: Invalid search bound (wrong
>> >> side of point)
>> >>
>> 
>> I 'm not sure but I believe this was a bug in emacs that Eli Zaretskii
>> fixed recently.  You will need to update your emacs. In the git mirror I
>> use, the commit appears like this:
>> 
>> commit b2b5f414358a7835b56613f67d2b0278ee804290
>> Author: Eli Zaretskii <eliz <at> gnu.org>
>> Date:   Wed Jan 1 19:44:48 2014 +0200
>
> Hi Nick,
>
> I can confirm that updating emacs to 24.3.1 does eliminate the problem. 
> But, what this means is that the problem will exist for any users who are
> still using Emacs 23 -- and maybe this shouldn't concern anyone since
> normally using bleeding-edge org-mode code would coincide with using newer
> versions of emacs...
>

No, I don't think so: this was a bug in a caching mechanism that was
introduced (disabled) in emacs 24 - it was enabled a couple of months
ago. It should not affect any emacs 23 users.

-- 
Nick