From: Waylan L. <wa...@gm...> - 2007-10-09 18:01:35
|
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... |
From: Waylan L. <wa...@gm...> - 2007-10-11 01:40:27
|
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... |
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/ |