Re: Re: window-position in after-move-hook returns old window position?

> Situation is a bit confusing because there is after-move-hook as you
> mentioned and tried in the other post, but also window-moved-hook,
> which I don't know if you tried too. Maybe this other is better?

Yes, I did miss `window-moved-hook`, however, it's still wrong. It
behaves like `while-moving-hook`, meaning it is called constantly while
moving the window interactively (`after-move-hook` only is called after
you "drop" the window), but `get-window-x` still reports the old
position during its callback. Easiest to test when using "Pack window
SOMEWHERE" when moving the window.

> Anyhow, if the 3 above do it, great.

Well, `while-moving-hook` is not called when using "Pack window
SOMEWHERE", but so far I could live with that, but it still would be
nice to have.

But even though `after-move-hook` and `window-moved-hook` are called on
that action, `get-window-x` reports the old position when called in
their callbacks.

> Bonus: while-moving-hook works
> with outline and opaque moves tho info pages also say it's called
> before the actual move, so maybe the toggle is lagging by one mouse
> event. As in: multiple events in one zone but single last one in the
> other zone would fail to toggle, or so I suppose.

I'm amusing such a thing, but so far I didn't really look into Sawfish
on where that could be.

-- 
Sawfish ML