[cmv4] 'origin' argument starting with "*" no longer works

[peterflynn]

I've been testing with everyscrub (patched to use Alt+drag instead of Ctrl) and none of its replaceRange() calls are batched. ReplaceRange with a "*" prefix is supposed to batch all contiguous undos regardless of timestamp.

Note that the inline color picker still gets undo-batched properly using a "+" prefix.

I debugged into addChangeToHistory() a little bit, and it looks like all the checks pass in the first if statement except for the last one: lastChangeEvent() is returning undefined.

[redmunds]

Take a look at this commit for InlineColorEditor -- I think it fixes the same problem.

[njx]

Yes - you now have to make sure that if you do a replaceRange followed by a selection change, and you want everything to be merged, you have to wrap them in an operation.

[peterflynn]

@njx Something to add to the API change guide I guess?

It's too bad there's no way to just pass an "origin" for selection changes too -- that seems like a less disruptive fix for existing code...

[njx]

Ah, yes, CM actually takes the origin parameter in its selection APIs now. I could add that parameter to setSelection()/setSelections() on Editor. I'm not entirely sure that obviates the need to wrap them in an operation, but it might.

[njx]

@peterflynn - if you have time, would you mind locally trying to add the origin argument to setSelection()/setSelections() and passing it through to the CM selection API (see http://codemirror.net/4/doc/manual.html#api_selection), and seeing if that fixes your problem without having to wrap in an operation?

[njx]

(or I could put up a PR to try if you want)

[njx]

@peterflynn - see #7196

[njx]

OK, I just took a little time to test this out myself (using the InlineColorEditor), and it looks like selection origins only allow merging with other selections, not edits. You still need to wrap the associated edit and selection in an operation in order to merge an edit and a selection together. I can ask Marijn if he could merge selections and edits with the same origin. In principle, though, it makes sense to me that (now that selections are a separate part of undo history) if you want an edit and a selection to be considered part of the same history event, you should group them in a single operation. It is a behavior change though.

[njx]

(See continued discussion in codemirror/codemirror5#2305)

[njx]

FBNC @peterflynn now that we can specify origins in the selection API and they should merge properly.

[njx]

Oops, forgot to reassign to @peterflynn

[peterflynn]

Confirmed this is fixed for my use case, and we've added it to the migration docs as well