Fixed it. Thanks!
With main now (so builds tomorrow), you can now right-click in the empty space of an area’s header and select “Move/Split Area” as this now works when selected from a menu. So you can add that to Quick Favorites if you like. And yes, it now also works if you assign a custom shortcut to it too - which is a lot of fun.
Thanks, tested, it’s fantastic! Some minor issues:
Let me know if any of those aren’t clear or you can’t reproduce! Thanks a lot for this work Harley, you’re doing awesome work as always.
Fixed. Well, just committed, so builds with it tomorrow.
When previewing an editor split, it’s not clear to me how it’s determining…
When calling from a menu or shortcut the split now behaves as if you had started from the top-left corner, so it should always act in a predictable way.
the shortcut isn’t displayed next to the operator in that menu like normal.
I’m not sure yet why that is the case.
it doesn’t seem to initialize correctly until the mouse is nudged…
Whether started from a menu or shortcut it should now give immediate feedback.
Yep, initialization and cancelling issues seem fixed, thanks!
I figured out why the shortcut isn’t showing up next to the operator. There are actually multiple related issues here, all caused by the fact that source_xy is a parameter:
So I wonder if the operator could lose the parameter, or have it be “optional” and just grab the coordinates from context instead. I think that would fix all of this.
Separate (ish) topic:
Can this operator ship with a default shortcut? I think it would be great. In the past I’ve had a pie menu for area splitting and merging bound to Alt+`(grave key), but of course it could be anything else that’s available.
I haven’t found a reliable way to do that. For the menu item on the header area menu I did try leaving off the coordinates and checking the context. But you get the wrong area if they are arranged in such a way that your mouse is over a different area when selecting the menu item.
However, because this operator now works from a menu, shortcut, etc I have removed OPTYPE_INTERNAL from it. This way it now shows up in the Operator Search (F3) list. If you make a shortcut there it seems to work correctly.
I first have to convince more people (Admins, Studio, etc) to try and test this and get it out of Experimental first. Then maybe they will see the utility in having a shortcut for it. After all it is only ONE now, that does splitting, joining, docking.
I’ve been using this feature some more and I’m not a huge fan of the new “editor icon is on the cursor” change. But as always, this might just be a “I’m not used to it yet” issue.
I’m not a huge fan for these reasons:
Testing was done on both macOS and Windows.
I don’t like icons as well, and don’t like fixed 50% default also, and the thing is neither of them were in initial implementation, both were added based on feedback and both are being incrementally backtracked, creating just more unnecessary work for Harley.
I’m not a fan of how things like this develop tbh, endless testing on experimental branches, without actual projects, actual casual users is pointless and will go on forever with tweaks. This should just be taken out of experimental, give people chance to evaluate it, use it for couple of weeks, see what works in actual work environments and what doesn’t. I’m afraid we’re heading to a position where too many people have been asked for opinion, and too many people have to sign off, and too many people want too many different things, and in the end this will just stay in the experimental like numerous stuff that is already frozen in time in there.
Yeah, it doesn’t add much, although nice to have some cursor change. I could probably make a custom “dragging area” cursor but that is a lot work right now to get right on all platforms. I’m hoping to improve that one day.
I’ll try making a bit smaller for now and see if it feels any different.
I can’t think of anything here that has a 50% default, but maybe I need more coffee. Do you mean something related to snapping?
Yes I forgot word “snapping” in the middle. I mean I do like it, just don’t like that its default. I can hardly remember case where I wanted to drag something like Outliner to the other side of the screen and wanted it to be 50% of the 3D view, you usually want them to be quite narrow, either vertically or horizontally.
But now that option for custom size is back I’m not too fussed about i
Ah. You didn’t like the old behavior where you were always splitting an area in half. But you like the new way of selecting the placement and size at the same time. Yes, that is one of my favorite parts of this and I’m glad it is back.
Huh, for me “new” behavior was old behavior because that’s what we first saw in meetings 
Yeah, I was only a bit confused because the current behavior now has a slight snap at 50%. LOL
Could make it smaller and show the regular mouse cursor, so it looks more like a drag and drop.
I made a PR for testing this.
I agree with what others said, replacing the whole cursor is weird. Showing the icon next to it feels better!
What about using the “drag” cursor icon instead of just the arrow? The one that appears when you press G:
I think it’d be coherent with every OS and with similar dragging actions in Blender itself.
Just to add to the comments above, I’ve been using this feature every day for a week or so and I’ve really enjoyed it. I really hope it manages to get out of Experimental and get more users and testers, as in my opinion it’s really smooth and nice to use 
So good to see this feature
Is there way to undo the operation on the editor? For example, Cannot undo merged (closed) editor? It takes several steps to manually restore the original state.(I feel like it’s not suitable to post here.
)
Not yet, but bears thinking about. Although editor operations don’t current support undo they also don’t interfere with your undo stack. As in right now you can do something useful in the 3D Viewport, make an editor change, and then undo or redo that earlier operation. Even if you were only able to undo the very last editor change that might stop you from undo/redo of anything before it. Might need some thought.
I’d love a separate undo stack for just UI layout stuff.
How much separated? Do you mean that it wouldn’t be connected to Ctrl-Z at all? Perhaps just a menu item somewhere for “undo last layout change”?
yea, most 3d apps have separate undo stacks for all sort of things, outside of the main ctrl z
the most popular being the one that undoes the viewport movements 
