On Wed, Apr 29, 2009 at 12:13:14AM +0200, Andreas Tille wrote:
Yes, me too. But somewhere in this longish discussion it was
suggested to find a solution for currently existing descriptions and
ditch these cases later. I do not want to spend my time to seek for
the URL of this mail in the
On Wed, 29 Apr 2009, Stefano Zacchiroli wrote:
Well, if you just keep them as transitional period without
highlighting them as deprecated in some way, you will end up with
them forever. We all know how slow we are with this kind of
transitions :)
ACK
Given that the current semantics was to
On Mon, Apr 27, 2009 at 04:53:11PM -0400, James Vega wrote:
Please have a look at garlic-doc. It does not look right.
It's using `o' as the bullet character which is not supported by
Markdown/rST. This has already been identified as a case that will need
to be fixed by the individual
On Thu, 23 Apr 2009, Daniel Burrows wrote:
I'm happy to support whatever markup language people want to use.
Same for me. To feed some facts to be able to compare the options
I rendered the debug blends pages with reST using the very same code
for the preprocessing which does
1. s/^ //
On Tue, Apr 28, 2009 at 04:51:56PM +0200, Andreas Tille wrote:
On Thu, 23 Apr 2009, Daniel Burrows wrote:
I'm happy to support whatever markup language people want to use.
...
I used for markdown
...
and for reST
FYI:
As I checked popularity of similar plain text formatters via popcon,
Andreas Tille dijo [Tue, Apr 28, 2009 at 04:51:56PM +0200]:
3. s/^(\s*)[.o]\s+/\1* /
This enables rendering lists using 'o' and '.' as bullets
I know 'o' is a character visually similar to a bullet... But I would
really prefer to discourage its use as such, specially if now lists
will be
On Tue, 28 Apr 2009, Gunnar Wolf wrote:
But I'd prefer dropping 'o' as a bullet marker.
Yes, me too. But somewhere in this longish discussion it
was suggested to find a solution for currently existing descriptions
and ditch these cases later. I do not want to spend my time to
seek for the
On Mon, 27 Apr 2009, Stefano Zacchiroli wrote:
Given that we agree that that example is just plainly broken no matter
what, why do you consider it as a valid motivation for throwing all
away?
That's not what I intended. My intention is to give guidelines which
might be independent from a
On Mon, 27 Apr 2009, Stefano Zacchiroli wrote:
[ FWIW, if you want to try it out please use the live version [1],
I've just fixed a stupid bug which caused ignoring the last
paragraph of a description ]
[1]
On Sun, Apr 26, 2009 at 11:34:57PM -0500, Manoj Srivastava wrote:
If nobody from -policy objects, I'll submit it tomorrow.
Sounds good.
Done: #525843. Discussion can continue in that bug log now, I guess.
Also, a live archive of all long descriptions (from unstable/amd64)
rendered as
On Sat, Apr 25, 2009 at 10:12:45PM +0200, Andreas Tille til...@rki.de was
heard to say:
On Sat, 25 Apr 2009, Daniel Burrows wrote:
I would prefer Restructured Text, for the simple reason that it has an
actual specification with a fairly complete description of its syntax
and semantics.
I
On Mon, 27 Apr 2009, Daniel Burrows wrote:
Wow, that's a lot of work! I certainly won't ask you to do it all
over again.
No, not really. I might replace just the markdown by the reST
call. That's probabyl quite cheap and I might try this in the
next couple of days even while beeing under
On Mon, Apr 27, 2009 at 03:19:23PM +0200, Stefano Zacchiroli wrote:
On Sun, Apr 26, 2009 at 11:34:57PM -0500, Manoj Srivastava wrote:
If nobody from -policy objects, I'll submit it tomorrow.
Sounds good.
Done: #525843. Discussion can continue in that bug log now, I guess.
Also,
On Mon, Apr 27, 2009 at 08:05:11PM +0200, Bill Allombert wrote:
Also, a live archive of all long descriptions (from
unstable/amd64) rendered as Markdown using render-dctrl is now
available at http://upsilon.cc/~zack/stuff/longdesc-mdwn/ . It is
weekly re-generated. Anybody who spots absurd
On Mon, Apr 27, 2009 at 09:36:59PM +0200, Stefano Zacchiroli wrote:
On Mon, Apr 27, 2009 at 08:05:11PM +0200, Bill Allombert wrote:
Also, a live archive of all long descriptions (from
unstable/amd64) rendered as Markdown using render-dctrl is now
available at
On Mon, Apr 27, 2009 at 10:19:54PM +0200, Bill Allombert wrote:
On Mon, Apr 27, 2009 at 09:36:59PM +0200, Stefano Zacchiroli wrote:
On Mon, Apr 27, 2009 at 08:05:11PM +0200, Bill Allombert wrote:
Also, a live archive of all long descriptions (from
unstable/amd64) rendered as Markdown
[ resent ]
On Thu, Apr 23, 2009 at 08:06:28PM -0500, Manoj Srivastava wrote:
I suspect the answer might be to get a working implementation out
in the wild (it does not have to be packages.d.o or anything
official -- even a standalone software that takes the output from
grep-dctrl or
On Sun, 26 Apr 2009, Stefano Zacchiroli wrote:
I've on purpose not looked at Andreas implementation, in order to see
if we have mutually thought at different issues. That also means that
it can be utterly buggy, you have been warned :-)
At short look I have the following diff:
---
* Andreas Tille til...@rki.de, 2009-04-26, 22:55:
I tried to format a single paragraph according to some URL I found but
thie does not really work without a header[3].
[...]
[3] http://code.activestate.com/recipes/193890/
That's quite overcomplicated. The following code should do the thing:
On Sun, 26 Apr 2009, Stefano Zacchiroli wrote:
Library OCaml which provide a set of needed and useful macros for developing.
Modules and functionality are the follows :
.
- Configuration_files: Allow to get information from configuration files
- Environments: Environments are useful for
On Sun, Apr 26, 2009 at 10:55:31PM +0200, Andreas Tille wrote:
At short look I have the following diff:
[ FWIW, if you want to try it out please use the live version [1],
I've just fixed a stupid bug which caused ignoring the last
paragraph of a description ]
[1]
On Sun, Apr 26, 2009 at 11:25:32PM +0200, Andreas Tille wrote:
BTW, even if my implementation works for libocamlbricks-ocaml-dev
[1] I'd regard this rather as a bug than a feature, becuase it just
should not work
Agreed.
- it should be formatted as separate lists. When seeing cases like
On Sun, Apr 26 2009, Stefano Zacchiroli wrote:
Well, it depends on the goal. Mine was on the line of what I perceived
it was consensus (totally subjective perception), that of trying to
use a standard language: either Markdown or RST.
This is what I as trying to push towards, and I
Manoj Srivastava sriva...@debian.org writes:
But if we have tons of '.' or 'o' lists, for sure we will need to
break that rule and support them. Do you have numbers about how many
such lists we have? If they are just a few they can easily be fixed,
if they are half the archive (which I doubt,
On Fri, Apr 24, 2009 at 08:37:22AM +0200, Andreas Tille til...@rki.de was
heard to say:
2. Markdown is probably better in detecting second level lists
thank I would have done it programmatically - so here is
a benefit. On the other hand there are some strange false
positives
On Sat, 25 Apr 2009, Daniel Burrows wrote:
I would prefer Restructured Text, for the simple reason that it has an
actual specification with a fairly complete description of its syntax
and semantics.
I do not have practical experience with both and so I do not have
any preference. The only
Daniel Burrows dburr...@debian.org writes:
I would prefer Restructured Text, for the simple reason that it has an
actual specification with a fairly complete description of its syntax
and semantics. In constrast, I've never been able to find any useful
documentation of Markdown beyond what
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 Thu, 23 Apr 2009, Manoj Srivastava wrote:
Sure. It would be great to have another implementation, perhaps
one that people can play with (something that, for example, one can
pipe the output of a grep-dctrl command to, and get an html snippet
from (hey, that can then be packaged as an
On Wed, Apr 22, 2009 at 10:22:15AM -0500, Manoj Srivastava wrote:
On Wed, Apr 22 2009, Stefano Zacchiroli wrote:
On Tue, Apr 21, 2009 at 11:36:31PM +0200, Vincent Danjean wrote:
No. Adding blank lines before lists is also required.
... so, agreed. The extra price to pay to use Markdown
On Thu, Apr 23 2009, Stefano Zacchiroli wrote:
Considering all this thread, can you please summarize the point of
view of policy maintainers on the issue? (which is why I added back
the -policy Cc: in the first place)
While I can't speak for the policy team (I have not been
On Thu, 23 Apr 2009, Manoj Srivastava wrote:
While I can't speak for the policy team (I have not been
re-delegated yet), I suspect the answer might be to get a working
implementation out in the wild (it does not have to be packages.d.o or
anything official -- even a standalone software
On Thu, Apr 23 2009, Andreas Tille wrote:
On Thu, 23 Apr 2009, Manoj Srivastava wrote:
While I can't speak for the policy team (I have not been
re-delegated yet), I suspect the answer might be to get a working
implementation out in the wild (it does not have to be packages.d.o or
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
Stefano Zacchiroli z...@debian.org writes:
On Tue, Apr 21, 2009 at 11:36:31PM +0200, Vincent Danjean wrote:
No. Adding blank lines before lists is also required.
... so, agreed. The extra price to pay to use Markdown would be that
additional line insertion.
FWIW, the use of reST as a
On Wed, Apr 22 2009, Stefano Zacchiroli wrote:
On Tue, Apr 21, 2009 at 11:36:31PM +0200, Vincent Danjean wrote:
No. Adding blank lines before lists is also required.
... so, agreed. The extra price to pay to use Markdown would be that
additional line insertion.
And this is like 6
On Tue, Apr 21 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 Wed, 22 Apr 2009, Manoj Srivastava wrote:
And this is like 6 lines of Pseudo code, and less in compact
languages like Perl. A fairly trivial exercise in basic CS logic.
Please do not insist on the number of lines. I mentioned in my
mail [1] that you need a bit more. I did not said
On Mon, 20 Apr 2009, Manoj Srivastava wrote:
Frankly, a poll about micromanaging marks for each level of
unordered list does seem to be technical. It is also an implementation
detail, and invents our own convention,
I disagree.
and options 1 2 would cause
many more packages to be
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
Le Mon, Apr 20, 2009 at 05:55:20PM -0500, Manoj Srivastava a écrit :
Is there anyone other than yourself who is actually unhappy
about markdown/ReST?
Hi all, hi Andreas,
In the end, I do not think that it is a good idea to do typesetting in long
descriptions. In the packages I
Charles Plessy ple...@debian.org writes:
In the end, I do not think that it is a good idea to do typesetting in
long descriptions. In the packages I maintain, I will remove itemized
and ordered lists if there are. This will solve Andreases problem.
What will you replace them with? They are a
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
On Mon, Apr 20 2009, Andreas Tille wrote:
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.
64 matches
Mail list logo
