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

Re: RFC: Better formatting for long descriptions



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 character on the line is a singe .
>>     remove the dot
>>   if the line matches the regexp: '^\s+[\*\+\-]\s+'
>>     if we are not in a list
>>       emit blank line first
>>       record we are not in a list
                       s/not//
>>   else
>>     if we are in a list
>>       record we are not in a list
>>   emit line
>> --8<---------------cut here---------------end--------------->8---
>>
>>        People who can not convert this 13 line Psuedocode into a real
>> code should not be writing stuff to pretty print descriptions.
>
> Thanks for the trust in the programming skills of your fellow
> developers.  You obviosely are able to write the code to detect
> a list *without* using a library.  Wasn't it you who told me we
> should use a library to *avoid* inventing our own code?  So if
> you have this code which works perfectly on the input I'm
> suggesting since two weeks why you want to add an additional library
> on top of this.  I feel a little bit bored by this discussion which
> is running several circles starts to become personal without any
> real reason (I hope I did not gave any) and finally leads to nothing
> (at least this is my impression).

        Frankly, I have no idea where this trade is going.

        With a 6 line pre-processor, you can feed the grep-dctrl
 provided Description fields to Markdown. So, seems like we have come
 somewhere -- we have had one investigation that leads one to believe
 that there are a small fraction of packages using "o" as a bullet that
 need to be changed, and apart fro that there are less than 50 packages
 are affected (if we want to specify markdown as the markup language for
 descriptions -- and these are the one where we have some unwanted
 emphasis, a non-fatal result).

        There is a mechanism to pre-process  the description for
 markdown (Perl implementation below). What more is needed for you to
 think this is leading somewhere?

>>> enclose lists in blank lines because people will tell you that
>>> this will look ugly in the existing interfaces.  So I would rather
>>> tend to "No for both" and this is the crux here.
>>
>>        Frankly, I think this is very wrong.
>
> The solution does not work without the code you wrote above.  But you
> need this code anyway to detect lists in the long descriptions and so
> I wonder where the real profit of an additional library is.

        *Sigh*.

        All I am doing with the code is inserting a line before the
 lists. I am not generating html. I am not also handling the _other_
 markup that markdown handles, that I presented as something that will
 make the description more readable too. The markdown librarys does all
 the heavy lifting fro the html generation. If you think my little perl
 snippet is the equivalent for what markdown does, you have not looked
 at markdown.

        I am not re-inventing the wheel when it comes to markup
 languages. 

        We know we needed _some_ pre-processing because we have the
 paragraphs separated by ' .', but the code is pretty minimal.

--8<---------------cut here---------------start------------->8---
 my $in=0;
 while(<>) {
  chomp;  s/^ //g;  s/^\.\s*$//;
  if(/^\s+[\*\+\-]\s+/) { print "\n" unless $in++;}
  else                  { $in=0; }
  print "$_\n"
}
--8<---------------cut here---------------end--------------->8---

        manoj

ps: This can easily become a shell function.

__> grep-aptavail -s Description -P airport-utils | perl -e '
 my $in=0;
 while(<>) {
  chomp;  s/^ //g;  s/^\.\s*$//;
  if(/^\s+[\*\+\-]\s+/) { print "\n" unless $in++;}
  else                { $in=0; }
  print "$_\n"
}' | markdown
<p>Description: configuration and management utilities for Apple AirPort base stations
This package contains various utilities to manage the Apple AirPort base
stations.</p>

<p>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.</p>

<p>For the original Apple AirPort and the Lucent RG-1000 base stations only:</p>

<ul>
<li>airport-config: base station configurator</li>
<li>airport-linkmon: wireless link monitor, gives information on the wireless
link quality between the base station and the associated hosts</li>
</ul>

<p>For the Apple AirPort Extreme base stations only:</p>

<ul>
<li>airport2-config: base station configurator</li>
<li>airport2-portinspector: port maps monitor</li>
<li>airport2-ipinspector: WAN interface monitoring utility</li>
</ul>

<p>For all:</p>

<ul>
<li><p>airport-modem: modem control utility, displays modem state, starts/stops
modem connections, displays the approximate connection time (Extreme only)</p>

<ul>
<li>airport-hostmon: wireless hosts monitor, lists wireless hosts connected
to the base station (see airport2-portinspector for the Snow)</li>
</ul></li>
</ul>

-- 
Never call a man a fool; borrow from him.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


Reply to: