[XBoard-devel] Premove again

[h.g. muller]

OK, I think I now understad what the premove problem is:

My guess is that people that who complain it is not working, are trying
to enter a recapture as premove. When you do that, the toSquare of the
move still contains your own piece at the time you enter the premove,
so it would be an own-piece capture. Now the logic for entering click-click
moves is such that when you enter a capture-own, it takes the second click
as a new fromSquare click in stead of a toSquare of a move that obviously
would be illegal.

When I test if premove works, I of course never try that, since I already know
that it does not work. I assumed this to be a commonly known limitation,
and we even discussed it on WinBoard forum.

BUT...

I never considered drag-drop moves. When you drag a piece over a friendy one,
there is no ambiguity with the case where you changed your mind and wanted
to grab a new piece in stead of the one you already selected. And there is no
justification to reject the move, as it could be a valid premove. Indeed, I 
see now
that the 4.2.7 code does only make the capture-own test in the click-click 
case,
(mouse-button down with an already valid from square), not in the drag-drop 
case
(mouse-button up on a different square than the preceding down).

And I moved this test to UserMoveEvent(), which is called in both cases, and
where it is tested before determining if we have a premove. (I think originally
I had moved it after the switch that determines this, as part of fixing the 
promotion
popup occurring on obviously illegal moves, but that gave problems in other 
modes,
so later I moved the capture-own test to before that switch. And that must have
created the premove problem with recaptures, both in XBoard and WinBoard,
as the test was now in back-end code.)

The test is a bit more involved now than it was in 4.2.7, because of 
variant support
(in Chess960 capture of own Rook is used to enter castling unambiguously).
For this reason it made more sense to move this test to the back-end.
(I think it is bad to have variant-dependent code in the frontend.) But it 
should have
its own routine, e.g. Boolean CaptureOwn(), and not be part of UserMoveEvent(),
which would be called for both the click-click and drag-drop case.

One problem remains: In Chess960 it is conceivable that you have a setup with
Ra1, Kb1, and that Ra1 is attacked, and that you would want to enter a premove
Kb1xa1 to recapture. But if the opponent does not capture, this now would be
interpreted as a castling premove. So unlike other recaptures, this would 
be an
unsafe situation to enter premove; the move is not guaranteed to be illegal 
when
the opponent does not play the expected move. But I guess this is a minor 
problem,
as there are plenty of other cases where a premove is not safe (non-captures,
or when the opponent could capture in two ways). It would have been better
to represent the FRC castling by Rx(own)K, as a K cn never be recptured. 
But this
is very uncomman, and would probably create confusion in itself.