On Wednesday 30 March 2005 05:19 am, Jeroen van Wolffelaar wrote:
> Ideally, all packaging tools would support some kind of very simple
> markup language to support enumerations in a sane way, but that's a
> long-term project.
There's room in the description standard for future extensions: quoting
Policy,
Those containing a space, a full stop and some more characters.
These are for future expansion. Do not use them.
We can also extend the description format in backwards-compatible ways. So,
while a proper markup language would be nice, that doesn't preclude fixing
the bullet problem, albeit in a slightly hacky way, NOW. What about this:
==========================
A line beginning with two or more spaces, followed by a bullet character and
a space, is considered to be an element of a bulleted list. Every succeeding
line that begins with N+1 or more spaces, where N is the number of spaces
preceding the bullet, is considered to be part of the same bulleted list, and
is processed as if N+1 spaces had been stripped from its left margin, with
the exception that if the N+2nd character is not a space, the line is
formatted as if a leading space were present. (see below)
Bullet characters are (maybe) "-", "+", "*", and "o"; the frontend may
render them literally or modify their appearence as it deems appropriate.
NOTE: it might be a good idea to exclude "o"; I doubt many packages use "o"
as a word by itself at the beginning of a literally-formatted line, but it
might be a word in some foreign language, which would cause problems once we
have translated descriptions. Unfortunately, this would make the format less
backwards-compatible.
==========================
This means that the current "best practice" for bulleted lists; eg,
Description: something with a bulleted list
This is a package. It has some features:
* A feature.
* Another feature.
* A feature I felt like
continuing onto the next line for some reason
* For backwards compatibility, some
variation in indentation is OK.
will be displayed as expected in all current frontends, while future
frontends will treat each of the last two items as a paragraph and word-wrap
it accordingly. Lists-within-lists would work like this:
Description: something with two bulleted lists
This is a package. It has lots of features:
* A feature.
* Another feature.
* A really complicated feature with subfeatures:
+ Subfeature 1
+ Subfeature 2
+ Subfeatures can also
continue to the next line.
.
We can also have paragraph separators.
* Another feature.
The only non-sensibly-rendering thing in legacy frontends would be the
literal full-stop, which could be avoided by discouraging the use of
multiple-paragraph list items (and really, descriptions shouldn't be that
complicated anyway...IMO).
Things to note:
- Older frontends will render descriptions in this format without any
difficulty.
- Newer frontends will either automagically detect bulleted lists in older
descriptions (all the proper lists that I found in a very small sample would
work exactly as expected) or display them literally (the current situation).
The worst case would be where the start of a list is literal and its
continuation is word-wrapped, but this would come out no worse than the
current situation:
* A feature
* Some other feature
but I want you to word-wrap the continuation.
All-in-all, I think that this is a nice low-cost way of getting proper
bullet support into the frontends. Comments?
Daniel
--
/------------------- Daniel Burrows <dburrows@debian.org> ------------------\
| "You keep on using that word. I do not think |
| it means what you think it means." |
| -- "The Princess Bride" |
\---------------- The Turtle Moves! -- http://www.lspace.org ---------------/
Attachment:
pgp1_Hp2aBhYd.pgp
Description: PGP signature