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 <mail@nicolasgoaziou.fr>]

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