On Mon, 25 Sep 2006, Daniel Burrows wrote:
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.
At the end of the day your solution sounds reasonable to me...
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.
I might go through them and check them.
*t
--
-----------------------------------------------------------------------
Tomas Pospisek
http://sourcepole.com - Linux & Open Source Solutions
------------------------------------------------------------------------
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
