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

Re: Consistent formating long descriptions as input data



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-dctrl.orig   2009-04-26 21:31:36.000000000 +0200
+++ render-dctrl        2009-04-26 22:00:13.000000000 +0200
@@ -104,6 +104,10 @@
             store_para()
             curpara, inlist, listindent = [], False, 0
         else:
+           # accept also '.' and 'o' as bullets
+           l = re.sub('^(\s*)[.o]\s+', '\\1* ', l)
+           # use real URLs
+           l = re.sub('<*([fh]t?tp://[-./\w?=~;&]+)>*', '[\\1](\\1)', l)
             m = mdwn_list_line.match(l)
             if not inlist and m and curpara:
                 # RULE 2: handle list item *not* at paragraph beginning


to enable working with currently used bullet symbols '.' and 'o' as well
as it was suggested above in the thread.  Moreover we should probably use
properly formated links if an URL is given.  Please not that my suggested
patch does not work in the examples I tried but I'm currently not able
to verify this.

You can view my implementation at [1] which leads to the examples
with several comments at [2].  I'd suggest to compare the result
of your implementation with the output on [2].

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 maintaining the state, intendend
as a set of bindings, of a user interaction with a GUI
 - FilenameExtra: Additional features for the standard module Filename

That's definitely broken and should be fixed anyway.

PS mail like this one of mine should be better stored in the log of a
  bug report against the policy, to keep track of the
  status.
  Andreas: do we have one already?

Not yet because I was not able to draw a final conclusion out of all
this discussion and I would also like to give reST a try (according
to two hints here on this list and the fact that there are some
problematic issues with markdown adn I have no clue why).  A better
documented library would be interesting - but I a hint how to use
reST would be helpful.  I tried to format a single paragraph according
to some URL I found but thie does not really work without a header[3].
Any "competing" implementation in reST to compare where we have less
problematic issues - or even if the issues are more in terms of
the number of broken formatting but if the reasons for these
breakages are clear would be OK.

  If not, can you please
  submit it with references to the thread? ... or else shout and
  I'll do that.

Please go for it - as I said my spare time might be restricted.
I'm not on vac but time consuming issues are not the first thing
I would touch the next couple of days.

Kind regards

       Andreas.

[1] http://svn.debian.org/viewsvn/blends/blends/trunk/webtools/blendstasktools.py?content-type=text%2Fplain
    --->  search for "def PrepareMarkdownInput(lines):"

[2] http://blends.debian.net/debug/tasks/
[3] http://code.activestate.com/recipes/193890/
--
http://fam-tille.de


Reply to: