From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jambunathan K Subject: Re: [odt/xhtml] Export lists as tables (list-tables) Date: Sat, 03 Sep 2011 14:14:16 +0530 Message-ID: <81liu63ti7.fsf@gmail.com> References: <814o0wt5xy.fsf@gmail.com> <87liu66ep3.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:33528) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzlqZ-0001fx-Ow for emacs-orgmode@gnu.org; Sat, 03 Sep 2011 04:45:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QzlqX-0003Lp-Sn for emacs-orgmode@gnu.org; Sat, 03 Sep 2011 04:45:03 -0400 Received: from mail-pz0-f44.google.com ([209.85.210.44]:34578) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzlqX-0003LU-EG for emacs-orgmode@gnu.org; Sat, 03 Sep 2011 04:45:01 -0400 Received: by pzk36 with SMTP id 36so6309218pzk.17 for ; Sat, 03 Sep 2011 01:45:00 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Nicolas Goaziou Cc: emacs-orgmode@gnu.org Nicolas Goaziou writes: > Hello, > > Jambunathan K 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
- 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
(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.) --