On Fri, 22 Sep 2006, Daniel Burrows wrote:
[...]
There are two real problems [with parsing and rendering lists in
package descriptions - tpo]:
[...]
(2) The bulletting scheme cannot distinguish between a full stop at the
beginning of a legitimate line of text and a syntactically
significant full stop. Since these periods may occur after other
text or after two spaces, the standard description algorithm will
not strip this text -- meaning that aptitude will massively mangle
a description that displays just fine in the standard formatting.
Worse, you need to know about aptitude's formatting to get this right;
full-stops after indentation are just fine everywhere else, but not
if you've written a bulletted list. I presume that most Debian
developers aren't even aware aptitude exists, and even if they do, they
aren't going to be intimately familiar with its description parsing
algorithm. I can't really defend a feature that's likely to lead to
surprising and undesired results.
This actually occurred in the example that led to bug #373888, and
at a quick check there's one other package (flac) that has this
problem.
I wasn't able to find any satisfactory solution to this problem.
What I do not understand here, is how come that a '.' at the beginning of
a line has syntactic influence on aptitude.
The Debian policy [1] distinguishes the following line starts:
* 1 space + whatever -> paragraphs
* 1 space + dot -> blank line
* 1 space + dot + whatever -> reserved / to be defined
* 2 spaces -> verbatim
Thus a line starting with:
* 1 dot -> is a syntax error in the description
-> thus of no business to aptitude
* 1 space + dot -> blank line -> of no business to aptitude
* 2 spaces + 1 dot -> per aptitudes list definition not part of a list
since the text of a list entry must be at least as
far indented as the first bullet and thus start
with at least 4 spaces off to th
-> thus render verbatim
* 3 spaces + 1 dot -> same as 2 spaces + 1 dot
* 4 spaces + 1 dot -> in case we're in a list entry (which is
determined by the previous line) then render the
dot as part of the list entry. Otherwise verbatim
* >4spaces + 1 dot -> dito, except that you'll probably want to ident it
with the additional spaces
* 1 space + bullet + whatever -> standard rendering - no list entry
* 2 spaces + bullet + whatever -> list entry
The crutial point being, that aptitude must not interpret a dot aka a
period as a bullet otherwise confusion ensues - which AFAIK it doesn't.
So again. I unfortunately fail to see the problem. In case you could give
me some examples that I succeed to grasp then I'd be grateful.
And to come back to my suggested part of the fix of the problem(-range):
one (among other) ways to go would be to check *all* the descriptions and
to make sure that they render well and if not to "fix" them [2]. This does
not seem to be a infeasible thing. Once this is done, then there doesn't
seem to be a technical hurdle to put the list syntax into the Debian
policy?
*t
[1]
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description
[2] http://wiki.debian.org/Aptitude%3a%3aParse-Description-Bullets%3dtrue
--
-----------------------------------------------------------------------
Tomas Pospisek
http://sourcepole.com - Linux & Open Source Solutions
------------------------------------------------------------------------
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
