Bug: Export to html and latex fails on these (relatively common) strings [8.2.10 (8.2.10-16-g4c37a9-elpa @ /home/mzimmermann/.emacs.d/elpa/org-20141110/)]

Bug: Export to html and latex fails on these (relatively common) strings [8.2.10 (8.2.10-16-g4c37a9-elpa @ /home/mzimmermann/.emacs.d/elpa/org-20141110/)]

[Milan Zimmermann]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

     http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org-mode mailing list.
------------------------------------------------------------------------

Hi:

Any of the strings in Ex 1) to Ex 4) below, even individually, including the extremely simple example 4, fails the export of the org file to latex and html. The failure appears to happen in the first step (converting to an intermediate format)

*Steps to reproduce:*

- Open a file containing any of the 4 examples (or this text named as org)
- C-c C-e l L 
- Backtrace is attaches

These type of strings on which the failure happens are not unusual to find in documents pasted from mysql or git.

*Ex 1)* - real life example from git output which fails to export

git pull origin master                                 
From github.com:airlift-group/cubifier                                                                                               
\* branch            master     -> FETCH_HEAD                                                                                        
Updating 28d0c00..8d3abef                                                                                                            
Fast-forward                                                                                                                         
grails-app/conf/Aaaa.groovy                        | 10 +++++-----                                                 
src/java/org/Bbbb.java                             | 19 +++++++++++++++----                                        
src/java/org/Cccc.java                             | 30 ++++++++++++++++++++----------  

*Ex 2)* - real life from Mysql output which fails to export (note the misalligned | in the data row - no issues when alligned)

+-------+------------+-----------+
| label | long_label | isEnabled |
+-------+------------+-----------+
|       | 2          |          |
+-------+------------+-----------+


*Ex 3)* Simple example which fails to export

+------------+----------+

*Ex 4)* Simpliest example which fails to export

+------------



Emacs  : GNU Emacs 24.3.1 (x86_64-suse-linux-gnu, GTK+ Version 3.10.4)
 of 2014-01-23 on cloud107
Package: Org-mode version 8.2.10 (8.2.10-16-g4c37a9-elpa @ /home/mzimmermann/.emacs.d/elpa/org-20141110/)

current state:
==============
(setq
 org-tab-first-hook '(org-hide-block-toggle-maybe
                      org-src-native-tab-command-maybe
                      org-babel-hide-result-toggle-maybe
                      org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-default-hook
                          org-babel-speed-command-hook)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-html-format-drawer-function '(lambda (name contents) contents)
 org-table-tab-recognizes-table.el nil
 org-latex-format-inlinetask-function 'ignore
 org-confirm-shell-link-function 'yes-or-no-p
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-emphasis-alist '(("*" bold "<b>" "</b>") ("/" italic "<i>" "</i>")
                      ("_" underline
                       "<span style=\"text-decoration:underline;\">"
                       "</span>")
                      ("=" org-code "<code>" "</code>" verbatim)
                      ("~" org-agenda-restriction-lock "<code>" "</code>"
                       verbatim)
                      ("+" (:strike-through t) "<del>" "</del>"))
 org-support-shift-select t
 org-latex-format-headline-function 'org-latex-format-headline-default-function
 org-startup-indented t
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-latex-format-drawer-function '(lambda (name contents) contents)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
                     org-src-mode-configure-edit-buffer)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-mode-hook '((lambda nil
                  (org-add-hook (quote change-major-mode-hook)
                   (quote org-show-block-all) (quote append) (quote local))
                  )
                 (lambda nil
                  (org-add-hook (quote change-major-mode-hook)
                   (quote org-babel-show-result-all) (quote append)
                   (quote local))
                  )
                 do-org-plot
                 #[nil "\300\301\302\303\304$\207"
                   [org-add-hook change-major-mode-hook org-show-block-all
                    append local]
                   5]
                 #[nil "\300\301\302\303\304$\207"
                   [org-add-hook change-major-mode-hook
                    org-babel-show-result-all append local]
                   5]
                 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-ascii-format-drawer-function '(lambda (name contents width) contents)
 org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
                          org-babel-execute-safely-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
                  org-cycle-hide-inline-tasks org-cycle-show-empty-lines
                  org-optimize-window-after-visibility-change)
 org-babel-tangle-lang-exts '(("lisp" . "lisp") ("java" . "java")
                              ("clojure" . "clj") ("perl" . "pl")
                              ("ruby" . "rb") ("python" . "py")
                              ("emacs-lisp" . "el"))
 org-confirm-elisp-link-function 'yes-or-no-p
 org-startup-with-inline-images t
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-html-format-headline-function 'ignore
 org-startup-truncated nil
 org-babel-load-languages '((sh . t) (python . t) (R . t) (ruby . t)
                            (ditaa . t) (dot . t) (octave . t) (sqlite . t)
                            (perl . t) (clojure . t) (java . t)
                            (emacs-lisp . t) (lisp . t))
 org-html-format-inlinetask-function 'ignore
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 )

Re: Bug: Export to html and latex fails on these (relatively common) strings [8.2.10 (8.2.10-16-g4c37a9-elpa @ /home/mzimmermann/.emacs.d/elpa/org-20141110/)]

[Nicolas Goaziou]

Hello,

Milan Zimmermann <milan.zimmermann@gmail.com> writes:

> Any of the strings in Ex 1) to Ex 4) below, even individually,
> including the extremely simple example 4, fails the export of the org
> file to latex and html. The failure appears to happen in the first
> step (converting to an intermediate format)
>
> *Steps to reproduce:*
>
> - Open a file containing any of the 4 examples (or this text named as org)
> - C-c C-e l L 
> - Backtrace is attaches
>
> These type of strings on which the failure happens are not unusual to
> find in documents pasted from mysql or git.

Thanks for your report.

> *Ex 1)* - real life example from git output which fails to export
>
> git pull origin master                                 
> From github.com:airlift-group/cubifier                                                                                               
> \* branch            master     -> FETCH_HEAD                                                                                        
> Updating 28d0c00..8d3abef                                                                                                            
> Fast-forward                                                                                                                         
> grails-app/conf/Aaaa.groovy                        | 10 +++++-----                                                 
> src/java/org/Bbbb.java                             | 19 +++++++++++++++----                                        
> src/java/org/Cccc.java                             | 30 ++++++++++++++++++++----------  

I don't get any error with this example. However, I suggest to wrap such
things within a verbatim block, e.g., #+begin_example, so they don't
interfere with Org syntax.

> *Ex 2)* - real life from Mysql output which fails to export (note the misalligned | in the data row - no issues when alligned)
>
> +-------+------------+-----------+
> | label | long_label | isEnabled |
> +-------+------------+-----------+
> |       | 2          |          |
> +-------+------------+-----------+
>
> *Ex 3)* Simple example which fails to export
>
> +------------+----------+
>
> *Ex 4)* Simpliest example which fails to export
>
> +------------

The three examples describe the same problem. Org has "some" support for
"table.el" tables. However, it is very bad at recognizing them: both
examples 3 and 4 are recognized as "table.el" tables.

Worse, "table.el" is bad at recognizing "table.el" tables.  Hence,
example 2 is /almost/ a "table.el" table, but "table.el" itself fails to
correctly recognize it.

So, even if we improve Org to recognize them better (and there's
definitely room for that), we cannot do better than the concerned
library itself, which is not perfect either.

IMO, it is worth pondering if we should drop the defective support for
table.el tables in Org.

In the meanwhile, you can also wrap this kind of output in a verbatim
block or a fixed-width area.


Regards,

-- 
Nicolas Goaziou

Re: Bug: Export to html and latex fails on these (relatively common) strings [8.2.10 (8.2.10-16-g4c37a9-elpa @ /home/mzimmermann/.emacs.d/elpa/org-20141110/)]

[Rasmus]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> IMO, it is worth pondering if we should drop the defective support for
> table.el tables in Org.

Fine with me.  Last I checked I was not able to get the output of
tabel.el tables to be satisfying (e.g. I think I gave up on having them
follow booktabs when exporting to LaTeX).

What are the advances of table.el?  Multicolumns and multiline row?

Thanks,
Rasmus

-- 
Send from my Emacs

Re: Bug: Export to html and latex fails on these (relatively common) strings [8.2.10 (8.2.10-16-g4c37a9-elpa @ /home/mzimmermann/.emacs.d/elpa/org-20141110/)]

[Nicolas Goaziou]

Rasmus <rasmus@gmx.us> writes:

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> IMO, it is worth pondering if we should drop the defective support for
>> table.el tables in Org.
>
> Fine with me.  Last I checked I was not able to get the output of
> tabel.el tables to be satisfying (e.g. I think I gave up on having them
> follow booktabs when exporting to LaTeX).
>
> What are the advances of table.el?  Multicolumns and multiline row?

Basically, yes.

Note that dropping support for table.el tables in Org doesn't mean it is
impossible to add them in an Org buffer: these tables are pretty much
major mode agnostic.

However, M-q will fill them, C-c ' will not edit them and export will
have to be done by hand, using features explained in "table.el"
comments.


Regards,

Re: Bug: Export to html and latex fails on these (relatively common) strings [8.2.10 (8.2.10-16-g4c37a9-elpa @ /home/mzimmermann/.emacs.d/elpa/org-20141110/)]

[Rasmus]

Hi,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Rasmus <rasmus@gmx.us> writes:
>
>> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>>
>>> IMO, it is worth pondering if we should drop the defective support for
>>> table.el tables in Org.
>>
>> Fine with me.  Last I checked I was not able to get the output of
>> tabel.el tables to be satisfying (e.g. I think I gave up on having them
>> follow booktabs when exporting to LaTeX).
>>
>> What are the advances of table.el?  Multicolumns and multiline row?
>
> Basically, yes.

So multiline rows doesn't matter.  We can collapse columns to not take
up too much horizontal space in buffers via <NUM>.  Long lines work out
of the box in ox-html and can easily be had via e.g. p-columns in
ox-latex.  No idea about ox-ascii or ox-odt.

Multicolumns would be very nice to have in Org-tables.  I'm not at all
how feasible this is, though. . .

Thus, the only feature we'd lose by dropping tabel.el is multicolumns.

> Note that dropping support for table.el tables in Org doesn't mean it is
> impossible to add them in an Org buffer: these tables are pretty much
> major mode agnostic.

Sure.  Same with org-table...

> However, M-q will fill them, C-c ' will not edit them and

Makes sense.

> export will have to be done by hand, using features explained in
> "table.el" comments.

Meh, they don't follow org-export-· and org-BACKEND-· anyway (I checked
this a while ago, maybe things changed). . .  If the previous statement
is correct, I don't know if Org really supports exporting them. . .

Anyway, that's just my €0.02.

—Rasmus

-- 
If you can mix business and politics wonderful things can happen!

Re: Bug: Export to html and latex fails on these (relatively common) strings [8.2.10 (8.2.10-16-g4c37a9-elpa @ /home/mzimmermann/.emacs.d/elpa/org-20141110/)]

[Milan Zimmermann]

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

Hi Nicolas,

Thanks for your answers.

On the first example from Git - you are right this snippet exports
correctly. I had a big file and after removing all tables, the export
failed and I thought it pointed to the git section. But I cannot duplicate
this now, I apologize for including this example.

On the rest of examples that as you said are due to trying to recognize
table.el tables: Personally I like the fact tables from Mysql (and perhaps
other systems) can be pasted directly and in /most cases/ work through the
table.el mechanism. If support for table.el is dropped, is there a way to
convert table.el tables to org tables? imho, that would be really helpful
precondition to dropping the table.el support.

And thanks for the #begin/end_example pointer.

Milan


On Fri, Nov 14, 2014 at 3:30 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr>
wrote:

> Hello,
>
> Milan Zimmermann <milan.zimmermann@gmail.com> writes:
>
> > Any of the strings in Ex 1) to Ex 4) below, even individually,
> > including the extremely simple example 4, fails the export of the org
> > file to latex and html. The failure appears to happen in the first
> > step (converting to an intermediate format)
> >
> > *Steps to reproduce:*
> >
> > - Open a file containing any of the 4 examples (or this text named as
> org)
> > - C-c C-e l L
> > - Backtrace is attaches
> >
> > These type of strings on which the failure happens are not unusual to
> > find in documents pasted from mysql or git.
>
> Thanks for your report.
>
> > *Ex 1)* - real life example from git output which fails to export
> >
> > git pull origin master
> > From github.com:airlift-group/cubifier
> > \* branch            master     -> FETCH_HEAD
> > Updating 28d0c00..8d3abef
> > Fast-forward
> > grails-app/conf/Aaaa.groovy                        | 10 +++++-----
> > src/java/org/Bbbb.java                             | 19
> +++++++++++++++----
> > src/java/org/Cccc.java                             | 30
> ++++++++++++++++++++----------
>
> I don't get any error with this example. However, I suggest to wrap such
> things within a verbatim block, e.g., #+begin_example, so they don't
> interfere with Org syntax.
>
> > *Ex 2)* - real life from Mysql output which fails to export (note the
> misalligned | in the data row - no issues when alligned)
> >
> > +-------+------------+-----------+
> > | label | long_label | isEnabled |
> > +-------+------------+-----------+
> > |       | 2          |          |
> > +-------+------------+-----------+
> >
> > *Ex 3)* Simple example which fails to export
> >
> > +------------+----------+
> >
> > *Ex 4)* Simpliest example which fails to export
> >
> > +------------
>
> The three examples describe the same problem. Org has "some" support for
> "table.el" tables. However, it is very bad at recognizing them: both
> examples 3 and 4 are recognized as "table.el" tables.
>
> Worse, "table.el" is bad at recognizing "table.el" tables.  Hence,
> example 2 is /almost/ a "table.el" table, but "table.el" itself fails to
> correctly recognize it.
>
> So, even if we improve Org to recognize them better (and there's
> definitely room for that), we cannot do better than the concerned
> library itself, which is not perfect either.
>
> IMO, it is worth pondering if we should drop the defective support for
> table.el tables in Org.
>
> In the meanwhile, you can also wrap this kind of output in a verbatim
> block or a fixed-width area.
>
>
> Regards,
>
> --
> Nicolas Goaziou
>

[-- Attachment #2: Type: text/html, Size: 4559 bytes --]

Re: Bug: Export to html and latex fails on these (relatively common) strings [8.2.10 (8.2.10-16-g4c37a9-elpa @ /home/mzimmermann/.emacs.d/elpa/org-20141110/)]

[Milan Zimmermann]

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

Please ignore my note about converting table.el to table. There is a C-c ~
.

On Fri, Nov 14, 2014 at 10:51 AM, Milan Zimmermann <
milan.zimmermann@gmail.com> wrote:

> Hi Nicolas,
>
> Thanks for your answers.
>
> On the first example from Git - you are right this snippet exports
> correctly. I had a big file and after removing all tables, the export
> failed and I thought it pointed to the git section. But I cannot duplicate
> this now, I apologize for including this example.
>
> On the rest of examples that as you said are due to trying to recognize
> table.el tables: Personally I like the fact tables from Mysql (and perhaps
> other systems) can be pasted directly and in /most cases/ work through the
> table.el mechanism. If support for table.el is dropped, is there a way to
> convert table.el tables to org tables? imho, that would be really helpful
> precondition to dropping the table.el support.
>
> And thanks for the #begin/end_example pointer.
>
> Milan
>
>
> On Fri, Nov 14, 2014 at 3:30 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr>
> wrote:
>
>> Hello,
>>
>> Milan Zimmermann <milan.zimmermann@gmail.com> writes:
>>
>> > Any of the strings in Ex 1) to Ex 4) below, even individually,
>> > including the extremely simple example 4, fails the export of the org
>> > file to latex and html. The failure appears to happen in the first
>> > step (converting to an intermediate format)
>> >
>> > *Steps to reproduce:*
>> >
>> > - Open a file containing any of the 4 examples (or this text named as
>> org)
>> > - C-c C-e l L
>> > - Backtrace is attaches
>> >
>> > These type of strings on which the failure happens are not unusual to
>> > find in documents pasted from mysql or git.
>>
>> Thanks for your report.
>>
>> > *Ex 1)* - real life example from git output which fails to export
>> >
>> > git pull origin master
>> > From github.com:airlift-group/cubifier
>> > \* branch            master     -> FETCH_HEAD
>> > Updating 28d0c00..8d3abef
>> > Fast-forward
>> > grails-app/conf/Aaaa.groovy                        | 10 +++++-----
>> > src/java/org/Bbbb.java                             | 19
>> +++++++++++++++----
>> > src/java/org/Cccc.java                             | 30
>> ++++++++++++++++++++----------
>>
>> I don't get any error with this example. However, I suggest to wrap such
>> things within a verbatim block, e.g., #+begin_example, so they don't
>> interfere with Org syntax.
>>
>> > *Ex 2)* - real life from Mysql output which fails to export (note the
>> misalligned | in the data row - no issues when alligned)
>> >
>> > +-------+------------+-----------+
>> > | label | long_label | isEnabled |
>> > +-------+------------+-----------+
>> > |       | 2          |          |
>> > +-------+------------+-----------+
>> >
>> > *Ex 3)* Simple example which fails to export
>> >
>> > +------------+----------+
>> >
>> > *Ex 4)* Simpliest example which fails to export
>> >
>> > +------------
>>
>> The three examples describe the same problem. Org has "some" support for
>> "table.el" tables. However, it is very bad at recognizing them: both
>> examples 3 and 4 are recognized as "table.el" tables.
>>
>> Worse, "table.el" is bad at recognizing "table.el" tables.  Hence,
>> example 2 is /almost/ a "table.el" table, but "table.el" itself fails to
>> correctly recognize it.
>>
>> So, even if we improve Org to recognize them better (and there's
>> definitely room for that), we cannot do better than the concerned
>> library itself, which is not perfect either.
>>
>> IMO, it is worth pondering if we should drop the defective support for
>> table.el tables in Org.
>>
>> In the meanwhile, you can also wrap this kind of output in a verbatim
>> block or a fixed-width area.
>>
>>
>> Regards,
>>
>> --
>> Nicolas Goaziou
>>
>
>

[-- Attachment #2: Type: text/html, Size: 5097 bytes --]