|
Mon 02 Oct 2006 01:47:46 PM UTC, comment #10:
No longer reproducible on the dev branch.
|
Wed 08 Mar 2006 06:50:52 PM UTC, comment #9:
Well, in any cases there is something that goes wrong :)
|
Mon 06 Mar 2006 09:42:08 PM UTC, comment #8:
> If you do that, as <p> starts a new line (doesn't it?), you'll
> end up with an extra line break too.
No, fortunately not, because browsers ignore the last <br /> immediately before a closing </p> tag. With the example, we get exactly what the user intended: two lines of text, separated by a normal size paragraph gap.
> We can even wonder where the markup function should be called:
> inside or outside trackers_field_display()?
>
> Hard to tell what would be more consistent.
Hm, I cannot answer that top of my head. I'll take a look into the code and try to come up with a sensible answer.
|
Mon 27 Feb 2006 09:28:51 AM UTC, comment #7:
"<p>first line<br />
</p>
<p>second line<br />
</p>"
If you do that, as <p> starts a new line (doesn't it?), you'll end up with an extra line break too.
>I guess we need to remove the call to nl2br() in that function. >However, there are some more calls to trackers_field_display(). >We need to investigate whether those would be affected.
We can even wonder where the markup function should be called: inside or outside trackers_field_display()?
Hard to tell what would be more consistent.
|
Sun 26 Feb 2006 07:04:58 PM UTC, comment #6:
> Weird, now lines break in original submission are doubled :(
I've discovered that bug. It's simply that the function trackers_field_display calls nl2br() before writing the field contents to its return value.
I guess we need to remove the call to nl2br() in that function. However, there are some more calls to trackers_field_display(). We need to investigate whether those would be affected.
|
Sun 26 Feb 2006 05:37:59 PM UTC, comment #5:
Hm, your example looks indeed faulty, but not because of the newlines and <br /> tags, those look good to me. However, I would expect it to contain paragraphs. Example:
"first line
second line"
This should be rendered as:
"<p>first line<br />
</p>
<p>second line<br />
</p>"
> How can that be? The whole issues seems simple to me: nl2br
> unless we are in the basic case.
|
Sun 26 Feb 2006 03:47:42 PM UTC, comment #4:
I really don't get it. Now
"newline
newline"
returns
"newline
<br />
<br />
newline<br />"
How can that be? The whole issues seems simple to me: nl2br unless we are in the basic case.
There should not be any missing <br> and neither should appear extra <br>. What the cause of the trouble here? We just have to put <br> each time we reach a \n, nothing else.
I guess
"newline
= adad ="
could be a problem if it means having
"newline<br>
<br>
<h3>adad</h3>"
because it will had lot of space while a <br> is not necessary in front of a heading.
Is that the issue that makes the overall buggy? If we cannot easily avoid the <br> in front of <h3>, we'll live with it. It is not so much a tragedy.
|
Sun 26 Feb 2006 03:41:16 PM UTC, comment #3:
Weird, now lines break in original submission are doubled :(
|
Sat 25 Feb 2006 11:31:13 PM UTC, comment #2:
This bug should be fixed in the latest SVN revision.
|
Fri 24 Feb 2006 06:59:47 PM UTC, comment #1:
Looking at it, I find no place where the line break are in effect. I'm not sure to understand why, I'll wait until you get back from holidays.
|
Sun 19 Feb 2006 03:50:15 PM UTC, original submission:
dimanche 19.02.2006 à 12:27, commentaire #51 :
> > It is maybe due to the fact that you called
> > utils_basic_markup() (basic), but now all the line breaks are
> > gone.
>
> Well, the basic markup doesn't care about paragraph formatting, so it doesn't
> add any line breaks or paragraph breaks.
>
> Where did you discover this problem? I thought that most uses of
> utils_make_links() should not add line breaks.
samedi 18.02.2006 à 17:11, commentaire #50 :
> It is maybe due to the fact that you called utils_basic_markup()
> (basic), but now all the line breaks are gone.
Sorry I was not clear: in comments, there are no longer any line breaks.
|
Related Recipes:
Savane - Bugs: bug #5348, formatting: line breaks in...