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.zimmerm...@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 <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 >> > >
