[Tue Jul 14 2009] [08:58:47] I was just reading Peter Jones' proposals for simplifying control of which editor is used, and I can see the sense in what he's done [Tue Jul 14 2009] [08:59:41] the current controls we have are overcomplicated, and depend on the wysiwyg editor being TinyMCE [Tue Jul 14 2009] [09:02:59] for the templates to work, they need some way to recognise when an "alternative" editor is preferred. Peter has gone the route of * Set EDITMETHOD = wysiwyg which is fine, except that it still assumes there is only one editor available [Tue Jul 14 2009] [09:03:06] viz. TinyMCE. [Tue Jul 14 2009] [09:03:30] drupal has got this: http://drupal.org/project/wysiwyg [Tue Jul 14 2009] [09:03:46] I'm thinking that * Set PREFERRED_EDITOR = TinyMCE / * Set PREFERRED_EDITOR = FCK / * Set PREFERRED_EDITOR = raw would be better [Tue Jul 14 2009] [09:03:53] it leverages the notion of editor profiles for different purposes [Tue Jul 14 2009] [09:04:02] interesting [Tue Jul 14 2009] [09:05:03] not sure how they switch between profiles. [Tue Jul 14 2009] [09:05:06] what drupal have done is what I originally wanted (and the reason I originally split WyswiygPlugin off) [Tue Jul 14 2009] [09:05:24] I have always seen editor choice as part of the type definition [Tue Jul 14 2009] [09:05:33] there is more wrt editor api [Tue Jul 14 2009] [09:05:41] y? [Tue Jul 14 2009] [09:06:00] for instance our two editors tinymce and natedit have problems to agree what to do when on form submit [Tue Jul 14 2009] [09:06:21] one reason why editchapter + tinymce does not work is [Tue Jul 14 2009] [09:06:30] I wrote a FCKeditor integration a couple of days ago; it has a third view :-/ [Tue Jul 14 2009] [09:06:50] that editchapter needs to recombine the topic text sections before submitting the textarea...which fails together with tinymce [Tue Jul 14 2009] [09:07:31] yes; but that's because editchapter has a (apologies) hacker view of the content. It really needs to work through TOM. [Tue Jul 14 2009] [09:07:43] for the same reason current natedit+tinymce suffers from data loss when switching back to wikitext first and then submitting the form [Tue Jul 14 2009] [09:08:40] editchapter worx while all other sectional edit solutions are out of order for a couple of years [Tue Jul 14 2009] [09:08:58] hey, I'm not criticising, just observing. I agree with you [Tue Jul 14 2009] [09:09:20] TOM has never been in a state for EC to use, so it had to do "what works" [Tue Jul 14 2009] [09:09:38] and we both discussed _why_ editchapter has to be hack: there's no formal notion of "section" in the core. [Tue Jul 14 2009] [09:09:46] right [Tue Jul 14 2009] [09:10:08] what I was referring to was more the client side...not the hacky server side [Tue Jul 14 2009] [09:10:14] javascript [Tue Jul 14 2009] [09:10:21] ok [Tue Jul 14 2009] [09:10:31] we need an editor api on the client side [Tue Jul 14 2009] [09:10:37] agreed [Tue Jul 14 2009] [09:10:43] or at least a "model" [Tue Jul 14 2009] [09:10:43] at least some agreement onSubmit [Tue Jul 14 2009] [09:10:46] y [Tue Jul 14 2009] [09:11:14] TinyMCEPlugin was written assuming it ruled the universe [Tue Jul 14 2009] [09:11:24] (expedient) [Tue Jul 14 2009] [09:11:55] there are a set of possible candidate clients for this part of the editor api [Tue Jul 14 2009] [09:12:11] editchapter needs a way to hook in its part [Tue Jul 14 2009] [09:12:35] tinymce needs a way to convert html2 tml before submit as well...as far as I see [Tue Jul 14 2009] [09:12:43] why does JS need to know anything about "chapters"? [Tue Jul 14 2009] [09:12:47] before "text" is submitted finally [Tue Jul 14 2009] [09:12:58] nothing [Tue Jul 14 2009] [09:13:05] surely it just edits (1) some text and (2) an address where the text comes from [Tue Jul 14 2009] [09:13:43] can we assume that all editors will start up the same way? camp on a