emacs-orgmode
[Top][All Lists]

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

 From: Jambunathan K Subject: Re: [O] [odt/xhtml] Export lists as tables (list-tables) Date: Sat, 03 Sep 2011 14:14:16 +0530 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (windows-nt)

Nicolas Goaziou <address@hidden> writes:

> Hello,
>
>
>> 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
- 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

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

- For lparse backends, "something" => list->table conversion
- For non-lparse backends, "something" => list->list

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

https://lists.gnu.org/archive/html/emacs-orgmode/2011-08/msg01267.html

it surfaced that

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

--