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

Re: RFC: Better formatting for long descriptions

On Sat, Apr 18 2009, Andreas Tille wrote:

> On Sat, 18 Apr 2009, Vincent Danjean wrote:
>> Remove the first space, remove the '.' that are alone on their line,
> That's cheap.
>> add a blank line before enumeration (this last point seems the more
>> annoying to me: it can be difficult to automatically find where to
>> insert a blank line).
> Well - here is the crux which let's me wonder whether Manoj was
> right in his posting[1] when he claimed:
>> > 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.
> It is neither trivial to detect the point where to add the needed
> blank line nor would it be a solution to advise people alwasy to

        Actually, it is pretty trivial. It is a second chanpeter
 exercise in K&R; it is a first month exercise in computer science 101.

        Here is an algorithm:
--8<---------------cut here---------------start------------->8---
 we are not in a list
 while reading each line, do
   remove leading space
   if the only non white space character on the line is a singe .
     remove the dot
   if the line matches the regexp: '^\s+[\*\+\-]\s+'
     if we are not in a list
       emit blank line first
       record we are not in a list
     if we are in a list
       record we are not in a list
   emit line
--8<---------------cut here---------------end--------------->8---

        People who can not convert this 13 line Psuedocode into a real
 code should not be writing stuff to pretty print descriptions.

> enclose lists in blank lines because people will tell you that
> this will look ugly in the existing interfaces.  So I would rather
> tend to "No for both" and this is the crux here.

        Frankly, I think this is very wrong.

> So while I perfectly agree with Manoj that voting on technical
> decisions is a bad idea I come back to my initial suggestion because
> my suggestions are technically equivalent but express a matter of
> taste of the developers which might lead to better acceptance.
> I would love if somebody could provide a proof that I'm wrong and
> there is a reliable way to turn long descriptions into proper markdown
> input to *really* be able to detect the lists.  If not I think I
> continue with my intention as described. [2]

        Is the above algorithm proof enough for you? Or do I have to
 write that into real code in your favourite porogramming language
 before you can see it?

"The minority is always right." Henrik Ibsen 1828-1906
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: