Due to the displace/displace_wtag madness we forgot to make sure that scope_displace actually redraws or moves the gobj. That means when you "Tidy Up" and the displace callback is called back, the GUI doesn't actually move the gobj to the new position. (Even though the new position is set correctly in the backend.)

So, add whatever call is necessary inside scope_displace to update the new position of the gobj in the GUI.

For the record:

• displace_wtag is an end-run around Pd's stupid, potentially socket-breaking noise of sending N messages to update position of a selection of N objects.
• displacefn still gets invoked in the case of clicking "Tidy Up." Why? I don't know.
• are there other callers to displacefn in the codebase? I don't know.
• for any external GUI in Purr Data, you have to have a displace_wtag routine which just updates member fields, and a displace callback to update fields plus updating the GUI manually. It's dumb. Luckily, the API for drawing GUI externals is so bad that nearly no one creates new external GUI widgets with it.
• the name of the displace callback member of t_widgetbehavior? displacefn
• the name of the displace_wtag callback member of t_widgetbehavior? Is it displacewtagfn or perhaps displace_wtagfn? No. It is displacefnwtag.

I like that last one a lot. It fits well with the "append-more-hair-to-the-hairball" process common to Pd, Pd-extended, and Purr Data.

And it works for other things, too: consider the South Carolina Democratic Primary Debateplustwobillionaires. I think we've inadvertendly hit upon an effective design pattern quite useful for reasoning not only about software but also our modern world in general.