From: G. M. <g....@we...> - 2005-04-06 08:42:44
|
On 4.04.05, David Goodger wrote: > > I like the field-list tables for a start, but I quickly hit a wall > > when I try to use them in any consistent document-wide manner: > > > > :Hello: world > > :This is a long header: and this is its data. > > :It's too bad: these lists don't format properly! ... > > If the header is over 14 characters, suddenly it becomes colspan="2" > > and the table starts looking super sloppy. Why is this magic number > > in there? > > It is a magic number, and that should change. ... Done. I just > added a "field_name_limit" runtime setting ("--field-name-limit" > command-line option), where 0 indicates "no limit". IMHO, 0 should be the default, as this is "the obvious way". (People that do not care are not hit by the "inexplicable" magic. People that do care can read the documentation find the solution there and set --field-name-limit to a suitable "non-magic" value.) Another idea would be an explicit markup for line breaks: :Hello: world :This is a long header: and this is its data. :It's too bad: these lists don't format properly! I am not sure whether it is really clever, as it breaks RFC822 completely. However, it adds flexibility as in a long document (or in a run of several documents with one command), the "wrap point" could be set at different places for different lists. (Some lists have long headers, others have long data lines.) I remember to have read about command options in list context either in the list archives or in the documentation. It was something in the line Command options are bad, because the result of a conversion is no longer unique. (If I remember right, it was about field-list markers or indened bullet lists, so maybe the difference is that in the above case only the low-level outoput formatting is affected while in the list example rst-s idea about the document structure would be different.) Guenter Milde -- G.Milde web.de |