|
From: Yuri T. <qar...@gm...> - 2007-10-11 07:29:31
|
Those changes all make sense to me. The first and the last ones are
just plain bugs. The second one doesn't make much difference in HTML,
but I suppose it would be cleaner if the extra spaces are removed.
- yuri
On 10/10/07, Waylan Limberg <wa...@gm...> wrote:
> I've committed these changes in r41. I suspect item (1) would be the
> only item that would cause any real issues. If it's a problem, I have
> a workaround. It just seemed hackish and unnecessary so I left it out
> barring any complaints. Please let me know if any issues are
> encountered.
>
> On 10/9/07, Waylan Limberg <wa...@gm...> wrote:
> > I've been working on a few different bugs related to line breaks. In
> > doing so, I've found some questionable side effects of the current
> > implementation that do not always make sense or correspond with perl
> > or php variations. I realize that just because markdown.pl or php do
> > something a certain way, doesn't mean we should, but I think it makes
> > sense here.
> >
> > So my question is, would anyone have any objection to the following changes?
> >
> > (1) Currently, in python two spaces are converted to a linebreak at
> > the end of a *header*. Seeing headers are always one line, what value
> > does this add? Neither php nor perl support this. Would anyone miss
> > this if I removed it? (It would make an inlinePattern for linebreaks
> > **much** easier.)
> >
> > (2) I noticed that the two spaces are always preserved in output ("
> > <br />\n"). Is this necessary? For example (spaces replaced with +s
> > for clarity):
> >
> > Line with a break.++
> >
> > currently becomes:
> >
> > Line with a break.++<br />
> >
> > instead of:
> >
> > Line with a break.<br />
> >
> > IMO this doesn't really matter one way or the other, but I'm getting
> > test failures over this and am inclined to strip the extra whitepsace
> > from the tests. Any thoughts?
> >
> > (1). Currently a blank line composed of at least two spaces becomes a
> > line break "<br />". This is not inline with either perl or php and
> > can have some interesting side effects. Note this example from
> > "tests/misc/some-tests.txt" (I've replaced the indentation with '+'s
> > for clarity):
> >
> > * Python is
> > ok
> > ++++Or not?
> > +++
> > Here is a normal paragraph
> >
> > 1. Another list
> >
> > I would expect the output given by perl or php:
> >
> > <ul>
> > <li>Python is
> > ok
> > Or not?</li>
> > </ul>
> >
> > <p>Here is a normal paragraph</p>
> >
> > <ol>
> > <li>Another list</li>
> > </ol>
> >
> > Instead python-markdown gives us:
> >
> > <ul>
> > <li><p>Python is
> > ok
> > Or not?
> > <br />
> > Here is a normal paragraph
> > </p>
> >
> > </li>
> >
> > <li><p>Another list
> > </p>
> >
> > </li>
> > </ul>
> >
> > Removing the 'blank line with spaces becomes a linebreak' rule
> > addresses this issue. Is there a legitimate use case for these lines
> > that I'm missing?
> >
> > If no one has any persuasive arguments for keeping the current
> > behaviour, I'll update the tests to reflect the changes and then
> > finish up my patches for the various linebreak bugs.
> >
> >
> > --
> > ----
> > Waylan Limberg
> > wa...@gm...
> >
>
>
> --
> ----
> Waylan Limberg
> wa...@gm...
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>
--
Yuri Takhteyev
Ph.D. Candidate, UC Berkeley School of Information
http://takhteyev.org/, http://www.freewisdom.org/
|