Hi all,
I'm still on vacation, but I saw "the WYSIWYG discussion, reloaded", and was bored, so...
As far as I could deduce, the goal is to use a run-of-the-mill HTML WYSIWYG editor, with minimal modifications, to edit MediaWiki text. Since rebuilding the perfect parser has Failed Repeatedly (TM), any parsed substitute should fall back gracefully, that is, only parse wikitext into some HTML structure when it is very sure it is doing it right, and otherwise leave it alone and just show it as old, ugly wikitext.
I took two hours to write a pure JavaScript demo that can render (note, not parse!) wikitext as HTML, so that a WYSIWYG HTML editor could use it. Some elements, like headings, blank lines, and templates, it converts into a pseudo-parsed structure, using classes to indicate where the element(s) came from. I believe that, basically, the original wikitext could be reconstructed from the rendered HTML (not checked, though), and that changes in plain ol' HTML (read: WYSIWYG edits) could be integrated likewise.
My demo is rudimentary: no checking for HTML comments or <nowiki>, no bold or italics, no <ref> or [[link]] handling, and tables and lists are ignored as well. But even so, the output remains readable and recognisable as wikitext, and it should be quite clear how the original wikitext could be regenerated from it.
The main function right now is the template collapse. Template code is surrounded by a green border, and the template name is green. Long templates hide their parameters, which can be shown by double-clicking the template name. Depending on context, it is decided to use <div> or <span>, so short inline templates stay inline. It is not always pretty, but IMHO demonstrates the concept.
The JavaScript seems reasonably quick. Yes, some wikitext will be hard to render; but frankly, we can just ignore it for the time being. Better something that works quickly and reliably in most cases and fails gracefully than something that would be perfect but never gets done, I say!
Again, quick hack demo warning. If you're brave enough to try it, my test article (only runs in article namespace ATM) is the article of the day, [[Lince (tank)]].
JavaScript at http://toolserver.org/~magnus/wysiwtf/wysiwtf.js CSS at http://toolserver.org/~magnus/wysiwtf/wysiwtf.css
To test, edit your vector.js, and copy this: document.write('<script type="text/javascript" src="http://toolserver.org/~magnus/wysiwtf/wysiwtf.js"></script>'); document.write('<link rel="stylesheet" type="text/css" href="http://toolserver.org/~magnus/wysiwtf/wysiwtf.css"></link>');
Force-reload, go to an article, and you'll see a new "WYSIWTF" tab (I trust you can decipher the acronym ;-)
Enjoy! ;-)
Magnus
On Wed, Dec 29, 2010 at 9:39 AM, Magnus Manske magnusmanske@googlemail.com wrote:
Force-reload, go to an article, and you'll see a new "WYSIWTF" tab (I trust you can decipher the acronym ;-)
Hi Magnus, I'm not getting an extra tab. Perhaps I've done something stupid, but I stuck the above code in vector.js, reloaded, nothing. Same in Chrome, FF, Opera. What simple thing am I missing?
Steve
On Wed, Dec 29, 2010 at 12:30 AM, Steve Bennett stevagewp@gmail.com wrote:
On Wed, Dec 29, 2010 at 9:39 AM, Magnus Manske magnusmanske@googlemail.com wrote:
Force-reload, go to an article, and you'll see a new "WYSIWTF" tab (I trust you can decipher the acronym ;-)
Hi Magnus, I'm not getting an extra tab. Perhaps I've done something stupid, but I stuck the above code in vector.js, reloaded, nothing. Same in Chrome, FF, Opera. What simple thing am I missing?
Not sure - works for me. Have a look : http://en.wikipedia.org/wiki/User:Magnus_Manske/vector.js
Maybe some other script in your vector.js dies before it gets to the include point? If so, try moving the lines to the top of vector.js.
Cheers, Magnus
On Wed, Dec 29, 2010 at 9:01 AM, Magnus Manske magnusmanske@googlemail.com wrote:
On Wed, Dec 29, 2010 at 12:30 AM, Steve Bennett stevagewp@gmail.com wrote:
On Wed, Dec 29, 2010 at 9:39 AM, Magnus Manske magnusmanske@googlemail.com wrote:
Force-reload, go to an article, and you'll see a new "WYSIWTF" tab (I trust you can decipher the acronym ;-)
Hi Magnus, I'm not getting an extra tab. Perhaps I've done something stupid, but I stuck the above code in vector.js, reloaded, nothing. Same in Chrome, FF, Opera. What simple thing am I missing?
Not sure - works for me. Have a look : http://en.wikipedia.org/wiki/User:Magnus_Manske/vector.js
Maybe some other script in your vector.js dies before it gets to the include point? If so, try moving the lines to the top of vector.js.
Also, it does only work in actual articles :-)
Update : Wikilinks are now converted to <a> links, images are ignored for now.
Magnus
Ok, I got it - there were some spurious blank lines. Ok, um, it does what you said it does :) Now, how to make this a compelling demonstration that this is _the way foward_?
Steve
On Wed, Dec 29, 2010 at 7:01 PM, Magnus Manske magnusmanske@googlemail.com wrote:
On Wed, Dec 29, 2010 at 12:30 AM, Steve Bennett stevagewp@gmail.com wrote:
On Wed, Dec 29, 2010 at 9:39 AM, Magnus Manske magnusmanske@googlemail.com wrote:
Force-reload, go to an article, and you'll see a new "WYSIWTF" tab (I trust you can decipher the acronym ;-)
Hi Magnus, I'm not getting an extra tab. Perhaps I've done something stupid, but I stuck the above code in vector.js, reloaded, nothing. Same in Chrome, FF, Opera. What simple thing am I missing?
Not sure - works for me. Have a look : http://en.wikipedia.org/wiki/User:Magnus_Manske/vector.js
Maybe some other script in your vector.js dies before it gets to the include point? If so, try moving the lines to the top of vector.js.
Cheers, Magnus
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
I see three parts that will be required for a fully functional demo:
1. Conversion of wikitext into "HTMLized" code as input for a HTML editor 2. A (patched) HTML WYSIWYG editor that takes the code from #1 as input 3. A wikitext generator, running on the saved HTML from #2
I have made a proof-of-principle implementation of #1, and I'll continue expanding it. I could also do an implementation of #3 later.
But, since I have little experience with HTML WYSIWYG editors, I would prefer someone else to do that part. But since there is mostly talk on this and the other list, I'll probably end up doing that myself as well... :-(
Cheers, Magnus
On Wed, Dec 29, 2010 at 1:45 PM, Steve Bennett stevagewp@gmail.com wrote:
Ok, I got it - there were some spurious blank lines. Ok, um, it does what you said it does :) Now, how to make this a compelling demonstration that this is _the way foward_?
Steve
On Wed, Dec 29, 2010 at 7:01 PM, Magnus Manske magnusmanske@googlemail.com wrote:
On Wed, Dec 29, 2010 at 12:30 AM, Steve Bennett stevagewp@gmail.com wrote:
On Wed, Dec 29, 2010 at 9:39 AM, Magnus Manske magnusmanske@googlemail.com wrote:
Force-reload, go to an article, and you'll see a new "WYSIWTF" tab (I trust you can decipher the acronym ;-)
Hi Magnus, I'm not getting an extra tab. Perhaps I've done something stupid, but I stuck the above code in vector.js, reloaded, nothing. Same in Chrome, FF, Opera. What simple thing am I missing?
Not sure - works for me. Have a look : http://en.wikipedia.org/wiki/User:Magnus_Manske/vector.js
Maybe some other script in your vector.js dies before it gets to the include point? If so, try moving the lines to the top of vector.js.
Cheers, Magnus
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
OK, so I tried it and made a small copyediting edit on my favorite article "Ninja Gaiden (Nintendo Entertainment System)" http://en.wikipedia.org/w/index.php?title=Ninja_Gaiden_(Nintendo_Entertainme...
It did mess up a couple of things which I did not touch, so consider this an early "bug report" of sorts :)
-MuZemike
On 12/29/2010 7:16 AM, Magnus Manske wrote:
I see three parts that will be required for a fully functional demo:
- Conversion of wikitext into "HTMLized" code as input for a HTML editor
- A (patched) HTML WYSIWYG editor that takes the code from #1 as input
- A wikitext generator, running on the saved HTML from #2
I have made a proof-of-principle implementation of #1, and I'll continue expanding it. I could also do an implementation of #3 later.
But, since I have little experience with HTML WYSIWYG editors, I would prefer someone else to do that part. But since there is mostly talk on this and the other list, I'll probably end up doing that myself as well... :-(
Cheers, Magnus
On Wed, Dec 29, 2010 at 1:45 PM, Steve Bennettstevagewp@gmail.com wrote:
Ok, I got it - there were some spurious blank lines. Ok, um, it does what you said it does :) Now, how to make this a compelling demonstration that this is _the way foward_?
Steve
On Wed, Dec 29, 2010 at 7:01 PM, Magnus Manske magnusmanske@googlemail.com wrote:
On Wed, Dec 29, 2010 at 12:30 AM, Steve Bennettstevagewp@gmail.com wrote:
On Wed, Dec 29, 2010 at 9:39 AM, Magnus Manske magnusmanske@googlemail.com wrote:
Force-reload, go to an article, and you'll see a new "WYSIWTF" tab (I trust you can decipher the acronym ;-)
Hi Magnus, I'm not getting an extra tab. Perhaps I've done something stupid, but I stuck the above code in vector.js, reloaded, nothing. Same in Chrome, FF, Opera. What simple thing am I missing?
Not sure - works for me. Have a look : http://en.wikipedia.org/wiki/User:Magnus_Manske/vector.js
Maybe some other script in your vector.js dies before it gets to the include point? If so, try moving the lines to the top of vector.js.
Cheers, Magnus
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Update : Misc fixes, diff function, preview function.
On Sun, Jan 2, 2011 at 9:04 PM, MuZemike muzemike@gmail.com wrote:
OK, so I tried it and made a small copyediting edit on my favorite article "Ninja Gaiden (Nintendo Entertainment System)" http://en.wikipedia.org/w/index.php?title=Ninja_Gaiden_(Nintendo_Entertainme...
It did mess up a couple of things which I did not touch, so consider this an early "bug report" of sorts :)
-MuZemike
On 12/29/2010 7:16 AM, Magnus Manske wrote:
I see three parts that will be required for a fully functional demo:
- Conversion of wikitext into "HTMLized" code as input for a HTML editor
- A (patched) HTML WYSIWYG editor that takes the code from #1 as input
- A wikitext generator, running on the saved HTML from #2
I have made a proof-of-principle implementation of #1, and I'll continue expanding it. I could also do an implementation of #3 later.
But, since I have little experience with HTML WYSIWYG editors, I would prefer someone else to do that part. But since there is mostly talk on this and the other list, I'll probably end up doing that myself as well... :-(
Cheers, Magnus
On Wed, Dec 29, 2010 at 1:45 PM, Steve Bennettstevagewp@gmail.com wrote:
Ok, I got it - there were some spurious blank lines. Ok, um, it does what you said it does :) Now, how to make this a compelling demonstration that this is _the way foward_?
Steve
On Wed, Dec 29, 2010 at 7:01 PM, Magnus Manske magnusmanske@googlemail.com wrote:
On Wed, Dec 29, 2010 at 12:30 AM, Steve Bennettstevagewp@gmail.com wrote:
On Wed, Dec 29, 2010 at 9:39 AM, Magnus Manske magnusmanske@googlemail.com wrote:
Force-reload, go to an article, and you'll see a new "WYSIWTF" tab (I trust you can decipher the acronym ;-)
Hi Magnus, I'm not getting an extra tab. Perhaps I've done something stupid, but I stuck the above code in vector.js, reloaded, nothing. Same in Chrome, FF, Opera. What simple thing am I missing?
Not sure - works for me. Have a look : http://en.wikipedia.org/wiki/User:Magnus_Manske/vector.js
Maybe some other script in your vector.js dies before it gets to the include point? If so, try moving the lines to the top of vector.js.
Cheers, Magnus
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
On 3 January 2011 20:26, Magnus Manske magnusmanske@googlemail.com wrote:
Update : Misc fixes, diff function, preview function.
How close is this to being something to tell (more of) the world about? (At least the WMF bits of the world.)
- d.
On Mon, Jan 3, 2011 at 8:42 PM, David Gerard dgerard@gmail.com wrote:
On 3 January 2011 20:26, Magnus Manske magnusmanske@googlemail.com wrote:
Update : Misc fixes, diff function, preview function.
How close is this to being something to tell (more of) the world about? (At least the WMF bits of the world.)
IMHO it's mostly working but very much incomplete. More (experienced) people working with it, at least on an experimental level, would be good to weed out bugs; the diff function can prevent save operations that would break a page.
I am uncertain as to how much regular time I can invest in this in the coming weeks. Work would likely be done on a rather irregular schedule. I'd be happy to share the load :-) Maybe in a joined toolserver project (until it matures, at least).
I just committed the source to the toolserver SVN [1], in case anyone wants to play with their own installation.
Where do you suppose to plug it? Signpost? A blog?
Cheers, Magnus
On 3 January 2011 22:53, Magnus Manske magnusmanske@googlemail.com wrote:
Where do you suppose to plug it? Signpost? A blog?
internal-l, for a start. I posted a pointer to my small pamphlet on WYSIWYG there too. There's considerable concern about (2) making editing easier for newbies though mostly (1) what the other two-thirds of the Wikimedia community can do about the severe n00b-biting and admin rudeness on the flagship project, en:wp. *Possibly* they can be distracted with a shiny thing before they start gently suggesting things be done.
- d.
On Mon, Jan 3, 2011 at 11:32 PM, David Gerard dgerard@gmail.com wrote:
On 3 January 2011 22:53, Magnus Manske magnusmanske@googlemail.com wrote:
Where do you suppose to plug it? Signpost? A blog?
internal-l, for a start. I posted a pointer to my small pamphlet on WYSIWYG there too. There's considerable concern about (2) making editing easier for newbies though mostly (1) what the other two-thirds of the Wikimedia community can do about the severe n00b-biting and admin rudeness on the flagship project, en:wp. *Possibly* they can be distracted with a shiny thing before they start gently suggesting things be done.
I head your "shiny" and raise you HTML tag syntax highlighting, now active.
I'm not on internal-l, but fire away :-)
Magnus
On 3 January 2011 23:47, Magnus Manske magnusmanske@googlemail.com wrote:
On Mon, Jan 3, 2011 at 11:32 PM, David Gerard dgerard@gmail.com wrote:
On 3 January 2011 22:53, Magnus Manske magnusmanske@googlemail.com wrote:
Where do you suppose to plug it? Signpost? A blog?
I see the Signpost grabbed it:
http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2011-01-03/Technol...
"WYSIWYG? WSYIWTF!"
- d.
On Tue, Jan 4, 2011 at 12:02 AM, David Gerard dgerard@gmail.com wrote:
"WYSIWYG? WSYIWTF!"
OK, what *does* the TF at the end of the second initialism mean?
Carcharoth
On Tue, Jan 4, 2011 at 11:49 AM, Carcharoth carcharothwp@googlemail.com wrote:
On Tue, Jan 4, 2011 at 12:02 AM, David Gerard dgerard@gmail.com wrote:
"WYSIWYG? WSYIWTF!"
OK, what *does* the TF at the end of the second initialism mean?
http://en.wikipedia.org/wiki/WTF (first interpretation)
Note that I replaced the tab label with "FTW" by now :-)
On Tue, Jan 4, 2011 at 1:02 AM, David Gerard dgerard@gmail.com wrote:
On 3 January 2011 23:47, Magnus Manske magnusmanske@googlemail.com wrote:
On Mon, Jan 3, 2011 at 11:32 PM, David Gerard dgerard@gmail.com wrote:
On 3 January 2011 22:53, Magnus Manske magnusmanske@googlemail.com wrote:
Where do you suppose to plug it? Signpost? A blog?
I see the Signpost grabbed it:
http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2011-01-03/Technol...
"WYSIWYG? WSYIWTF!"
Nice :-)
Update : WYSIFTW now with auto-collapsed references!
2011/1/4 Magnus Manske magnusmanske@googlemail.com:
"WYSIWYG? WSYIWTF!"
Nice :-)
Update : WYSIFTW now with auto-collapsed references!
This is a cool demo, thanks for making and sharing it. It's obviously very buggy, but I think it's the first gadget that actually tries to create a rich-text editing experience directly on WP.
Within the usability initiative in the last year, the team focused on incremental enhancements to the current editing interface. If you haven't seen it, sandbox 6 of the usability prototypes is worth playing with: http://prototype.wikimedia.org/s-6/index.php?title=Main_Page&action=edit
It has both the dynamic table of contents, template collapsing, and a simplified tab view for edit/preview. The first two changes depend on changing the standard <textarea> to a contentEditable <iframe>, which introduces many of the same challenges that manifest as bugs in your WYSIWTF implementation. For example, copy and paste behavior across collapsed elements (as well as properly filtering allowed/disallowed content from paste data) is very hard to properly control across browsers. This massive added complexity and associated bugginess is the key reason why we haven't deployed these changes yet. The other reason is that our usability research has shown that collapsing elements can in fact increase initial newbie confusion as it becomes harder to make a direct match between the two representation modes (Ctrl+F for something you're trying to change no longer works).
There's an internal debate whether the <iframe> editor is at all a good long-term technology foundation to build on, or whether it would be wiser to adopt the Google approach of implementing a new editing surface in JavaScript (see http://googledocs.blogspot.com/2010/05/whats-different-about-new-google-docs... ).
The team is currently focused on finalizing the new ResourceLoader, which will generally make our front-end code more manageable, as well as finishing up phase 2 of the article feedback pilot (the little rating widget showing up on some articles) and ironing out bugs in the new upload wizard. But as we start into 2011, I'm hopeful that we can come up with a good development and staging plan for immediate improvements to the editing interface, as well as a longer term re-architecting towards rich-text editing which ideally allows for incremental benefits to be deployed to WMF projects.
On 4 January 2011 19:56, Erik Moeller erik@wikimedia.org wrote:
The other reason is that our usability research has shown that collapsing elements can in fact increase initial newbie confusion as it becomes harder to make a direct match between the two representation modes (Ctrl+F for something you're trying to change no longer works).
Yeah. This is why usability testing is *not optional*. Programmers are *regularly* surprised by what actual users do with their creations.
Wikipedia already has many productive contributors who are smart, knowledgeable and clueful but basically can't work computers - but can just about cope with wikitext. Imagine if we could get *eight times* the contributor pool, the areas of human experience we could cover if we got in people who were even worse with computers but knew about things other people didn't.
The team is currently focused on finalizing the new ResourceLoader, which will generally make our front-end code more manageable, as well as finishing up phase 2 of the article feedback pilot (the little rating widget showing up on some articles) and ironing out bugs in the new upload wizard. But as we start into 2011, I'm hopeful that we can come up with a good development and staging plan for immediate improvements to the editing interface, as well as a longer term re-architecting towards rich-text editing which ideally allows for incremental benefits to be deployed to WMF projects.
What are their thoughts on the Wikia WYSIWYG editor? I presume Wikia did usability tests. I don't like the Wikia editor a lot (and find it opaque), but I can cope with wikitext.
- d.
2011/1/4 David Gerard dgerard@gmail.com:
What are their thoughts on the Wikia WYSIWYG editor? I presume Wikia did usability tests. I don't like the Wikia editor a lot (and find it opaque), but I can cope with wikitext.
We've both done internal evaluations of the Wikia RTE, and had several meetings with their team to review it and its possible use on WMF sites. This included a demonstration by Gil of applying the RTE to various Wikipedia articles.
The RTE falls back to wikitext mode when it encounters syntax it can't handle. You can see this e.g. on http://twilightsaga.wikia.com/index.php?title=Bella_Swan&action=edit. Wikia has worked on it for years, and a lot of the effort has gone into reducing the number of edge cases like this, both in terms of avoiding complete breakage, and in managing clean conversion back and forth that doesn't lead to dirty diffs (you touch something in one mode, and destroy markup in the other as a result). Sometimes I find it hard to find pages that _don't_ break on their more complex wikis, but to be fair, they are continuing to improve it all the time.
At this point in time, it's the most mature RTE for MediaWiki that I'm aware of which preserves both editing modes. Other than its remaining fragility (which is far greater on a site like WP, where it breaks completely on a large double-digit percentage of articles as of the last test), in order for it to be truly user-friendly in editing WP, things like its template-handling (and other complex syntax like citations) would need to be quite dramatically improved.
So, the short answer is that it's surprisingly mature at this point, but would still require a big push to be usable by us. The remaining question we need to answer is whether it's a technical architecture we want to commit ourselves to, as per my earlier note, or whether (perhaps in partnership with Wikia and others who might benefit from it) we want to focus on a next-generation architecture, consistent with what Google and others have been doing in their editing UIs.
On Wed, Jan 5, 2011 at 1:32 AM, Magnus Manske magnusmanske@googlemail.com > >Nice :-)
Update : WYSIFTW now with auto-collapsed references!
Hey Magnus, not sure if you're looking for more feedback, but, I just tried the section editing and:
1) Can't paste into it (ctrl+v). Other keys also don't work right (home, end...) 2) Can't edit the last character of a section 3) Clicking outside the edited section should do something (ie, prompt you to save or abandon) 4) Double-clicking inside the edited section still does its default behaviour (edit the whole page)
However...this is really cool. And not just for newbies. It instantly makes it much more appealing for me to make a minor change, because it's so much faster (one less page refresh). Please keep going with it.
Steve
On Thu, Jan 20, 2011 at 11:26 PM, Steve Bennett stevagewp@gmail.com wrote:
On Wed, Jan 5, 2011 at 1:32 AM, Magnus Manske magnusmanske@googlemail.com > >Nice :-)
Update : WYSIFTW now with auto-collapsed references!
Hey Magnus, not sure if you're looking for more feedback, but, I just tried the section editing and:
- Can't paste into it (ctrl+v). Other keys also don't work right (home, end...)
I haven't gotten around to implement any of these yet. I just managed to add Ctrl/Alt plus cursor right-left yesterday night...
- Can't edit the last character of a section
Yes, it's a cumbersome little bug I'll have to squash.
- Clicking outside the edited section should do something (ie, prompt
you to save or abandon)
What if you want to copy something from outside the section? (Assuming paste would work...)
- Double-clicking inside the edited section still does its default
behaviour (edit the whole page)
Is it possible that you turned that behaviour on in your user settings? It's off by default, AFAIK.
However...this is really cool. And not just for newbies. It instantly makes it much more appealing for me to make a minor change, because it's so much faster (one less page refresh). Please keep going with it.
Thanks, I will!
Cheers, Magnus
On Fri, Jan 21, 2011 at 9:10 PM, Magnus Manske magnusmanske@googlemail.com wrote:
- Clicking outside the edited section should do something (ie, prompt
you to save or abandon)
What if you want to copy something from outside the section? (Assuming paste would work...)
Good point.
- Double-clicking inside the edited section still does its default
behaviour (edit the whole page)
Is it possible that you turned that behaviour on in your user settings? It's off by default, AFAIK.
Yes, I do have that setting on. I mentioned not as a "help me, double-click is doing the wrong thing" but because lots of other people will probably have it on, too. So it's something to be aware of, and if there's any way of killing that behaviour while editing with FTW, then do it...
Steve