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 <m...@nicolasgoaziou.fr> wrote: > Hello, > > Milan Zimmermann <milan.zimmerm...@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 >
