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