On Mon, Sep 25, 2006 at 10:37:48PM +0200, Tomas Pospisek <[EMAIL PROTECTED]> was heard to say: > On Sun, 24 Sep 2006, Daniel Burrows wrote: > > 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. > > Mh. Well I understand a bit better now, thanks a lot. So the conclusion > is that the grammar/parser needs a change. However: > > > 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 is very ugly. Why not allow the grammar as it was and instead say > that: > > * One list entry > . > Some more text > > only this form will be accepted as a blank line and none other. That means > all other cases such as:
This might be reasonable as an alternative. It does mean, though, that if policy starts to define a meaning for " .asdf\n", there isn't a clean way of adding support for that within lists. I'm not sure that just using the same paragraph separator everywhere is all that ugly, though, although it wasn't my first instinct. Look at it this way: in many typesetting languages, completely blank lines separate paragraphs. This isn't done in descriptions because blank lines separate control file fields -- so we have the convention that a full stop and nothing else stands in for a blank line. It's not part of the text structure and I don't think there's any need to indent it. > >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? > > all existing packages are rendered correctly, even with the change of > syntax above then the need for backward compatiblity will be remain for an > empty set of packages. I can see your point about backward compatibilty, > but IMHO it's not really sensible to require it even if no existing > package will be affected any more... > > Currently there are 1729 packages that contain bullets that will be > interpreted as such by aptitude and thus would need to be checked. > > Using a bit of scripting it should be possible to do the later in a day or > so. I did run a quick check the other day to find out what was (potentially) affected by this particular problem, and there were only a handful of packages using full stops at the beginning of non-blank lines. I haven't thoroughly checked the rest of the archive, but I also haven't heard complaints about any other rendering problems with bullets. Daniel
signature.asc
Description: Digital signature
