[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: Better formatting for long descriptions

On Thu, Apr 16 2009, Andreas Tille wrote:

> On Thu, 16 Apr 2009, Ben Finney wrote:
>> Note that, like Manoj, I'm suggesting only a *subset*, not the full
>> specification.
> Well, in this thread we had several suggestions reaching from complete
> change to different format up to "not in detail specified" subsets of
> other formats.  IMHO this does not bring us foreward a single step.
> If we want to move foreward we have to make sure that we will not be
> forced to touch every single package because such an intend will be

        This is exactly why I like markdown or restructured text, most
 packages conform already.

> bound to fail and every minute spended in discussion here is simply
> wasted.  So if you suggest a subset of a specification please state
> clearly which subset and whether it works with currently existing
> descriptions.  I'd volunteer to set up a doodle poll with suggestions.

        Voting is a piss poor means of making a technical decision.

        At this point, I would say rules for lists, and bold/italics
 should not be any more restrictive than markdown/ReST, and not impose
 any more burdens on the description writer.

> If you make a suggestion please answer the following question:
>   A. Does the suggestion enable parsing logical structures like
>      two level itemize lists?
>      (This is what I want to approach and what is IMHO needed)

        Markdown and ReST, trivially.

>   B. Does the suggestion enable keeping the majority of description
>      untouched and enables keeping the currently existing tools?
>      (This is important to gain any acceptance)

        Yes, for both.

        The one issue I have seen raised is that of using *italics* and
 **bold** text; there are package descriptions where italics will
 suddenly appear. Me, I like org mode, where we have /italics/, *bold*
 +strikethrough+, _underline_; bug I doubt that org-mode will be popular
 as an interpreter.

It is better to have loved and lost -- much better.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: