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

[Jambunathan K <kjambunathan@gmail.com>]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Jambunathan K <kjambunathan@gmail.com> writes:
>
>> List-tables is a humble first step in this direction. (Proportional
>> sizing of columns and support for grid lines is coming soon)
>>
>> From the blurb:
>> ,----
>> | ;; Notes on LIST-TABLES
>> | ;; ====================
>> | ;; When `org-lparse-list-table-enable' is non-nil, the following list
>> | ;;
>> | ;; #+begin_list-table
>> | ;; - Row 1
>> | ;;   - 1.1
>> | ;;   - 1.2
>> | ;;   - 1.3
>> | ;; - Row 2
>> | ;;   - 2.1
>> | ;;   - 2.2
>> | ;;   - 2.3
>> | ;; #+end_list-table
>> | ;;
>> | ;; will be exported as though it were a table as shown below.
>> | ;;
>> | ;; | Row 1 | 1.1 | 1.2 | 1.3 |
>> | ;; | Row 2 | 2.1 | 2.2 | 2.3 |
>> | ;;
>> | ;; Inspired by following thread:
>> | ;; https://lists.gnu.org/archive/html/emacs-orgmode/2011-03/msg01101.html
>> `----

Hello Nicolas

Thanks for you feedback.

Long post. Intention is to record my notes on the topic as opposed to
responding/acting directly on your specific feedback. There is some
slight digression as well here and there.

Consider my implementation as a prototype and there is LOTS OF scope for
improvement including the possibility of abandoning it altogether and
settling instead for a most efficeint implementation. 

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". 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".

Btw, having a prototype also helps in 
1. registering a clear intent
2. get some clarity on the points of interest

> 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?

> Here, Org is perfectly able to determine list end by itself[1] without
> an explicit boundary.  

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.)

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

> Furthermore, blocks, with the obvious exception of backend specific
> ones, are expected to do "something" in any major exporter. 

I am not sure by "doing something" you mean "create side-effects" like
generating results block. 

For now, I will assume that you are meaning "format it in a custom
manner" - by formatting it could mean plain formatting (list becomes
list), stripping (comment, src block etc stripped on export),
transforming (src block is appended or replaced with results block or a
ditaa block replaced with image file). With my latter definition,
"something" does happen though it happens to be "different things" for
different backends. I agree that this difference in behaviour amounts to
major incosistency and has to be bridged.

Let me explain.

The current implementation uses a custom implementation of
org-special-blocks.el but NOT org-special-blocks.el per se.

When org-special-blocks.el is NOT LOADED, 
- For lparse backends, "something" => list->table conversion
- For non-lparse backends, "something" => list->list

When org-special-blocks.el is LOADED
- for latex, ORG-LIST-TABLE-START and ORG-LIST-TABLE-END will be
  inserted in the buffer and later transformed
  to \begin{list-table}...\end{list-table} directive. This is a bug and
  has to be addressed. I think org-special-blocks.el has to be modified
  someway so that list is emitted normally.
- for html backend, the list will be surrounded with a <div > </div>
- for docbook backend, the list will be emitted normally
- for lparse-backends, the list->table conversion will happen.

> Thus, to put things differently, the structure you use should mention,
> by one way or another, that this is ODT specific.

list->table conversion will happen only if
`org-lparse-list-table-enable' is enabled (the default being disabled -
since it is an experimental/new feature). 

May be I could modify org-special-blocks.el to do capture something like
this [1]

'(LIST-TABLE
  (LATEX DO-NOTHING) ;; don't put in special env
  (HTML DEFAULT-ACTION) ;; surround with <div/>
  (DOCBOOK DO-NOTHING)
  (ODT CUSTOM-ACTION) ;; leave what to do the exporter
  (XHTML DEFAULT-ACTION)) 

and have the user customize it before using list-tables feature. This
way he will atleast know that list-tables are plain lists in non-lparse
backends.

> Hence, I would suggest to use a line like:
>                          #+attr_odt: list-table
>
> just above the list instead of the current choice of syntax.

I have not considered this.

Retrospectively speaking, Captions, labels and attributes gets applied
only to tables and links (IIRC) and not LISTS. [2]

When lists are emitted as tables, one might want to attach styles to the
list-table as though it were a table. So support for applying
attr_whatever to list will become necessary.

May be it is just not attr_odt or attr_html but instead attr_lparse?

> Now, as this file is meant to reach Org core, I really wish we can come
> up with a more general solution that will benefit to every other
> official export backend. Indeed, while developing one specific exporter
> is very useful, I personally think that, on the other hand, we must aim
> at providing users a consistent experience with any of them[2].

I agree with consistency part.

> [2] I will probably submit code soon that should help greatly in that
> mission.

That will be good or even better.

Thanks.
Jambunathan K.

[1] There should be a way to attach a custom handler for a special block
and it could also take some params.

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)

[2] Speaking of attributes, as a side note, there is clearly an INTENT
to apply captions etc to source blocks and examples. But due to
historical reasons there has been a re-ordering of processing steps in
org-export-preprocess-string which to leads to loss of the caption
information. (I have seen requests for having captions in src blocks
etc.)





--