Movement delay breaks movement

[myshkin]

Reported by macang on IRC: when movement delay is nonzero and the roguelike keyset is on, the hjkl movement keys only work every other keypress, and the yubn movement keys don't move at all. He reported this with 3.3.2 on OS X 10.6.6; I can reproduce it with v4 on OS X 10.6.8 with both the roguelike and standard keysets. I suspect it is not port-specific.

[myshkin]

On IRC, BreathesFire? confirms that it also occurs on 3.3.0 Windows:

Oh that's odd.  Adding a movement delay disables num-keypad input, but the standard arrow keys work
Working off a windows 10-3-2011 compile
Actually, it forces you to hold down the key and wait for effect
I'm thinking movement delay should only apply to auto-run with '.'
It also stores the last movement key and waits for input after x-milliseconds, then uses the old direction
so if you are holding down a movement key, release, then press a new direction, you will continue once more in the old direction
Using the run command also requires holding down the key to get a running direction prompt
Then the game delays for each space ran, but the screen is not updated between each sqaure movement
The result is a long delay until @ appears at the end of his run.
So yeah, movement delay is unplayable on 3.3.0 for windows

[myshkin]

See also ​this oook thread. The bug is not as old as 3.2.0.

[david3x3x3]

I ran a git bisect and I think the problem was introduced with commit 9ca1731.

[magnate]

[b346826] in master and [807b29f] in v4-master - thanks David!