wpviews: keyboard behaviour for a selected view

[iseulde]

Current behaviour:

• Inserting characters doesn't do anything when a view is selected.
• Pressing backspace deletes the view, but also the "space" it took.
• Pressing enter adds a new paragraph under the view.
• Pasting something adds the content to the next paragraph, but sticks it to the existing content.

Behaviour for selected text/image:

• Inserting characters replaces the selection with the characters.
• Pressing backspace deletes the selection.
• Pressing enter also deletes the selection.
• Pasting something replaces the selection.

Conclusion:

Now that we can place the cursor before and after the view, we should also make the behaviour for a selected view more "natural". Since a view is selected clearly, there's no need to assume the user made a mistake. In 3.9 they couldn't place the cursor before or after a view, so these workarounds had to be made.

We should also fix the behaviour of backspace when the cursor is after the view. At the moment it deletes the view, but also the space it took.

[azaozz]

In 29236:

TinyMCE wpView:

• Typing something replaces a selected view.
• Pressing backspace deletes the selection.
• Pressing enter also deletes the selection.
• Pasting something replaces the selection.
• Also merge the different 'keydown' handlers.

Props avryl, fixes #28913.

[iseulde]

Forgot to handle paste... I'd also be better to replace the other remove functions. :)
Just reopening so we don't forget about this.

[azaozz]

In 29246:

TinyMCE wpView: better removal of views, replace a selected view when pasting. Props avryl, fixes #28913.

[DrewAPicture]

Could you please add docs for removeView()? A description, @since, and @param at the very least.

[iseulde]

Currently removeView() is just an internal function.

[DrewAPicture]

Replying to avryl:

Currently removeView() is just an internal function.

And I'd like it to have some form of docs :) Docs are as much for core developers as they are for people extending WordPress.

[iseulde]

Okay, I didn't know we have to document "private" JS functions. Then the other functions probably also need them.

[iseulde]

Are there any guidelines for this? I don't see a page in the handbook for JS. Only
​http://make.wordpress.org/core/handbook/inline-documentation-standards/php-documentation-standards/

[DrewAPicture]

Replying to avryl:

Are there any guidelines for this? I don't see a page in the handbook for JS. Only
​http://make.wordpress.org/core/handbook/inline-documentation-standards/php-documentation-standards/

Not yet. I'm writing a post proposing we adopt the ​JSdoc 3 standard though.

At this point we just need a description of what it does, when it was introduced, and any parameters including the type and description. Something like:

/**
 * What it does.
 * 
 * @since 4.0.0
 *
 * @param {type} view Description.
function removeView( view ) {
	// TODO: trigger an event to run a clean up function.
	// Maybe `jQuery( view ).trigger( 'remove' );`?
	editor.undoManager.transact( function() {
		handleEnter( view );
		editor.dom.remove( view );
	});
}

The hope is to come back later and fix up what's missing (what I'm currently doing primarily for PHP).

[DrewAPicture]

Let's call this fixed and circle back on the docs later.