Re: [O] [odt/xhtml] Export lists as tables (list-tables)

[Nicolas Goaziou]

Hello,

Jambunathan K <address@hidden> 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