On Sat, Sep 23, 2006 at 05:38:52PM +0200, Tomas Pospisek <[EMAIL PROTECTED]> was heard to say: > 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
All correct.
> * 1 space + bullet + whatever -> standard rendering - no list entry
> * 2 spaces + bullet + whatever -> list entry
Ah. The problem is that aptitude parses indented regions using the
standard grammar, but with N spaces stripped from each line before
applying the grammar. This allows multi-paragraph list entries, like:
* One list entry
* Another list entry.
.
Here is some more text describing the list entry.
The result of treating the last line as part of the list entry is that
it will be indented to exactly the same level as the rest of the entry,
and it will be word-wrapped instead of being treated as verbatim text.
Using the standard grammar also allows verbatim text in lists. This
was another reason for always stripping exactly one space after the
bullet; it allows you to write
* Homepage: http://some.url.example.com
and have it not get word-wrapped. (previously this would be considered
a normal bullet point with 2 spaces of indentation beyond the bullet)
Removing the ability to write multi-paragraph list entries is not
appealing to me. Now that I look at this from a fresh perspective,
though, there is one other choice. I could consider text following
a bullet that's at the same indentation level and separated only by
blank lines to be part of the bullet, as in:
* One list entry
* Another list entry.
.
Here is some more text describing the list entry.
This syntax is also more compatible with older readers like dselect.
> 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?
I think the path of least resistance, especially for getting this into
policy, is to have a backwards-compatible syntax. aptitude's list
handling was supposed to be backwards-compatible, but I made a mistake
in handling full stops that made it not backwards-compatible. I'm not
aware of any other technical problems, so I'll re-enable it in the next
release (once I implement the change above).
Daniel
signature.asc
Description: Digital signature
