Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-24 Thread Andreas Tille
On Thu, 23 Apr 2009, Daniel Burrows wrote: For the sorts of markup our descriptions have now it'll be fine, but it's my experience that when you give people a hammer they start hitting everything that's vaguely nail-shaped with it. :-) ROFL. The whole time of discussion was well spent just

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-23 Thread Daniel Burrows
On Tue, Apr 21, 2009 at 09:31:31AM +0200, Andreas Tille til...@rki.de was heard to say: Moreover I see no reason to bind anybody to a certain library like markdown. My experience has shown that people will insist on their very own way to do things. Do you think apt, aptitude, synaptic etc.

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-22 Thread Stefano Zacchiroli
On Tue, Apr 21, 2009 at 11:36:31PM +0200, Vincent Danjean wrote: I've the impression that you didn't read my post, I might be wrong though. Do you read mine ? Yes, but not the prev(prev(.)), sorry about that. With that convention, you can use Markdown out of the box (on each paragraph)

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-22 Thread Michael Banck
On Wed, Apr 22, 2009 at 07:34:45AM +0200, Andreas Tille wrote: Well, *if* something is *recommended* in the docs filing wishlist bugs against packages that ignore the recommendation are fine. Why else should we issue recommendations? For people writing new long descriptions, first off. That

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-22 Thread Andreas Tille
On Tue, 21 Apr 2009, Don Armstrong wrote: There's no point to defining rules without a working implementation, because we don't know what the rules should be. So I tried to do an implementation for the tasks pages of Blends which works for unordered lists as discussed here and I also made

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-21 Thread Stefano Zacchiroli
On Mon, Apr 20, 2009 at 11:24:42PM +0200, Andreas Tille wrote: Here is the URL of the poll: http://doodle.com/2bp8rrh3i35sr4s7 Heya, thanks for the poll. Nevertheless, I think I got a bit lost in the discussion. Following it, I had the impression that there was a quasi-agreement on

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-21 Thread Andreas Tille
On Tue, 21 Apr 2009, Stefano Zacchiroli wrote: Nevertheless, I think I got a bit lost in the discussion. Following it, I had the impression that there was a quasi-agreement on Markdown. Hence, I'm wondering what is the exact purpose of your poll. With Markdown, you have alternative markers for

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-21 Thread Don Armstrong
On Tue, 21 Apr 2009, Andreas Tille wrote: I'm afraid that this leaves to much space for broken input as the airport-utils example in the end of [1] shows. Manoj tried to prove that markdown works perfectly - but it does not because the indentantion of the original input is just wrong. I want

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-21 Thread Vincent Danjean
Don Armstrong wrote: On Tue, 21 Apr 2009, Andreas Tille wrote: Moreover I see no reason to bind anybody to a certain library like markdown. It's perfectly ok to punt the specification of the format to an external library, at least initially. If enough people don't want to use the markdown

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-21 Thread Lars Wirzenius
ti, 2009-04-21 kello 10:37 +0200, Vincent Danjean kirjoitti: As shown before in the other thread, markdown does not work with the current long description : it needs pre-processing to add some blank lines before each list. That's true. Because the Packages and debian/control files are in

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-21 Thread Stefano Zacchiroli
On Tue, Apr 21, 2009 at 10:37:00AM +0200, Vincent Danjean wrote: As shown before in the other thread, markdown does not work with the current long description : it needs pre-processing to add some blank lines before each list. I've the impression that you didn't read my post, I might be

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-21 Thread Lars Wirzenius
ti, 2009-04-21 kello 12:00 +0200, Andreas Tille kirjoitti: In principle this is fine as well. That's why my initial mail[1] said This suggestion is far from complete and should be enhanced. If there is a need to relax my strictly German habit to trimm everything very tidy - people should have

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-21 Thread Don Armstrong
On Tue, 21 Apr 2009, Andreas Tille wrote: On Tue, 21 Apr 2009, Don Armstrong wrote: So long as we have an implementation which works for the vast majority of cases we can file bugs to make it work for the few cases where it doesn't. (Or the output can just be slightly broken in those cases;

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-21 Thread Andreas Tille
On Tue, 21 Apr 2009, Don Armstrong wrote: There's no point to defining rules without a working implementation, because we don't know what the rules should be. Once there is a working implementation that works for a reasonable majority of the descriptions, we can define rules based on the

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-21 Thread Andreas Tille
On Tue, 21 Apr 2009, Don Armstrong wrote: So long as we have an implementation which works for the vast majority of cases we can file bugs to make it work for the few cases where it doesn't. (Or the output can just be slightly broken in those cases; it's not like that's a huge problem.) IMHO

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-21 Thread Andreas Tille
On Tue, 21 Apr 2009, Lars Wirzenius wrote: Properly here should mean anything that the markdown language says is OK. The markdown language is remarkably relaxed about indentation. It can handle it fine if one list is indented by two space, and other by three. There seems to be no need for

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-21 Thread Stefano Zacchiroli
On Tue, Apr 21, 2009 at 01:08:24PM +0300, Lars Wirzenius wrote: Very well: your tendency towards strict consistency needs to be relaxed. :) Thus as far as I can see there is a rough consensus and the following should happen: That's my reading as well. (Adding back -policy to the recipient

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-21 Thread Lars Wirzenius
ti, 2009-04-21 kello 11:27 +0200, Andreas Tille kirjoitti: On Tue, 21 Apr 2009, Stefano Zacchiroli wrote: Anticipating a potential objection: nested lists do work without needing blank lines to separate nesting levels; I've just tried that out. ... provided that lists are formated

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-21 Thread Andreas Tille
On Tue, 21 Apr 2009, Stefano Zacchiroli wrote: Anticipating a potential objection: nested lists do work without needing blank lines to separate nesting levels; I've just tried that out. ... provided that lists are formated properly in the first place (keyword: broken spacings). That's why I

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-21 Thread Holger Levsen
Hi, On Dienstag, 21. April 2009, Andreas Tille wrote: There is no point in implementing better markup for the Blends pages if I know from the beginning that I will end up with broken pages for an undetermined time. Perfect is the enemy of good. regards, Holger signature.asc

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-21 Thread Vincent Danjean
Stefano Zacchiroli wrote: On Tue, Apr 21, 2009 at 10:37:00AM +0200, Vincent Danjean wrote: As shown before in the other thread, markdown does not work with the current long description : it needs pre-processing to add some blank lines before each list. I've the impression that you didn't

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-21 Thread Michael Banck
On Tue, Apr 21, 2009 at 12:36:14PM +0300, Lars Wirzenius wrote: ti, 2009-04-21 kello 11:27 +0200, Andreas Tille kirjoitti: On Tue, 21 Apr 2009, Stefano Zacchiroli wrote: Anticipating a potential objection: nested lists do work without needing blank lines to separate nesting levels;

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-21 Thread Andreas Tille
On Tue, 21 Apr 2009, Michael Banck wrote: I for one like visual consistency even when reading package descriptions via apt-cache etc. It must be a boring German habit - I always felt this way myself. I started some action when I noticed that my feeling turned out to have technical advantages

Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

2009-04-20 Thread Andreas Tille
Hi, as promissed in the overlongish thread [1] I would like to sort out the details how we should enhance the consistency and parseability of our long descriptions in a poll. I agree that it is not a good idea to solve technical issues in a poll. But this is not about a technical issue. There