Multiple ColorEditor fixes

[marcelgerber]

Fixes multiple issues with InlineColorEditor:

• Use cm.markText() instead of cm.setBookmark() (implements this comment)
• Take advantage of markText() API for inline editor ranges #2165
• When end of range is deleted in color editor, it can edit the wrong remaining portion #2166
• Color editor should use same heuristics for host code edits as for the text field #2175
• Cursor jumps to wrong place after undoing 2nd colorpicker change #2805
• Deleting part of hex color breaks Color Editor #10357
• one new unit test, one unit test re-enabled, one unit test updated

[redmunds]

I can see that this problem existed before with _startBookmark/_endBookmark, but _marker can be undefined or null, so that should be checked here to prevent a NPE.

[marcelgerber]

I don't think it can ever be null - cm.markText() always returns a TextMarker instance, and we initialize it in the constructor and only .clear() it on close, so when could this ever be null?
Of course, this._marker.find() can be null.

[marcelgerber]

I just tested this - as long as the InlineColorEditor is open, this._marker is always an instance of TextMarker.

[redmunds]

Yes, I'm certain that this._marker will never be null in the current code. But the constructor does not enforce that a valid marker is passed in and you can see some unit tests where creating new InlineColorEditor() does not pass any parameters (i.e. marker is undefined). This is just to be safe for any future usage.

[marcelgerber]

Ah yeah, now that makes sense. Changed.

[redmunds]

Done with review.

[redmunds]

Looks good. Merging.

[peterflynn]

@marcelgerber Would you be interested in making a similar cleanup to the easing function editor at some point? Bonus points for finding a way to share some bookmark-management code between the two :-)

[marcelgerber]

I did that and found that there's a lot of shared code in getCurrentRange - where to put shared utility functions for Inline Editor Extensions?