I haven't read the whole long thread, so perhaps this has been mentioned
by someone else. Python has recently decided to convert their
documentation to reStructuredText [1]. It would make a lot of sense for
Debian to use that de-facto standard (or some subset of it) for text
typesetting in the
On Wed, 13 May 2009, Morten Kjeldgaard wrote:
I haven't read the whole long thread, so perhaps this has been mentioned
by someone else. Python has recently decided to convert their
documentation to reStructuredText [1]. It would make a lot of sense for
Debian to use that de-facto standard (or
On Thu, 23 Apr 2009, Daniel Burrows wrote:
For the sorts of markup our
descriptions have now it'll be fine, but it's my experience that when
you give people a hammer they start hitting everything that's vaguely
nail-shaped with it. :-)
ROFL.
The whole time of discussion was well spent just
On Tue, Apr 21, 2009 at 09:31:31AM +0200, Andreas Tille til...@rki.de was
heard to say:
Moreover I see no reason to bind anybody to a certain library
like markdown. My experience has shown that people will insist
on their very own way to do things. Do you think apt, aptitude,
synaptic etc.
On Tue, Apr 21, 2009 at 11:36:31PM +0200, Vincent Danjean wrote:
I've the impression that you didn't read my post, I might be wrong
though.
Do you read mine ?
Yes, but not the prev(prev(.)), sorry about that.
With that convention, you can use Markdown out of the box (on each
paragraph)
On Wed, Apr 22, 2009 at 07:34:45AM +0200, Andreas Tille wrote:
Well, *if* something is *recommended* in the docs filing wishlist bugs
against packages that ignore the recommendation are fine. Why else
should we issue recommendations?
For people writing new long descriptions, first off. That
On Tue, 21 Apr 2009, Don Armstrong wrote:
There's no point to defining rules without a working implementation,
because we don't know what the rules should be.
So I tried to do an implementation for the tasks pages of Blends which
works for unordered lists as discussed here and I also made
On Mon, Apr 20, 2009 at 11:24:42PM +0200, Andreas Tille wrote:
Here is the URL of the poll:
http://doodle.com/2bp8rrh3i35sr4s7
Heya, thanks for the poll.
Nevertheless, I think I got a bit lost in the discussion.
Following it, I had the impression that there was a quasi-agreement on
On Tue, 21 Apr 2009, Stefano Zacchiroli wrote:
Nevertheless, I think I got a bit lost in the discussion.
Following it, I had the impression that there was a quasi-agreement on
Markdown. Hence, I'm wondering what is the exact purpose of your
poll. With Markdown, you have alternative markers for
On Tue, 21 Apr 2009, Andreas Tille wrote:
I'm afraid that this leaves to much space for broken input as the
airport-utils example in the end of [1] shows. Manoj tried to prove
that markdown works perfectly - but it does not because the
indentantion of the original input is just wrong. I want
Don Armstrong wrote:
On Tue, 21 Apr 2009, Andreas Tille wrote:
Moreover I see no reason to bind anybody to a certain library like
markdown.
It's perfectly ok to punt the specification of the format to an
external library, at least initially. If enough people don't want to
use the markdown
ti, 2009-04-21 kello 10:37 +0200, Vincent Danjean kirjoitti:
As shown before in the other thread, markdown does not work with
the current long description : it needs pre-processing to add some
blank lines before each list.
That's true. Because the Packages and debian/control files are in
On Tue, Apr 21, 2009 at 10:37:00AM +0200, Vincent Danjean wrote:
As shown before in the other thread, markdown does not work with
the current long description : it needs pre-processing to add some
blank lines before each list.
I've the impression that you didn't read my post, I might be
ti, 2009-04-21 kello 12:00 +0200, Andreas Tille kirjoitti:
In principle this is fine as well. That's why my initial mail[1]
said This suggestion is far from complete and should be enhanced.
If there is a need to relax my strictly German habit to trimm
everything very tidy - people should have
On Tue, 21 Apr 2009, Andreas Tille wrote:
On Tue, 21 Apr 2009, Don Armstrong wrote:
So long as we have an implementation which works for the vast
majority of cases we can file bugs to make it work for the few
cases where it doesn't. (Or the output can just be slightly broken
in those cases;
On Tue, 21 Apr 2009, Don Armstrong wrote:
There's no point to defining rules without a working implementation,
because we don't know what the rules should be. Once there is a
working implementation that works for a reasonable majority of the
descriptions, we can define rules based on the
On Tue, 21 Apr 2009, Don Armstrong wrote:
So long as we have an implementation which works for the vast majority
of cases we can file bugs to make it work for the few cases where it
doesn't. (Or the output can just be slightly broken in those cases;
it's not like that's a huge problem.)
IMHO
On Tue, 21 Apr 2009, Lars Wirzenius wrote:
Properly here should mean anything that the markdown language says is
OK. The markdown language is remarkably relaxed about indentation. It
can handle it fine if one list is indented by two space, and other by
three. There seems to be no need for
On Tue, Apr 21, 2009 at 01:08:24PM +0300, Lars Wirzenius wrote:
Very well: your tendency towards strict consistency needs to be
relaxed. :)
Thus as far as I can see there is a rough consensus and the following
should happen:
That's my reading as well. (Adding back -policy to the recipient
ti, 2009-04-21 kello 11:27 +0200, Andreas Tille kirjoitti:
On Tue, 21 Apr 2009, Stefano Zacchiroli wrote:
Anticipating a potential objection: nested lists do work without
needing blank lines to separate nesting levels; I've just tried that
out.
... provided that lists are formated
On Tue, 21 Apr 2009, Stefano Zacchiroli wrote:
Anticipating a potential objection: nested lists do work without
needing blank lines to separate nesting levels; I've just tried that
out.
... provided that lists are formated properly in the first place (keyword:
broken spacings). That's why I
Hi,
On Dienstag, 21. April 2009, Andreas Tille wrote:
There is no point in implementing better markup for the Blends pages
if I know from the beginning that I will end up with broken pages
for an undetermined time.
Perfect is the enemy of good.
regards,
Holger
signature.asc
Stefano Zacchiroli wrote:
On Tue, Apr 21, 2009 at 10:37:00AM +0200, Vincent Danjean wrote:
As shown before in the other thread, markdown does not work with
the current long description : it needs pre-processing to add some
blank lines before each list.
I've the impression that you didn't
On Tue, Apr 21, 2009 at 12:36:14PM +0300, Lars Wirzenius wrote:
ti, 2009-04-21 kello 11:27 +0200, Andreas Tille kirjoitti:
On Tue, 21 Apr 2009, Stefano Zacchiroli wrote:
Anticipating a potential objection: nested lists do work without
needing blank lines to separate nesting levels;
On Tue, 21 Apr 2009, Michael Banck wrote:
I for one like visual consistency even when reading package descriptions
via apt-cache etc.
It must be a boring German habit - I always felt this way myself. I
started some action when I noticed that my feeling turned out to
have technical advantages
Hi,
as promissed in the overlongish thread [1] I would like to
sort out the details how we should enhance the consistency and
parseability of our long descriptions in a poll. I agree that
it is not a good idea to solve technical issues in a poll.
But this is not about a technical issue. There
Andreas Tille wrote:
But what exactly do I have to do to get the item lists marked?
Remove the first space, remove the '.' that are alone on their line,
add a blank line before enumeration (this last point seems the more
annoying to me: it can be difficult to automatically find where to
insert a
Peter Pentchev r...@ringlet.net writes:
Just as a kind of clarification: Manoj, I think that Giacomo's
comments were only to the *last* item of the text he quoted, not to
the whole portion above it :) Thus, IMHO his first really needed?
question referred specifically to the ordered lists
On Sat, 18 Apr 2009, Vincent Danjean wrote:
Remove the first space, remove the '.' that are alone on their line,
That's cheap.
add a blank line before enumeration (this last point seems the more
annoying to me: it can be difficult to automatically find where to
insert a blank line).
Well
On Sat, Apr 18 2009, Andreas Tille wrote:
On Sat, 18 Apr 2009, Vincent Danjean wrote:
Remove the first space, remove the '.' that are alone on their line,
That's cheap.
add a blank line before enumeration (this last point seems the more
annoying to me: it can be difficult to automatically
On Sat, 18 Apr 2009, Manoj Srivastava wrote:
Here is an algorithm:
--8---cut here---start-8---
we are not in a list
while reading each line, do
remove leading space
if the only non white space character on the line is a singe .
remove the dot
On Sat, Apr 18 2009, Andreas Tille wrote:
On Sat, 18 Apr 2009, Manoj Srivastava wrote:
Here is an algorithm:
--8---cut here---start-8---
we are not in a list
while reading each line, do
remove leading space
if the only non white space
On Sat, 18 Apr 2009, Manoj Srivastava wrote:
Frankly, I have no idea where this trade is going.
IMHO the problem is that you assume our suggestions are in contrast to
each other - but they are not. I wanted to iron out suggestions how
to format the input in a standardised way. What
On Thu, 16 Apr 2009, Manoj Srivastava wrote:
Which is good, since Markdown/ReST rules for lists will only
make the lists using o as the bullet out of whack.
Fine.
None of which are mandatory. All the package descriptions I read
in /var/lib/dpkg/available seems to pass, though
On Thu, Apr 16, 2009 at 03:01:30PM -0500, Manoj Srivastava wrote:
On Thu, Apr 16 2009, Giacomo Catenazzi wrote:
Manoj Srivastava wrote:
- Ability to recognize and render the following logical entities, in
decreasing order of importance:
+ unordered lists
+ ordered lists
On Thu, 16 Apr 2009, Manoj Srivastava wrote:
Manoj Srivastava wrote:
- Ability to recognize and render the following logical entities, in
decreasing order of importance:
+ unordered lists
+ ordered lists
really needed?
I would think these are the guts of this proposal. Or
On Thu, 16 Apr 2009, Guillem Jover wrote:
,-- count-bullet-chars.sh --
#!/bin/sh
lists=/var/lib/apt/lists/*_sid_main_*_Packages
total=`grep ^ *[-+\*o] $lists | wc -l`
for tag in \* - + o; do
items=`grep ^ *$tag $lists | wc -l`
percent=`echo scale=4; $items / $total * 100 | bc`
echo Tag
Andreas Tille a écrit :
I have not found any recommendation regarding this at the SRP Wiki page
[1].
I vaguely remember that this Smith project was initially driven by a French
guy who might try to push a French habit into the English world. ;-)
Of course. Because, contrary to the world of
On Wed, Apr 15 2009, Guillem Jover wrote:
Tag \* was used 9277 times (68.0900%)
Tag - was used 3837 times (28.1600%)
Tag + was used 120 times (.8800%)
Tag o was used 390 times (2.8600%)
Regardless of the numbers though (which have moved lately slightly in
favour of '-' due to the
to, 2009-04-16 kello 08:42 +0200, Christian Perrier kirjoitti:
I have never been able to find any such solid reference for English.
There is probably something in the Chicago Manual of Style, that's
generally accepted as the Right Reference for en_US.
Maybe more input from our experts on
On Thu, 16 Apr 2009, Manoj Srivastava wrote:
Do we really have nothing better to do than to impose
bureaucratic rules on what characters to use as bullet symbols in long
descriptions even if the user can tell that the character is a bullet?
The user can tell, but scripts can't
On Thu, Apr 16 2009, Andreas Tille wrote:
On Thu, 16 Apr 2009, Manoj Srivastava wrote:
Do we really have nothing better to do than to impose
bureaucratic rules on what characters to use as bullet symbols in long
descriptions even if the user can tell that the character is a bullet?
On Thu, 16 Apr 2009, Manoj Srivastava wrote:
Any script should be able to take the top 4 symbols currently
used, and be able to detect them. I think *, +, - and o cover most
packages, and the scripts in question can be readily expanded. All
kinds of markup languages already do something
On Thu, Apr 16, 2009 at 02:34:52AM -0500, Manoj Srivastava wrote:
Having sad that, I would not be averse to specifying that leading
white space and *, +, and - would be acceptable as bullet marks (I
thought specifying which mark at which level was overspecification).
Why don't we
On Thu, Apr 16 2009, Andreas Tille wrote:
On Thu, 16 Apr 2009, Manoj Srivastava wrote:
Any script should be able to take the top 4 symbols currently
used, and be able to detect them. I think *, +, - and o cover most
packages, and the scripts in question can be readily expanded. All
(following up on IRC discussion)
Manoj Srivastava sriva...@debian.org writes:
I suggest we follow a convention and tool set already in place,
with multiple language bindings, if you must insist on adding rules to
the long description.
There are alternatives (Text::Textile
On Thu, 16 Apr 2009, Manoj Srivastava wrote:
my initial posting. Detecting these would need either a defined
character or a defined spacing (IMHO an 'and' would be better than
a non-exclusive 'or' here).
Umm. I am not sure that follows. I am also not convinced we need
to invent our
On Thu, Apr 16, 2009 at 04:01:20AM -0500, Manoj Srivastava wrote:
Umm. I am not sure that follows. I am also not convinced we need
to invent our own rules. Text::Markdown or Text::MultiMarkdown could
help. And they do not seem to have issues with recognizing
indentation/different
Ben Finney ben+deb...@benfinney.id.au writes:
(following up on IRC discussion)
Manoj Srivastava sriva...@debian.org writes:
I suggest, for readability, to use a subset of markdown; the
link and image tags are not that human readable.
reStructuredText
On Thu, 16 Apr 2009, Ben Finney wrote:
Note that, like Manoj, I'm suggesting only a *subset*, not the full
specification.
Well, in this thread we had several suggestions reaching from complete
change to different format up to not in detail specified subsets of
other formats. IMHO this does
On Thu, Apr 16 2009, Ben Finney wrote:
(following up on IRC discussion)
Manoj Srivastava sriva...@debian.org writes:
I suggest we follow a convention and tool set already in place,
with multiple language bindings, if you must insist on adding rules to
the long description.
On Thu, Apr 16 2009, Andreas Tille wrote:
On Thu, 16 Apr 2009, Ben Finney wrote:
Note that, like Manoj, I'm suggesting only a *subset*, not the full
specification.
Well, in this thread we had several suggestions reaching from complete
change to different format up to not in detail
On Thu, Apr 16 2009, Tzafrir Cohen wrote:
On Thu, Apr 16, 2009 at 04:01:20AM -0500, Manoj Srivastava wrote:
Umm. I am not sure that follows. I am also not convinced we need
to invent our own rules. Text::Markdown or Text::MultiMarkdown could
help. And they do not seem to have
On Thu, Apr 16 2009, Andreas Tille wrote:
On Thu, 16 Apr 2009, Manoj Srivastava wrote:
my initial posting. Detecting these would need either a defined
character or a defined spacing (IMHO an 'and' would be better than
a non-exclusive 'or' here).
Umm. I am not sure that follows. I
Hi,
Oh, markdown is only confused when you have `two' `words'
quoted like this, wqhen there is only one such quote in the package, we
are fine.
pThis package contains the programs `abc2midi' which/p
So, less than 149 instances of the code tag where we want none.
Quoting Lars Wirzenius (l...@liw.fi):
to, 2009-04-16 kello 08:42 +0200, Christian Perrier kirjoitti:
I have never been able to find any such solid reference for English.
There is probably something in the Chicago Manual of Style, that's
generally accepted as the Right Reference for en_US.
Hi,
I think we need to enumerate some goals for this proposed
change. Here is a start:
- Minimal disruption for current packages. The impact should be
measured by numbers of packages impacted
+ Any specification of which of *, +, - to use as th first level item
will impact
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Manoj Srivastava wrote:
- Ability to recognize and render the following logical entities, in
decreasing order of importance:
+ unordered lists
+ ordered lists
really needed?
+ emphasis
+ strong emphasis
+ definition lists
On Thu, Apr 16 2009, Giacomo Catenazzi wrote:
Manoj Srivastava wrote:
- Ability to recognize and render the following logical entities, in
decreasing order of importance:
+ unordered lists
+ ordered lists
really needed?
I would think these are the guts of this proposal.
On Thu, Apr 16, 2009 at 12:50:12PM -0500, Manoj Srivastava wrote:
I think we need to enumerate some goals for this proposed
change. Here is a start:
- Minimal disruption for current packages. The impact should be
measured by numbers of packages impacted
snip
At this point, I would say
Hi!
On Mon, 2009-03-23 at 13:26:36 +0100, Andreas Tille wrote:
On Mon, 23 Mar 2009, Michael Banck wrote:
So it would be great if some numbers could be brought up first (maybe
Andreas has a rough overview now, because he looked at the different
kinds of itemizations).
Well, I had not but
On Wed, 8 Apr 2009, Guillem Jover wrote:
There's been a wiki page trying to track this, including packages
which formatting was proving problematic:
http://wiki.debian.org/Aptitude::Parse-Description-Bullets=true
Great. The most important information from this page for myself is that
there
Hi!
On Mon, 2009-03-23 at 16:23:12 -0700, Daniel Burrows wrote:
I don't have the energy to push this any more, but I should probably
at least refer to my previous attempt to standardize bulleted lists:
http://lists.debian.org/debian-devel/2005/12/msg00531.html
You might find it
On Mon, Mar 23, 2009 at 07:18:07PM +0100, Michael Banck wrote:
Uh, what are you saying here? That we should use * to prepend
items in itemized lists, so that it can be converted to HTML lists by
packages.debian.org et al.? If not, what else?
Yes.
More generally, I believe we can benefit
Quoting Michael Banck (mba...@debian.org):
Please note that debian-l10n-english suggests using the enumeration
style you mention for a2ps, when we're reviewing package
descriptions...
What's the rationale? So far, I was under the impression that *
A not very strong one, I'm
On Mon, 23 Mar 2009, Christian Perrier wrote:
What's the rationale? So far, I was under the impression that *
A not very strong one, I'm afraid..:-)
IIRC, we once found some reference indicating a tendency for dashed
enumerations to be an accepted standard but I can't quote this.
On Mon, Mar 23, 2009 at 07:24:45AM +0100, Christian Perrier wrote:
Quoting Michael Banck (mba...@debian.org):
Please note that debian-l10n-english suggests using the enumeration
style you mention for a2ps, when we're reviewing package
descriptions...
What's the rationale? So far,
On Mon, 23 Mar 2009, Michael Banck wrote:
So it would be great if some numbers could be brought up first (maybe
Andreas has a rough overview now, because he looked at the different
kinds of itemizations).
Well, I had not but you can get it somehow by
for tag in \* - + o ; do
echo Tag
On Fri, Mar 20, 2009 at 02:45:09PM +0100, Andreas Tille wrote:
I do not propose drastic changes but a start for Best practices
might be reasonable and perhaps some lintian warnings might help to
remind developers to move to some standard.
Laudable initiative, thanks for raising the issue. The
On Mon, 23 Mar 2009, Stefano Zacchiroli wrote:
In particular, I observe that we (IIRC) already have psuedo-parsing
code which is used at least by packages.d.o to render as proper HTML
lists the pseudo-lists which come from long descriptions.
Not that I know of. IMHO it is just set verbose
Quoting Andreas Tille (til...@rki.de):
Could you please clarify whether you mean *enumeration* (in the sense
I meant itemization, actually, so more ul than ol. There are
certainly very few cases where ordered lists are really useful in
packages' description.
Sorry for the approximative
On Mon, Mar 23, 2009 at 02:32:17PM +0100, Stefano Zacchiroli wrote:
In that respect, resisting the NIH syndrome just means choose an
already existing text-based markup language and adopt its
convention. For instance, we can just say that long description lists
have to be formatted as Markdown
I don't have the energy to push this any more, but I should probably
at least refer to my previous attempt to standardize bulleted lists:
http://lists.debian.org/debian-devel/2005/12/msg00531.html
You might find it useful, or not. At least it more or less documents
current practice in
On Sun, 22 Mar 2009, Michael Bramer wrote:
if we like to remove the long description from the package file, we must
change apt in some way and use some other rules for select the right
description (a new 'Description-md5sum' or the Version-Nr)
I'd call the Version-Nr. a sinsible choice. ;-)
On Sat, 21 Mar 2009, Christian Perrier wrote:
Please note that debian-l10n-english suggests using the enumeration
style you mention for a2ps, when we're reviewing package
descriptions...
BTW, once you answered in this thread: Shouldn't we make the suggested
enhancements part of the
Quoting Andreas Tille (til...@rki.de):
On Sat, 21 Mar 2009, Christian Perrier wrote:
Please note that debian-l10n-english suggests using the enumeration
style you mention for a2ps, when we're reviewing package
descriptions...
BTW, once you answered in this thread: Shouldn't we make the
On Sat, Mar 21, 2009 at 10:52:10PM +0100, Andreas Tille wrote:
I agree that some descriptions are definitely to long. I wonder who
should really read some descriptions to the end. Bad examples can
be viewn here:
http://debian-med.alioth.debian.org/tasks/typesetting.html
The very long
On Sun, 22 Mar 2009, Lionel Elie Mamane wrote:
http://debian-med.alioth.debian.org/tasks/typesetting.html
The very long lengths seem to come mostly from lists of CTAN packages
in a Debian package; I find these useful, as I can apt-cache search
CTAN_package to find it in Debian.
Yes, I'm
Lionel Elie Mamane lio...@mamane.lu writes:
The very long lengths seem to come mostly from lists of CTAN
packages in a Debian package; I find these useful, as I can
apt-cache search CTAN_package to find it in Debian.
For that purpose, it would seem ‘apt-file’ can do the job better,
obviating
Neil Williams wrote:
If large numbers of package descriptions are to change collectively,
it's best to make that one change with two aims rather than two separate
changes. Less work for everyone involved.
But Andreas' RFC affects the source packages, yours only affects the
infrastructure
On Sat, Mar 21, 2009 at 11:13:54PM +0100, Christian Perrier wrote:
Quoting Andreas Tille (til...@rki.de):
Package: a2ps
- various encodings (all the Latins and others),
- various fonts (automatic font down loading),
- various medias,
^^ (two spaces)
Please note that
On Fri, 20 Mar 2009 19:15:00 -0400
Filipus Klutiero chea...@gmail.com wrote:
On Fri, 20 Mar 2009 14:45:09 +0100 (CET)
Andreas Tille til...@rki.de wrote:
I tried to find a clear advise how to reasonable format lists inside long
descriptions of packages. The only thing I know is that
On Fri, 20 Mar 2009 23:32:51 +0100
Michael Banck mba...@debian.org wrote:
On Fri, Mar 20, 2009 at 07:20:43PM +, Neil Williams wrote:
I'd like to get the longest descriptions out of Packages.gz completely,
so encouraging their retention it not ideal. It's not about whether 2
or 3 spaces
On Sat, 21 Mar 2009 12:28:36 +0900
Paul Wise p...@debian.org wrote:
On Sat, Mar 21, 2009 at 8:15 AM, Filipus Klutiero chea...@gmail.com wrote:
The extended description needs to be available to APT, not only via
packages.d.o.
I agree with Neil William's comment in the other thread about
On Sat, Mar 21, 2009 at 4:58 PM, Neil Williams codeh...@debian.org wrote:
It's another instance of duplication - why retain the long description
in the Packages file while a translated version also exists from DDTP?
Probably better for the description to be removed from the Packages
file
On Fri, 20 Mar 2009, Neil Williams wrote:
Packages.gz is already 26Mb - I'd like to find ways to shorten the
package descriptions, not lengthen it. :-(
Please read again. Chances are good that packages files might
become shorter.
The rationale behind this is that with some
better standard
On Fri, 20 Mar 2009, Neil Williams wrote:
My comment for this RFC is, therefore, that better formatting for long
descriptions should include a review of whether the long description
deserves to be that long in the first place, whether the long
description merely duplicates data already
On Fri, 20 Mar 2009, Filipus Klutiero wrote:
2. Does not break any existing tool
I tend to agree with Martin. Do you have a particular reason making this
change urge?
Just to give the suggestion a small chance. I'm not against a better
format but I have read enough suggestions that
Quoting Andreas Tille (til...@rki.de):
Package: a2ps
- various encodings (all the Latins and others),
- various fonts (automatic font down loading),
- various medias,
^^ (two spaces)
Package: acerhk-source
* controlling LEDs (Mail, Wireless)
* enable/disable wireless hardware
Paul Wise schrieb:
On Sat, Mar 21, 2009 at 4:58 PM, Neil Williams codeh...@debian.org wrote:
It's another instance of duplication - why retain the long description
in the Packages file while a translated version also exists from DDTP?
Probably better for the description to be removed from
Neil Williams wrote:
On Fri, 20 Mar 2009 19:15:00 -0400
Filipus Klutiero chea...@gmail.com wrote:
[...]
What about a way of having a really long, detailed, nicely formatted
description on packages.debian.org but a much shorter, more basic
version in the Packages.gz file?
The
Hi,
I tried to find a clear advise how to reasonable format lists inside long
descriptions of packages. The only thing I know is that lines with two
leading spaces is considered verbose. This leaves a lot of freedom to
simulate for instance itemize lists. I'd like to give some examples for
also sprach Andreas Tille til...@rki.de [2009.03.20.1445 +0100]:
I tried to find a clear advise how to reasonable format lists inside long
descriptions of packages. The only thing I know is that lines with two
leading spaces is considered verbose. This leaves a lot of freedom to
simulate for
On Fri, 20 Mar 2009, martin f krafft wrote:
What we really should do, instead of clinging to the NIH-behaviour,
reinventing the wheel, and polishing it over and over again is ditch
the pseudo-RFC822 format we have and use Yaml instead.
http://www.yaml.org/start.html
http://yaml.org/spec/1.2/
On Fri, Mar 20, 2009 at 02:45:09PM +0100, Andreas Tille wrote:
1. Itemize lists: (li)
2. Enumerate lists: (ol)
--
3. Description lists: (dl)
This suggestion is far from complete and should be enhanced.
Well,
On Fri, 20 Mar 2009 14:45:09 +0100 (CET)
Andreas Tille til...@rki.de wrote:
I tried to find a clear advise how to reasonable format lists inside long
descriptions of packages. The only thing I know is that lines with two
leading spaces is considered verbose.
Packages.gz is already 26Mb -
On Fri, 2009-03-20 at 19:03 +, Neil Williams wrote:
On Fri, 20 Mar 2009 14:45:09 +0100 (CET)
Andreas Tille til...@rki.de wrote:
I tried to find a clear advise how to reasonable format lists inside long
descriptions of packages. The only thing I know is that lines with two
leading
Neil Williams wrote:
On Fri, 20 Mar 2009 14:45:09 +0100 (CET)
Andreas Tille til...@rki.de wrote:
I tried to find a clear advise how to reasonable format lists inside long
descriptions of packages. The only thing I know is that lines with two
leading spaces is considered verbose.
On Fri, 20 Mar 2009 20:08:43 +0100
Julien Cristau jcris...@debian.org wrote:
On Fri, 2009-03-20 at 19:03 +, Neil Williams wrote:
On Fri, 20 Mar 2009 14:45:09 +0100 (CET)
Andreas Tille til...@rki.de wrote:
I tried to find a clear advise how to reasonable format lists inside long
On Fri, Mar 20, 2009 at 07:20:43PM +, Neil Williams wrote:
I'd like to get the longest descriptions out of Packages.gz completely,
so encouraging their retention it not ideal. It's not about whether 2
or 3 spaces should be used, it's about whether such detailed content
deserves to be in
1 - 100 of 103 matches
Mail list logo
