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
else
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?
manoj
--
"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: