[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#302138: incorrect Description line wrapping with bullet lists

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 

      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 

  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 
    - 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 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: pgpAtfQoFPvlc.pgp
Description: PGP signature

Reply to: