Re: [Docutils-develop] Overcoming limitations of reST tables

[<gr...@us...>]

On Mon, 29 Aug 2005, Martin Blais wrote:

> I know we all have our own idea of what restructured text is all
> about, but I must say that what I'm seeing above is as FAR as possible
> from my idea of what rest should be.  There are plenty of markup
> languages out there, if I understand correctly, rest is not meant to
> be one-- rather a markup-LESS document language.

agree with that and that is the way i use it.

> Doesn't rest state explicit limitations that we are meant to live with
> and "tough luck" if it won't do it?  Can we avoid turning this simple
> almost elegant set of conventions into yet another markup language? 
> The beauty of rest is "no or little markup".  IMO rest should not do
> anything that people want, it would not be rest anymore, and sometimes
> it should "just say no" (if it had a voice, that is).
> 
> Mark: what you need is to generate LaTeX, XHTML or some other markup
> language, you're using a program to generate it!  I would say you're
> DEFINITELY using the wrong tool for your purpose.
> 
> Now, before I go lie down, maybe what we all need is for a general
> framework for including output results from external processes,
> something like the "raw" directive, but that could call external
> programs to produce some part of the document tree, where the user
> could feed any horibble looking input from a document block to their
> favourite programs.   The whole point of this would be for a single
> text document to contain the whole source for mixed typed documents. 
> Not sure if it's worth it, but at least we would not have to consider
> insane amounts of bubbly markup being proposed into rest all the time:
> there would be a simple answer: "shove it up your own code!"  :-)

i got to this point too, and then again

* the rest you describe actually is the one reader that is implemented
  there could be others too.
* docutils could supply such a direct-to-internal reader (maybe from xml
  yaml rfc-somenumber)

  and it might even be easier to use the normal reader and just allow
  some .. internalField:: specifiers.

cheers
-- 
 BINGO: best of breed products and services