This is from my bug page http://www.wikipedia.org/wiki/User%3AKeichwa:
Testing links ============= Input ----- Let's learn [[Italian language|Italian]].
Output ------ Let's learn [[Italian language|Italian]].
Expected Output --------------- Let's learn Italian.
-=-=-=-=-=-=-=-=-=-=-=-=-=- cut here -=-=-=-=-=-=-=-=-=-=-=-=-=-
Any Emacs user out there? How to prevent Emacs from breaking lines in "[[some words|"?
On Mon, 10 Mar 2003, Karl Eichwalder wrote:
This is from my bug page http://www.wikipedia.org/wiki/User%3AKeichwa: Let's learn [[Italian language|Italian]].
The bug's in your editor, I'm afraid. Wiki syntax doesn't cross linebreaks. For one thing, this helps contain damage from Markup Gone Mad; a lone opening tag that isn't closed turning an entire page into gibberish.
-- brion vibber (brion @ pobox.com)
Brion Vibber vibber@aludra.usc.edu writes:
On Mon, 10 Mar 2003, Karl Eichwalder wrote:
This is from my bug page http://www.wikipedia.org/wiki/User%3AKeichwa: Let's learn [[Italian language|Italian]].
The bug's in your editor, I'm afraid. Wiki syntax doesn't cross linebreaks. For one thing, this helps contain damage from Markup Gone Mad; a lone opening tag that isn't closed turning an entire page into gibberish.
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>
Karl Eichwalder ke@gnu.franken.de 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.
And now th bug that annoys me most (http://www.wikipedia.org/wiki/User%3AKeichwa):
2.1 Testing lists
2.1.1 Input
Let's look at these items:
* item 1 * item 2 is a little bit longish: it takes more than one line. * item 3
2.1.2 Output
Let's look at these items:
* item 1 * item 2 is a little bit longish: it
takes more than one line.
* item 3
2.1.3 Expected Output
Let's look at these items:
* item 1 * item 2 is a little bit longish: it takes more than one line. * item 3
-=-=-=-=-=-=-=-=-=-=-=-=-=- cut here -=-=-=-=-=-=-=-=-=-=-=-=-=-
I hope you will be able to fix this one -- it's rather important to me.
Karl Eichwalder wrote in part:
- item 1
- item 2 is a little bit longish: it
takes more than one line.
- item 3
I hope you will be able to fix this one -- it's rather important to me.
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
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.
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>
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 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.
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.
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.
Vicki Rosenzweig vr@redbird.org writes:
<h2>title</h2> <p> line </p>
Why must they?
Because leaving out the initial <p> is a hack and HTML coders are pretty aware of it :)
Is that an offer to work on the code?
Sorry, I'm not a coder/hacker. I'm just a user and bug reporter and I hope my reports are useful. I can offer to work on the technical documentation -- maybe I should start there.
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.
Maybe, I can work around these problems by my side.
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.
The bug is that some things are ambiguous; that bad because this makes people change texts back and forth for layout purposes only.
Karl Eichwalder wrote:
Toby Bartels wrote:
I certainly hope that this one does not get "fixed".
If the error will continue to stay for too long, it will be me who will have to go.
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.
-=-=-=-=-=-=-=-=-=-=-=-=-=- == title == line -=-=-=-=-=-=-=-=-=-=-=-=-=- and -=-=-=-=-=-=-=-=-=-=-=-=-=- == title ==
line
must come out the same:
<h2>title</h2> <p> line </p> -=-=-=-=-=-=-=-=-=-=-=-=-=-
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.)
Just make it a habit to produce XHTML and problems will vanish with a sudden.
*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.
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.
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".
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.
Then that's a documentation problem. Where does it say that? and I'll fix it.
-- Toby
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.
Actually, I wrote that code, and I think it would be better to do it his way. The only reason I didn't is that Usemod didn't, and there's a lot of existing text that depends on the old behavior. But I agree that the old behavior is bad: line ends should not be significant in wiki text, ever. As it is, they are not significant in ordinary paragraphs, but they are significant within lists. That's inconsistent and confusing.
Lee Daniel Crocker lee@piclab.com writes:
First: thanks for your work!
As it is, they are not significant in ordinary paragraphs, but they are significant within lists. That's inconsistent and confusing.
Thanks for confirmation. Hopefully in the long and not so long run we can do something to improve the situation!
Best, Karl
Lee Daniel Crocker wrote:
Toby Bartels wrote:
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.
Actually, I wrote that code, and I think it would be better to do it his way.
I was actually referring to the behaviour near headers.
The only reason I didn't is that Usemod didn't, and there's a lot of existing text that depends on the old behavior. But I agree that the old behavior is bad: line ends should not be significant in wiki text, ever. As it is, they are not significant in ordinary paragraphs, but they are significant within lists. That's inconsistent and confusing.
I've already described how *I* would like them to be significant.
-- Toby
Toby Bartels toby+wikipedia@math.ucr.edu writes:
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.
Okay, it's not a programming bug.
Of course, the <p> is irrelevant in HTML 4 -- by HTML specs, they *must* be rendered the same by the browser --
As we know they do not. Thus let's less ambiguous HTML code as possible.
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.)
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 :)
Karl Eichwalder wrote in part:
Toby Bartels wrote:
(When we go to XHTML, where the initial <p> will be required, then presumably we'll have to rely on the CSS for everything.)
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 :)
I think that every developer agrees that XHTML would be best. But none of them (I'm not one) has started to do the work. It's a matter of budgeting time and priorities; even the fact that I'm not one of the developers is such a matter (since I do have some interest in how the code works).
-- Toby
On Sun, 2003-03-16 at 11:49, Karl Eichwalder 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.
You are welcome to come and go as you please.
(re: headers with vs without following blank lines)
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).
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.
Just make it a habit to produce XHTML and problems will vanish with a sudden.
Thank you for volunteering to rewrite the parser to consistently produce correct XHTML. Right?
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.
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.
In any case, these aren't bugs, but feature requests.
I'd rather rate these things as bugs.
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)
----- Original Message ----- From: "Brion Vibber" brion@pobox.com To: "wikipedia-l" wikipedia-l@wikipedia.org Sent: Sunday, March 16, 2003 2:09 PM Subject: Re: [Wikipedia-l] Re: New bug concerning lists
Toby: 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. Brion: You are welcome to come and go as you please.
What is this? Sharp words of wit on the En:wiki mailing list?! The future is bright. :) -SV
Stevertigo wrote:
Toby: 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. Brion: You are welcome to come and go as you please.
What is this? Sharp words of wit on the En:wiki mailing list?! The future is bright. :) -SV
If you say so. But I didn't say the "If the error [...]" part. ^_^
-- Toby
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.
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.
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
Brion Vibber brion@pobox.com writes:
Thank you for volunteering to rewrite the parser to consistently produce correct XHTML. Right?
No, I'm not a hacker :) Feeding stuff thru tidy/untidy can do wonders...
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.
There is some truth in your statement. But: for editing purposes jumping line length don't hurt that much (Emacs hat M-q to work around those problems...) and more important I simply depend on broken lines -- grep, sed and awk work best on those line.
And don't tell me a webbrowser's built-in editor is a proper tool to write articles ;)
There is some truth in your statement. But: for editing purposes jumping line length don't hurt that much
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.
(Emacs hat M-q to work around those problems...)
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.
and more important I simply depend on broken lines -- grep, sed and awk work best on those line.
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
erik_moeller@gmx.de (Erik Moeller) writes:
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.
I just pasted http://de.wikipedia.org/w/wiki.phtml?title=Ludwig_Tieck&action=edit from Emacs (4066 chars) and adding 1000 chars were not a problem.
BTW, if you used vim, you could just do ":set lbr" to turn on soft wrapping...
When time permits I'll check out longlines.el; for the moment I'll stay away from web editing as much as possible ;)
erik_moeller@gmx.de (Erik Moeller) writes:
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.
I just pasted http://de.wikipedia.org/w/wiki.phtml?title=Ludwig_Tieck&action=edit from Emacs (4066 chars) and adding 1000 chars were not a problem.
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
Erik Moeller wrote in part:
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!"
And I would write:
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!"
because I encourage semantic interpretations of the breaks.
^_^
-- Toby
Toby Bartels toby+wikipedia@math.ucr.edu writes:
because I encourage semantic interpretations of the breaks.
^_^
And some editor even add <br> elements at the end of semantical entities ;-(
Karl Eichwalder wrote:
Toby Bartels toby+wikipedia@math.ucr.edu writes:
because I encourage semantic interpretations of the breaks.
And some editor even add <br> elements at the end of semantical entities ;-(
The world is a bad place, lets get back to LaTeX, it's usually doing what I want and it can handle even Karl's and Toby's wishes. You can even use emacs to edit it's files ;)
Smurf
Karl Eichwalder wrote:
And some editor even add <br> elements at the end of semantical entities ;-(
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
This doesn't look like a bug to me. You've added a newline character in the middle of the link. Why would you expect it to create a link to an article which doesn't have a newline character in its name? Zoe Karl Eichwalder ke@gnu.franken.de wrote:This is from my bug page http://www.wikipedia.org/wiki/User%3AKeichwa:
Testing links ============= Input ----- Let's learn [[Italian language|Italian]].
Output ------ Let's learn [[Italian language|Italian]].
Expected Output --------------- Let's learn Italian.
-=-=-=-=-=-=-=-=-=-=-=-=-=- cut here -=-=-=-=-=-=-=-=-=-=-=-=-=-
Any Emacs user out there? How to prevent Emacs from breaking lines in "[[some words|"?
Any Emacs user out there? How to prevent Emacs from breaking lines in "[[some words|"?
Emacs is not a good text editor, it is a good code editor. It doesn't even have built-in support for soft line wrapping, i.e. word wrapping at the window edge. You can wrap *characters* at the window edge using AutoFillMode, but to wrap words properly you need an ugly hack such as longlines.el (check CategoryFilling on emacswiki.org). Even the built in editor of my mail client is better than that.
Or you could use a decent *text* editor like nedit, scite or gvim.
I long for the day when Unix fetishists will realize that much of their software is broken for real world tasks.
Regards,
Erik
erik_moeller@gmx.de (Erik Moeller) writes:
It doesn't even have built-in support for soft line wrapping, i.e. word wrapping at the window edge.
Unix tools work best on hard "wrapped" lines (grep, awk, wc) and proper file formats can cope perfectly with long lines and "wrapped" lines (TeX, SGML, etc.). The wikipedia file format is, errm, the wikipedia file format--it's not that bad, but it surely has issues; esp. when it comes to lists
Or you could use a decent *text* editor like nedit, scite or gvim.
Was there done that--but now I'm using Emacs since 10 years or so and I still don't regret this decision. More likely I'll stay away from wikipedia than dropping Emacs ;)
Karl Eichwalder wrote in part:
The wikipedia file format is, errm, the wikipedia file format
When I'm working on Wikipedia articles offline, I save them as extension ".wml", for "wiki markup language". ^_^
-- Toby
WML is used for http://www.wikipedia.org/wiki/WML
I suggest use WPL WikiPedia Language ;)
Regards.
----- Original Message ----- From: "Toby Bartels" toby+wikipedia@math.ucr.edu To: wikipedia-l@wikipedia.org Sent: Wednesday, March 12, 2003 6:46 AM Subject: [Wikipedia-l] The Wikipedia file format (Was: New Bug: Newline within a Link)
Karl Eichwalder wrote in part:
The wikipedia file format is, errm, the wikipedia file format
When I'm working on Wikipedia articles offline, I save them as extension ".wml", for "wiki markup language". ^_^
-- Toby _______________________________________________ Wikipedia-l mailing list Wikipedia-l@wikipedia.org http://www.wikipedia.org/mailman/listinfo/wikipedia-l
Pedro M.V. wrote:
WML is used for http://www.wikipedia.org/wiki/WML
I suggest use WPL WikiPedia Language ;)
Why not "*.wiki"?
Magnus
Magnus Manske magnus.manske@web.de writes:
I suggest use WPL WikiPedia Language ;)
Why not "*.wiki"?
There is more than one wiki and no file format matches the other. Thus: "*.wikipedia".
OTOH, using Emacs a file suffix isn't necessarily needed; I can setup Emacs to recognize all files in a special directory as wikipedia files.
Karl Eichwalder wrote:
Magnus Manske writes:
Why not "*.wiki"?
Simplicity!
There is more than one wiki and no file format matches the other. Thus: "*.wikipedia".
I originally used "wiki markup language" (WML) on the grounds that I wasn't going to distinguish between the different wiki markup languages.
OTOH, using Emacs a file suffix isn't necessarily needed; I can setup Emacs to recognize all files in a special directory as wikipedia files.
I don't need a suffix either -- I just do it to be cute. I'm sorry that I brought it up.
-- Toby
On Wed, 12 Mar 2003 22:54:55 -0800, Toby Bartels toby+wikipedia@math.ucr.edu wrote:
Karl Eichwalder wrote:
Magnus Manske writes:
Why not "*.wiki"?
Simplicity!
There is more than one wiki and no file format matches the other. Thus: "*.wikipedia".
I originally used "wiki markup language" (WML) on the grounds that I wasn't going to distinguish between the different wiki markup languages.
But wouldn't most systems try and parse that as Wireless Markup Language? Are there actually any three-letter combinations left unused by Mime types and software data formats?
Richard Grevers wrote:
Toby Bartels wrote:
Magnus Manske writes:
Why not "*.wiki"?
Simplicity!
I originally used "wiki markup language" (WML) on the grounds that I wasn't going to distinguish between the different wiki markup languages.
But wouldn't most systems try and parse that as Wireless Markup Language? Are there actually any three-letter combinations left unused by Mime types and software data formats?
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
(Toby Bartels toby+wikipedia@math.ucr.edu): Richard Grevers wrote:
Toby Bartels wrote:
Magnus Manske writes:
Why not "*.wiki"?
Simplicity!
I originally used "wiki markup language" (WML) on the grounds that I wasn't going to distinguish between the different wiki markup languages.
But wouldn't most systems try and parse that as Wireless Markup Language? Are there actually any three-letter combinations left unused by Mime types and software data formats?
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.
Umm, what's wrong with ".txt"? Since there isn't really a formalized markup language yet, I think it would be confusing and likely cause problems to use a file extension to imply that there is. At some point in the future, I certainly do plan to formalize and complete a wikipedia markup language, and it will likely resemble the current one closely-- but it won't be identical.
LDC wrote:
Toby Bartels wrote:
Since *.wml is no good for the reasons given, I support *.wiki.
Umm, what's wrong with ".txt"?
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
Richard Grevers wrote:
On Wed, 12 Mar 2003 22:54:55 -0800, Toby Bartels toby+wikipedia@math.ucr.edu wrote:
Karl Eichwalder wrote:
Magnus Manske writes:
Why not "*.wiki"?
Simplicity!
There is more than one wiki and no file format matches the other. Thus: "*.wikipedia".
I originally used "wiki markup language" (WML) on the grounds that I wasn't going to distinguish between the different wiki markup languages.
But wouldn't most systems try and parse that as Wireless Markup Language? Are there actually any three-letter combinations left unused by Mime types and software data formats?
Yes: .wff for "wikipedia file format" seems not to be used by anyone else. (And then there's the other meaning of wff for amusement's sake).
-- Neil
I love it !!!. I like WFF. Use it, please. ;)
Regards.
----- Original Message ----- From: "Neil Harris" usenet@tonal.clara.co.uk To: wikipedia-l@wikipedia.org Sent: Friday, March 14, 2003 12:11 AM Subject: Re: [Wikipedia-l] Re: Re: The Wikipedia file format
Richard Grevers wrote:
But wouldn't most systems try and parse that as Wireless Markup Language? Are there actually any three-letter combinations left unused by Mime types and software data formats?
Yes: .wff for "wikipedia file format" seems not to be used by anyone else. (And then there's the other meaning of wff for amusement's sake).
-- Neil
Wikipedia-l mailing list Wikipedia-l@wikipedia.org http://www.wikipedia.org/mailman/listinfo/wikipedia-l
wikipedia-l@lists.wikimedia.org