Re: RFC: Better formatting for long descriptions
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 a couple had italics
in strange places. This is not a fatal flaw.
No - this perfectly fits my intention that some descriptions have to be fixed.
We just need guidelines for developers to follow.
I find the descriptions on packages.d.o just fine right now.
IMHO it is no argument that a specific person is happy with the layout
everybody else is.
Just like it is no argument that someone think something is ugly
that means everyone thinks so too.
If a text has a certain logic it should to be
supported by the means a certain output style has. HTML can express a
list and so it should if we want to express lists.
Please do not split my paragraphs to blur my arguing. Thanks.
Heh. Ever heard of inline answers?
In most cases I manage to ignore this kind of questions. Try reading my
mail again to find out a reasonable answer to your question yourself.
I suggest you try it out, before handwaving vague FUD
around. Even tnftp description works fine with either. There are very
few descriptions (about 24 or so) where we might have unwanted
emphasis. I think we can have that fixed.
But what exactly do I have to do to get the item lists marked?
grep-available -s Description -F Package airport-utils | markdown
<p>Description: configuration and management utilities for Apple AirPort base stations
This package contains various utilities to manage the Apple AirPort base
stations.
.
Be aware that Apple released several versions of the AirPort base station;
the original AirPort ("Graphite") was a rebranded Lucent RG-1000 base
station, doing 802.11a/b. The AirPort Extreme ("Snow") is an Apple-built
802.11a/b/g base station.
.
For the original Apple AirPort and the Lucent RG-1000 base stations only:
- airport-config: base station configurator
- airport-linkmon: wireless link monitor, gives information on the wireless
link quality between the base station and the associated hosts
.
For the Apple AirPort Extreme base stations only:
- airport2-config: base station configurator
- airport2-portinspector: port maps monitor
- airport2-ipinspector: WAN interface monitoring utility
.
For all:
- airport-modem: modem control utility, displays modem state, starts/stops
modem connections, displays the approximate connection time (Extreme only)
- airport-hostmon: wireless hosts monitor, lists wireless hosts connected
to the base station (see airport2-portinspector for the Snow)</p>
$ grep-available -s Description -F Package tnftp | markdown
<p>Description: The enhanced ftp client
tnftp is what many users affectionately call the enhanced ftp
client in NetBSD (http://www.netbsd.org).
.
This package is a <code>port' of the NetBSD ftp client to other systems.
.
The enhancements over the standard ftp client in 4.4BSD include:
* command-line editing within ftp
* command-line fetching of URLS, including support for:
- http proxies (c.f: $http_proxy, $ftp_proxy)
- authentication
* context sensitive command and filename completion
* dynamic progress bar
* IPv6 support (from the WIDE project)
* modification time preservation
* paging of local and remote files, and of directory listings
(c.f:</code>lpage', <code>page',</code>pdir')
* passive mode support, with fallback to active mode
* <code>set option' override of ftp environment variables
* TIS Firewall Toolkit gate ftp proxy support (c.f:</code>gate')
* transfer-rate throttling (c.f: <code>-T',</code>rate')</p>
I would simplify the rule, as opposed to having a trivial
library call in the tool. Indeed, reusing the libraries provided is
*less* work for the parser, than a NIH new parser.
I'm really in favour of reusing a library (and I wonder whether I wrote
anything in contrast to this). I just fail to see any effect when using
markdown except that the description is now enclosed in <p></p> and
some other markups appear which could be fixed. But the intended result
to get a list markup is not reached. Or did I missed something?
I think we need the emphasis almost as much as we need lists;
and people are already using *word* for emphasis in desciptions
(though not all that many).
I'm not against implementing emphasis which might be also an interesting
enhancement and if it is a small amount of packages which need to be
fixed these most probably need to be fixed in plain text anyway. So if
you enlighten me how the lists could work I'm perfectly happy.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: