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
>