Closed ivy-lli closed 4 days ago
@ivy-lli Yeah, I can see how in your use case the behavior seems erroneous. I guess it depends a bit on your interpretation of a multi-move. Is it a single operation or is it just a convenience wrapper for several "independent" moves. However, we should not end up in an invalid state in any case.
Providing a fix would be great help, thank you! However, I think both use cases are in general valid so maybe there could be a flag indicating whether all moves need to succeed or not which can be the new default in my opinion since it is probably the more common case anyway. What do you think?
Yes I also thought that a flag or something like that would be nice to control this behavior if it is wanted.
I'm not sure if this is even the desired behaviour, but I think I open an Issue to clarify if not.
The problem is the following: If you move multiple elements and one of them matches an invalid move (because of the registered restrictor) this element will be restored to its origin location while the others move. This may results in a stacked elements.
Shouldn't all elements be reset to their origin location?
Our glsp project (restrict to move elements to "negative" area):
glsp workflow example with enabled NoOverlapMovementRestrictor:
Should I open a PR to fix it?