From mboxrd@z Thu Jan 1 00:00:00 1970 From: Milan Zimmermann Subject: 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/)] Date: Fri, 14 Nov 2014 10:55:34 -0500 Message-ID: References: <87ioiira7m.fsf@home-server.home-network> <87tx22npzo.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1133809af9c9d10507d3a99a Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60735) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpJE5-0002j1-9P for emacs-orgmode@gnu.org; Fri, 14 Nov 2014 10:55:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XpJE3-0005uW-Fj for emacs-orgmode@gnu.org; Fri, 14 Nov 2014 10:55:57 -0500 Received: from mail-qg0-x232.google.com ([2607:f8b0:400d:c04::232]:42529) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpJE3-0005uP-9Y for emacs-orgmode@gnu.org; Fri, 14 Nov 2014 10:55:55 -0500 Received: by mail-qg0-f50.google.com with SMTP id e89so1310296qgf.9 for ; Fri, 14 Nov 2014 07:55:54 -0800 (PST) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org --001a1133809af9c9d10507d3a99a Content-Type: text/plain; charset=ISO-8859-1 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 > wrote: > >> Hello, >> >> Milan Zimmermann 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 >> > > --001a1133809af9c9d10507d3a99a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please ignore my note about converting table.el to table. = There is a C-c ~ .=A0

On Fri, Nov 14, 2014 at 10:51 AM, Milan Zimmermann <mil= an.zimmermann@gmail.com> wrote:
Hi Nicolas,

Thanks for your answer= s.

On the first example from Git - you are right t= his snippet exports correctly. I had a big file and after removing all tabl= es, the export failed and I thought it pointed to the git section. But I ca= nnot duplicate this now, I apologize for including this example.
=
On the rest of examples that as you said are due to trying t= o 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 ther= e a way to convert table.el tables to org tables? imho, that would be reall= y helpful precondition to dropping the table.el support.

And thanks for the #begin/end_example pointer.
=A0
Milan
=


On Fri, Nov 14, 2014 at 3:30 AM, Nicolas Goaziou <ma= il@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<= br> > 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<= br> > 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=A0 =A0 =A0 =A0 =A0 =A0 master=A0 =A0 =A0-> FETCH_HEAD
> Updating 28d0c00..8d3abef
> Fast-forward
> grails-app/conf/Aaaa.groovy=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | 10 +++++-----
> src/java/org/Bbbb.java=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| 19 +++++++++++++++----
> src/java/org/Cccc.java=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| 30 ++++++++++++++++++++----------

I don't get any error with this example. However, I suggest to w= rap 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 |
> +-------+------------+-----------+
> |=A0 =A0 =A0 =A0| 2=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 |
> +-------+------------+-----------+
>
> *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&quo= t; support for
"table.el" tables. However, it is very bad at recognizing them: b= oth
examples 3 and 4 are recognized as "table.el" tables.

Worse, "table.el" is bad at recognizing "table.el" tabl= es.=A0 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


--001a1133809af9c9d10507d3a99a--