At 08:49 PM 3/16/03 +0100, Karl wrote:
Toby Bartels toby+wikipedia@math.ucr.edu writes:
I certainly hope that this one does not get "fixed".
If the error will continue to stay for too long, it will be me how will have to go.
This seems to be a matter of incompatibility between your preferred editing software and the Wikipedia software. I wouldn't call that a bug--neither was written specifically to work with the other--and it shouldn't be an insurmountable obstacle.
I hope that someday PediaWiki will recognise a lack of blank line, not only next to headers but also next to lists, rules, etc, as indicating that a feature is next to (or within) the paragraph.
I guess you are talking about the next bug I want to go reporting :)
-=-=-=-=-=-=-=-=-=-=-=-=-=- == title == line -=-=-=-=-=-=-=-=-=-=-=-=-=-
and
-=-=-=-=-=-=-=-=-=-=-=-=-=- == title ==
line
must come out the same:
<h2>title</h2> <p> line </p>
Why must they? Do we have a spec that says linebreaks should be ignored in input but produced in output?
But the parser forget to eat spaces at the start and at the end of the title line ("== title ==" -> "<h2> title </h2>") and is does bad things to the paragraph (the <p> element).
Just make it a habit to produce XHTML and problems will vanish with a sudden.
Is that an offer to work on the code?
Is your offline editor really unable to handle long lines? (I only remember emacs' being brought up, but I edit wiki files with emacs all the time.)
I'm using 'turn-on-auto-fill' and 'fill-column' (72 resp. 79) for text mode and related modes. And I use fill commands to make the text look nice.
That makes sense when your editor is producing final text. It's not useful when you're producing input for a formatter--whether that formatter is PediaWiki, Quark, or a browser that's expecting HTML and CSS.
In any case, these aren't bugs, but feature requests.
I'd rather rate these things as bugs. Somewhere is the claim that empty lines are paragraph separators. The wiki-to-html converter does not obey this rule.
Where is the claim? Unless that's in our spec, it's not a bug. Certainly, you can't get your preferences installed and made high priority by asserting that it's a bug that the software isn't doing things that aren't in its design or specifications.