Brion Vibber &lt;vibber(a)aludra.usc.edu&gt; writes: It's easy to detect those Markup Gone Mad occurrences; thus I'd like to ask to be friendly to Unix editing conventions, too. The bug listed above on http://www.wikipedia.org/wiki/User%3AKeichwa is more serious, BTW. Wikipedia's to-HTML converter happily add many a lot <p> elements when you comment out some lines; cf. http://de.wikipedia.org/wiki/Arabische_Sprache where this happens: Input: ====== [...] Verdopplung des mittleren Radikals. <!-- == Textsammlungen == --> <!-- Beim [[Free Translation Project]] liegen noch keine Übersetzungen (Englisch-Arabisch) aus dem Bereich freier Software vor: http://www.iro.umontreal.ca/contrib/po/HTML/team-ar.html --> ''Siehe auch:'' [[Sprache]] HTML output: ============ [...] Verdopplung des mittleren Radikals. <p> <p> <p> <p> <p> <em>Siehe auch:</em> <a href="http://de.wikipedia.org/wiki/Sprache" class='internal' title="Sprache">Sprache</a> <p> -- ke(a)suse.de (work) / keichwa(a)gmx.net (home): | http://www.gnu.franken.de/ke/ | ,__o Free Translation Project: | _-\_<, http://www.iro.umontreal.ca/contrib/po/HTML/ | (*)/'(*)

Karl Eichwalder wrote in part: I certainly hope that this one does not get "fixed". 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. This makes the output for natural to the editor, as well as allowing for more nuanced effects. (You can't do it with HTML, you need CSS, as with the headers.) 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.) In any case, these aren't bugs, but feature requests. -- Toby

At 08:49 PM 3/16/03 +0100, Karl wrote: 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. Why must they? Do we have a spec that says linebreaks should be ignored in input but produced in output? Is that an offer to work on the code? 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. 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. -- Vicki Rosenzweig vr(a)redbird.org http://www.redbird.org

Karl Eichwalder wrote: That would be too bad. But you're probably not going to get far calling it an "error", when people worked hard on the programming to get it to specifically do just what it does. They don't *must* come out the same; that's up to us all to decide. And the wiki parser was specifically designed so that they don't. (This particular effect was the result of a big compromise, as it happens.) Of course, the <p> is irrelevant in HTML 4 -- by HTML specs, they *must* be rendered the same by the browser -- which is why people worked on getting different CSS as well. (When we go to XHTML, where the initial <p> will be required, then presumably we'll have to rely on the CSS for everything.) *These* "problems" won't vanish -- the differences will still be there. In the case of the line break, nothing would change. In the case of the header, the CSS would still produce the effect. Ah, there's your problem. Turn these off when editing wiki files, and all will be well. You can even set up emacs to do this automatically when you edit a file whose name ends in (say) ".wiki". Then that's a documentation problem. Where does it say that? and I'll fix it. -- Toby

Lee Daniel Crocker &lt;lee(a)piclab.com&gt; writes: First: thanks for your work! Thanks for confirmation. Hopefully in the long and not so long run we can do something to improve the situation! Best, Karl -- ke(a)suse.de (work) / keichwa(a)gmx.net (home): | http://www.gnu.franken.de/ke/ | ,__o Free Translation Project: | _-\_<, http://www.iro.umontreal.ca/contrib/po/HTML/ | (*)/'(*)

Toby Bartels &lt;toby+wikipedia(a)math.ucr.edu&gt; writes: Okay, it's not a programming bug. As we know they do not. Thus let's less ambiguous HTML code as possible. This would be a good thing -- without CSS all things are non-fancy and thus usable ofr simple browsers and audio devices and for fancy things the reader can choose from some CSS stylesheets. If you don't agree with me, that's also okay :) -- ke(a)suse.de (work) / keichwa(a)gmx.net (home): | http://www.gnu.franken.de/ke/ | ,__o Free Translation Project: | _-\_<, http://www.iro.umontreal.ca/contrib/po/HTML/ | (*)/'(*)

On Sun, 2003-03-16 at 11:49, Karl Eichwalder wrote: You are welcome to come and go as you please. (re: headers with vs without following blank lines) This feature was added by popular request. It would probably be better produced with a separate style class on the header elements to munge the margins rather than relying on tricky behavior with missing <p>s. You're welcome to improve the code to produce technically correct output. Thank you for volunteering to rewrite the parser to consistently produce correct XHTML. Right? Ah, you're an idiocyncratic line-breaker. You should know that if I had my way you'd be locked up. ;) Seriously, *your* ideal column width and *my* ideal column width are not always going to be the same. If your lines are longer than my edit box, I see ragged broken lines and text does *not* look nice. If your lines are shorter than my edit box, I see a lot of annoyingly short lines and text does *not* look nice. This has been an endemic problem for years in email and usenet, and I've no desire to see it in wiki. Let the editors wrap lines as appropriate for display, please, and don't make them ragged with forced line breaks. I'd rather see some code from you if you're so darn sure you know how to do it right. -- brion vibber (brion @ pobox.com)

What is this? Sharp words of wit on the En:wiki mailing list?! The future is bright. :) -SV

Another disadvantage of line-wrapping is that in the search function, the 'context' information contains less information. Also, if an article gets edited, the line length will be broken, unless the person doing the editing is willing to spend quite a bit of time making things 'look nice' again which isn't visible on the page at all - in which case the 'changes' page is not going to do its function well. Not to mention that the 'changes' page is already unusable when linebreaking is added or removed. Andre Engels

Switching line lengths require more effort on the part of the human brain and lead to semantic interpretations of the breaks (as emphasis, pause etc.). Compare: Messages from Communities Around the Globe Palestinians and international friends from the United States, the UK, and the Netherlands marched along Sea Street, Sharia al Baha, one of the central streets in Rafah Camp. As they approached the center of town they began to shout through bullhorns in Arabic "Hurriyah la Falesteen! Hurriyah la al Iraq! Hurriyah la Rafah! Hurriyah la Baghdad!" and in English "Freedom for Palestine! Freedom for Iraq! Freedom for Rafah! Freedom for Baghdad!" vs. Messages from Communities Around the Globe Palestinians and international friends from the United States, the UK, and the Netherlands marched along Sea Street, Sharia al Baha, one of the central streets in Rafah Camp. As they approached the center of town they began to shout through bullhorns in Arabic "Hurriyah la Falesteen! Hurriyah la al Iraq! Hurriyah la Rafah! Hurriyah la Baghdad!" and in English "Freedom for Palestine! Freedom for Iraq! Freedom for Rafah! Freedom for Baghdad!" Since you have to read to edit, this is a very serious problem. Yes, but people with different line lengths have to keep doing this to fix each other's annoying breaks. Furthermore, most people do use the browser- internal editor, like it or not, for convenience reasons alone. I do so myself a lot because Mozilla has no external editor support and cannot paste more than 4000 bytes from most other applications on Linux. For these reasons, I will probably revert any edits I see which needlessly insert linebreaks into text. I do not see the advantage here -- in fact, you will have to go to extra trouble when doing a regex on a paragraph with linebreaks in it, since you usually care about the paragraph, not about the line. Semantically, however, the linebreaks are a bug that has a long history in the Unix world. BTW, if you used vim, you could just do ":set lbr" to turn on soft wrapping... Regards, Erik

Yes, it works with emacs and a few other apps which use different clipboard handling code. However, even then there are problems with some special chars. See http://bugzilla.mozilla.org/show_bug.cgi?id=56219 for the sordid details. Regards, Erik

Toby Bartels &lt;toby+wikipedia(a)math.ucr.edu&gt; writes: And some editor even add <br> elements at the end of semantical entities ;-( -- ke(a)suse.de (work) / keichwa(a)gmx.net (home): | http://www.gnu.franken.de/ke/ | ,__o Free Translation Project: | _-\_<, http://www.iro.umontreal.ca/contrib/po/HTML/ | (*)/'(*)

Karl Eichwalder wrote: Valid on a web page for, say, poetry. Of course, Wikipedia doesn't include poetry, except in quotations, where we use : at the beginning of the line instead: ==== : Roses are red; : Violets are blue; : An I for an I, : and a II for a II. ==== Of course, this doesn't work if the line breaks don't tell you that the : line has ended. And Project Sourceberg *does* include unquoted poetry: ==== Roses are red;<br> Violets are blue;<br> An I for an I,<br> and a II for a II. ==== (The semantic line breaks that I use in my emails are of course inappropriate when the line length may be nothing like the 80 column email standard that my emails are written to reflect.) -- Toby

Karl Eichwalder wrote in part: When I'm working on Wikipedia articles offline, I save them as extension ".wml", for "wiki markup language". ^_^ -- Toby

Pedro M.V. wrote: Why not "*.wiki"? Magnus

Karl Eichwalder wrote: Simplicity! I originally used "wiki markup language" (WML) on the grounds that I wasn't going to distinguish between the different wiki markup languages. I don't need a suffix either -- I just do it to be cute. I'm sorry that I brought it up. -- Toby

Richard Grevers wrote: That's already been mentioned. I wasn't clear, but my comment after Magnus' proposal was one of approbation. Since *.wml is no good for the reasons given, I support *.wiki. -- Toby

LDC wrote: I want to be able to see at a glance when a file is a wiki file. Don't forget, I used .wml just to be cute -- don't establish .wiki formally for real! -- Toby

I love it !!!. I like WFF. Use it, please. ;) Regards. ----- Original Message ----- From: "Neil Harris" &lt;usenet(a)tonal.clara.co.uk&gt; To: &lt;wikipedia-l(a)wikipedia.org&gt; Sent: Friday, March 14, 2003 12:11 AM Subject: Re: [Wikipedia-l] Re: Re: The Wikipedia file format