From: Milan Zimmermann <milan.zimmermann@gmail.com>
To: emacs-orgmode@gnu.org
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:51:19 -0500 [thread overview]
Message-ID: <CAEc2VK2s0acvb11Rr+Q+wwL44pw7j=_+hRrpxB=QenxVTmNCLw@mail.gmail.com> (raw)
In-Reply-To: <87tx22npzo.fsf@nicolasgoaziou.fr>
[-- Attachment #1: Type: text/plain, Size: 3474 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 4559 bytes --]
next prev parent reply other threads:[~2014-11-14 15:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-13 22:45 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/)] Milan Zimmermann
2014-11-14 8:30 ` Nicolas Goaziou
2014-11-14 9:27 ` Rasmus
2014-11-14 9:42 ` Nicolas Goaziou
2014-11-14 10:35 ` Rasmus
2014-11-14 15:51 ` Milan Zimmermann [this message]
2014-11-14 15:55 ` Milan Zimmermann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAEc2VK2s0acvb11Rr+Q+wwL44pw7j=_+hRrpxB=QenxVTmNCLw@mail.gmail.com' \
--to=milan.zimmermann@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).