From: Nicolas Goaziou <n.goaziou@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [odt/xhtml] Export lists as tables (list-tables)
Date: Sat, 03 Sep 2011 13:41:13 +0200 [thread overview]
Message-ID: <87aaal6eg6.fsf@gmail.com> (raw)
In-Reply-To: <81liu63ti7.fsf@gmail.com> (Jambunathan K.'s message of "Sat, 03 Sep 2011 14:14:16 +0530")
Hello,
Jambunathan K <kjambunathan@gmail.com> writes:
> I implemented it mostly to exercise the org-lparse library a bit and
> ended up extracting/abstracting few things in org-lparse.el. Note that
> I have zero understanding of list-struct. The list-tables are generated
> right at the point where lists/list-items are emitted WITHOUT and I
> DONOT DO any "pre-processing" on list-struct. I would consider this
> approach as "backend-driven".
That's exactly my point. This is backend specific.
> This is in contrast, to the approach that you have taken in
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2011-03/msg01125.html
>
> which is "frontend-driven".
I wouldn't call this quick hack an "approach". In fact, as an approach,
it would be quite bad: you're right, it's all an exporter thing, not an
Org one.
> Btw, having a prototype also helps in
> 1. registering a clear intent
> 2. get some clarity on the points of interest
Agreed.
>> You shouldn't use blocks for this. Blocks are on the heavy side of
>> syntax and are to be avoided when possible.
>
> Could you please clarify what exactly you mean by "heavy side" of
> syntax?
Block syntax is very intrusive in an Org document. Unless there's one
really good reason to use it, we shouldn't.
Now, the only valid reason I see to use a block in that case is that it
allows to have a table-list within a list, which is a bit convoluted.
> There should be a way for the user to specify that "this" list is a
> special kind of list and need to be exported differently. In some sense
> identifying the beginning of a list-table is crucial. (As you rightly
> note finding the end of the list is easy.)
That's why I talked about #+attr_odt.
> These are some possibilities that I considered for declaring a
> list-table and abandoned it mostly because it would require extra work.
>
> 1. Use the top-level bullet-type to identify special kinds of lists
> * Advantages
> - This theme occurred a few days ago in the thread "Convert list to
> Paragraph". See
> https://lists.gnu.org/archive/html/emacs-orgmode/2011-08/msg01117.html.
>
> - No special metalines required
>
> * Disadvantages
> - list-structs report only on three types of bullets - ordered,
> unordered, description - even though Org syntax recognize
> multiple kinds of bullets for the unordered (`-', `+', `*') and
> ordered (`1.', `1)'). As a result org-lparse driver has only a
> small catalogue of "list types" to work with as opposed to a
> greater set available to the front end driver.
>
> One of the things that could be considered is to enhance
> list-struct so that it starts reporting on various "kinds" of
> ordered and unordered and the not so commonly used bullet types
> (which is user-specific) could be reserved for special export
> processing. (I almost never use *, +, or alphabetical styles).
>
> A nice side-effect of such a enhancement would be that the
> backend drivers - like odt - can offer a platter of list styles
> that match one-to-one with the list style used in Org file
> resulting in a more richer export.
>
> 2. Use description list as leader lines. One of
>
> - ORG-LIST-TABLE :: ORG-LIST-TABLE-OPTIONS
> - a
> - b
> - c
> - d
> - e
> - f
>
> - ORG-LIST-TABLE :: ORG-LIST-TABLE-OPTIONS
> - a
> - b
> - c
> - d
> - e
> - f
I really think this is the wrong direction to go anyway.
Org syntax is meant for... Org. Almost every syntactical element should
provide information to _Org_ that cannot be provided by others means.
Only exceptions allowed are elements whose boundaries need to be
explicitly specified. In that case, a block structure in indeed the Org
way to answer their needs.
Obviously, #+begin_center, #+begin_verse, and the logic behind
org-special-blocks.el are these exceptions.
list-tables are, from Org, just lists. They may be exported differently
(more exactly their first two levels may be), but they're still lists.
A well-defined syntax exists for them, and there is no need to re-invent
the wheel.
You want to tell some exporter(s) that the list should be treated
differently. There's a way: "#+attr_(backend)".
> Retrospectively speaking, Captions, labels and attributes gets applied
> only to tables and links (IIRC) and not LISTS. [2]
This is being worked on. From my point of view, almost everything could
have caption, label and attributes. More on that later.
> May be it is just not attr_odt or attr_html but instead attr_lparse?
attr_lparse means nothing for the non-developer. An user knows the
output format he wants to get, not the parser internally used to provide
it.
Moreover, no offense to take, I really wish we can get rid of such
a thing as org-lparse.el. For all its benefits, it's still the spawn of
evil: org-html.el.
Parsing line after line a block driven format is just unnatural. We can
do better.
> In the below thread,
> https://lists.gnu.org/archive/html/emacs-orgmode/2011-08/msg01267.html
>
> it surfaced that
>
> #+begin_todo additonal-params
> todonotes
> #+end_todo
>
> could be emitted as macro and not as environment (I may have got my
> LaTeX terms wrong)
In my opinion, any block could have the Babel-oriented following syntax,
where anything between parenthesis is clearly optional:
(#+caption: caption)
(#+label: label)
(#+attr_backend: backend specific params)
(#+header: generic params)
#+begin_name (generic params)
...
#+end_name
The optional lines could be in any order, #+attr_backend and #+header
line could happen any number of times.
Regards,
--
Nicolas Goaziou
next prev parent reply other threads:[~2011-09-03 11:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-01 19:31 [odt/xhtml] Export lists as tables (list-tables) Jambunathan K
2011-09-01 23:12 ` suvayu ali
2011-09-02 1:20 ` Matt Price
2011-09-02 17:23 ` Nicolas Goaziou
2011-09-02 17:48 ` Matt Price
2011-09-02 18:11 ` Nicolas Goaziou
2011-09-02 19:52 ` Thomas S. Dye
2011-09-03 8:44 ` Jambunathan K
2011-09-03 11:41 ` Nicolas Goaziou [this message]
2011-09-03 12:58 ` Christian Moe
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=87aaal6eg6.fsf@gmail.com \
--to=n.goaziou@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).