I've been following the discussion and as I can see it's already become
rather unproductive*. So I hope my cutting in will not be very much out
of place (even if I don't really know what I'm talking about).
Many people here has stated the main reason why a WYSIWYG editor is not
feasible is the current wikitext syntax.
What's actually wrong with it?
The main thing I can thing of is the fact one template may include an
opening of a table etc. and another one a closing (e.g. {{col-begin}},
{{col-end}}). It makes it impossible to isolate the template from the
rest of the article - draw a frame around it, say "this box here is a
template".
It could be fixed by forbidding leaving unclosed tags in templates. As a
replacement, a kind of foreach loop could be introduced to iterate
through an unspecified number of arguments.
Lack of standardisation has also been mentioned. Something else?
I've tried to think how a perfect parser should work. Most of this has
been already mentioned. I think it should work in two steps: first
tokenise the code and transform it into an intermediate tree structure like
*paragraph
title:
* plain text: "Section 1"
content:
* plain text: "foo"
* bold text:
* plain text: "bar"
* template
name: "Infobox"
* argument
name: "last name":
value:
* plain text: "Shakespear"
and so on. Then this structure could be transformed into a) HTML for
display, b) JSON for the WYSIWYG editor. Thanks for this you wouldn't
need to write a whole new JS parser. The editor would get a half-ready
product. The JS code would need to be able to: a) transform this
structure into HTML, b) modify the structure, c) transform this
structure back into wikitext.
But I guess it's more realistic to write a new JS parser than to write a
new PHP parser. The former can start as a stub, the latter would need to
be fully operational from the beginning.
Stephanie's suggestions are also interesting.
lampak
* (except the WYSIWTF, of course)