Better integration with WYSIWYG

I can't visualize how tabbing would work.

Wouldn't it be simpler to have the input format filter act dynamically?

That way, I could set up one input format for CKeditor, another for BUedit, set one to the default, and swap the other in as needed (with no need for WYSIWYG...)

So the way the "Tab" would work is like the current disable rich text link, that sounds easy enough.

That would be a nice option, however, I would like also the ability to completely integrate with the WYSIWYG api module.

I think that the disable/enable rich text is a separate function. It's purpose, IMNHSO, is to give the user access to the raw HTML code that ckeditor produces so that it can be fixed. That's separate from the purpose of editing in BUeditor.

Whatever makes it easier for my users I am for, and I need to give users the choice of both editing modes. I especially don't want to force long-time users into the CKeditor world.

Unfortunately, one would think that installing CKeditor and linking it to one text format, and then installing BUeditor and linking it to another text format would be simple, but it isn't. The installation seems to be path dependent (fancy lingo for "sometimes it works and sometimes it doesn't"). I'd settle for a quick fix that made swapping the editors by text format work.... [UPDATE I thought that this patch was in the 7.x-2.x-dev that I had installed, but apparently not, since after patching I can swap.]

I'm hesitating on the tabs because the HTML that ckeditor and BUeditor produce is very different, and BUeditor exposes the markup. So if the user starts out in BUeditor, shifts to CKeditor, and then Shifts back to BUeditor, they are going to see much more intensive HTML markup than they started out with, and that may confuse and dismay them. When there's one window with a dropdown, and the user switches, and if they have a "Wow, that's weird!" reaction, they can unswap immediately with the dropdown. Cause and effect aren't so evident with tabs.

In addition, both editors support different buttons and even button logic. So what happens when the user creates video using the media element in CKeditor and then switches to BUedit which also allows video but using different markup?

I'd almost turn the handle 180 the opposite direction, if (1) I could swap the input format with the dropdown and (2) have the option to lock down the initial choice of format after the first Save to avoid all these confusing compatibility issues. (Maybe lock by default, and then have a permissions-enabled unlock button in a vertical tan, the way OS handles some things through the admin interface.)

From what I can tell the tab idea is the same as the "disable rich-text" button --only styled differently.

The bueditor is a very simple editor that acts directly on the textarea. It doesn't rely on iframes like other editors. So theoretically switching to non-rich text more would just show the plain text-area and not a whole new editor. I think that the tabbed rich text editor switch is a good idea and will really make the different view more apparent. Bueditor is more of a helper than a real editor so it should integrate flawlessly.

If you are saying that the ckeditor too crappy of html to be sullied by the buediter then I really don't know what to say other than --don't use ckeditor. I prefer the wymeditor.

@frob

If you are saying that the ckeditor too crappy of html to be sullied by the buediter then I really don't know what to say other than --don't use ckeditor. I prefer the wymeditor.

1. No, I'm not saying that. I'm saying the difference could be confusing to users. That's going to be true no matter which WYSIWYG editor is used.

2. No, I want users to be able to use both editors. That's my use case.

So one scenario is:

1. Enter clean minimized easy-to-read HTML markup in BU edit tab

2. Switch to WYSIWYG tab

3. Return to BU edit tab.

4. HTML markup has changed to WYSIWYG markup.

Yes?

One issue I've seen in Wordpress WYSIWYG is that when you use the code view, switch to the design view and then back to the code view, the editor reformats automatically, doing things such as moving close tags and removing blank lines. I would like to see the BU tabs respect whatever is in the BU code tab when switching back and forth, even if the code in question might be "wrong". A preference check box for this behavior may be a good idea for those administrators who are responsible for other content editors and who happen to prefer the code fixing behavior to reduce overhead.

For all I know that Wordpress WYSIWYG behavior could be a feature that can be overridden or changed, but I haven't used Wordpress as much as I have Drupal.