From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [odt/xhtml] Export lists as tables (list-tables) Date: Sat, 03 Sep 2011 13:41:13 +0200 Message-ID: <87aaal6eg6.fsf@gmail.com> References: <814o0wt5xy.fsf@gmail.com> <87liu66ep3.fsf@gmail.com> <81liu63ti7.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:49348) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qzobs-0002ph-HF for emacs-orgmode@gnu.org; Sat, 03 Sep 2011 07:42:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qzobr-0001X1-17 for emacs-orgmode@gnu.org; Sat, 03 Sep 2011 07:42:04 -0400 Received: from mail-ww0-f49.google.com ([74.125.82.49]:37143) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qzobq-0001Wr-Mj for emacs-orgmode@gnu.org; Sat, 03 Sep 2011 07:42:02 -0400 Received: by wwf10 with SMTP id 10so3073049wwf.30 for ; Sat, 03 Sep 2011 04:42:00 -0700 (PDT) In-Reply-To: <81liu63ti7.fsf@gmail.com> (Jambunathan K.'s message of "Sat, 03 Sep 2011 14:14:16 +0530") 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: emacs-orgmode@gnu.org Hello, Jambunathan K 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