Enforce EnterMode

[neilj]

This is similar to #1464 (possibly a duplicate?).

When the enter mode is set to 'div' and you are inside a preexisting <p>, hitting enter inserts a new <p> not a <div>. Now I understand that this is sometimes useful, but I'm currently using FCKeditor for online email composition, and here our customers expect hitting enter to always give them one space, and due to wanting to support bi-directional support we can't use br mode.

The fix for this is very simple - I've added a new preference FCKEditor.ForceEnterMode which takes a boolean value (and should probably default to false). When set to true it will always use the given tag, even if it is splitting the opposite tag.

I've attached a patch.

[neilj]

Patch

[neilj]

Sorry, there was a bug in the original patch where if you were inside a list, hitting enter would give you a new line rather than a new list item. I think that may be forcing the mode a bit too much. I've put the new patch inline at the bottom of this message. Please ignore the attached one.

I feel my original explanation of this new feature/bug fix was a bit inadequate, so to see the difference from the current version consider the following:

1. The editor is in 'div' mode.

2. The starting html of the editor is preset to the following:

<p>This is some <strong>sample text</strong>. You are using <a href="http://www.fckeditor.net/">FCKeditor</a>.</p>
<p>A little more text</p>
<p>And a bit more.</p>

3. Whilst inside one of the paragraphs, you hit enter. If you are in the middle of the paragraph, it is simply split in two with both options. But if you are at the beginning or end, the behaviour differs:

Behaviour with patch (and option enabled) - a new <div> is inserted before/after paragraph as appropriate.

Behaviour without patch (or option disabled) - a new <p> is inserted before/after paragraph as appropriate.

Updated patch:

classes/fckenterkey.js

@@ -478 +478 @@
 
                                 // If is a header tag, or we are in a Shift+Enter (#77),
                                 // create a new block element (later in the code).
-                                if ( !this._HasShift && !(/^H[1-6]$/).test( sPreviousBlockTag ) )
+                                if ( !this._HasShift && !(/^H[1-6]$/).test( sPreviousBlockTag ) && ( !FCKEditor.ForceEnterMode || sPreviousBlockTag == 'LI' ) )
                                 {
                                         // Otherwise, duplicate the previous block.
                                         eNewBlock = FCKDomTools.CloneElement( ePreviousBlock ) ;
                                 }
                         }
-                        else if ( eNextBlock )
+                        else if ( eNextBlock && !FCKEditor.ForceEnterMode )
                                 eNewBlock = FCKDomTools.CloneElement( eNextBlock ) ;
 
                         if ( !eNewBlock )

[w.olchawa]

I've just added your changes to a patch. It will be easier to check the patch that way.

[robmueller]

Updated patch

[robmueller]

I've updated the patch with the following changes.

1. It's checking FCKConfig for the option, not the incorrect FCKEditor

2. If hit Enter in a block and the block you're in is the same as the EnterMode block tag to create, then it clones the current block tag instead of creating a new one.

The main reason for this is if you set the justification on a block (eg. style="text-justification: right"), or direction (eg dir="rtl"), then that should be cloned to the next block/line when you hit Enter even if ForceEnterMode is on