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 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 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 UR
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 b
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
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/^ //
2
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 pac
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 M
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 http://upsilon.cc/~
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
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.
>
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 s
On Sat, Apr 25, 2009 at 10:12:45PM +0200, Andreas Tille 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 do n
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 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]
http://git.debian.org/?p=pkg-python-debian/python-debian.git;a=blob_plain;f=examples/
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 libr
Manoj Srivastava 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, having seen
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
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 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]
http://git.debian.org/?p=p
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 mainta
* Andreas Tille , 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:
from docutils.
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:
--- render-dctr
[ 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-dct
Daniel Burrows 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 /usr/bin/markd
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 th
On Fri, Apr 24, 2009 at 08:37:22AM +0200, Andreas Tille 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 f
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 i
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 for
On Tue, Apr 21, 2009 at 09:31:31AM +0200, Andreas Tille 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. developers
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
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 th
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
re-del
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 Markdo
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 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
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 lik
Stefano Zacchiroli 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 format specifi
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 sure
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. Tha
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
> > pa
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
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
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
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
Desc
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 recipie
Charles Plessy 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 natural convent
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 impleme
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
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 mai
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
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 De
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 fo
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 t
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
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 wr
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
p
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 m
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 wan
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 d
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
Markdow
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 ch
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 po
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 i
64 matches
Mail list logo
