Re: Consistent formating long descriptions as input data
On Thu, 23 Apr 2009, Manoj Srivastava wrote:
Sure. It would be great to have another implementation, perhaps
one that people can play with (something that, for example, one can
pipe the output of a grep-dctrl command to, and get an html snippet
from (hey, that can then be packaged as an ikiwiki plugin).
As I said inclusion of the preprocessing code into python-apt or
any other reasonable place where you could turn it into a general
tool makes perfectly sense. IMHO it makes sense if I continue with
the tests for a while and than offer it for adoption.
But the task pages should count as an implementation.
I tried to detect some examples which need some changes. You might
like to have a look at my "Debugging Blend":
http://blends.debian.net/debug/tasks
Some issues are mentioned there - I intend to add some better
documentation if needed but some issues become clear.
Thanks. Once you are through, perhaps some directives for long
description policy can be derived from that.
Yesterday I had the idea to add a "Remarks of Blends-team" feature
which I will "missuse" to add a verbose output of `apt-cache show`
to the packages in question on the page above. This should enable
an easy way to see the problems quickly. I'll announce here once
it is finished.
2. Markdown is probably better in detecting second level lists
thank I would have done it programmatically - so here is
a benefit. On the other hand there are some strange false
positives for second level lists.
These should be something we can look at to provide a policy
recommendation so these false positives can be reduced.
Yes, that's the idea. On the other hand looking at some examples
I have the feeling that sometime markup has a strange way to handle
some lists. I'll come up with examples once I implemented the
"Remarks feature" so you can easily see what I mean.
I like the idea of 's/^(\s*)o\s+/$1* /' (to preserve the leading
indentation, in case this was a second level item) as a preprocessing
step in the interim, in the long term this usage should go down as
policy starts to deprecate it.
OK.
4. I expect more not yet detected needs for preprocessing.
Thanks for working on this.
Sure. I startet this thread not just for the sake of havin fun in a
discussion. ;-)
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: