[XBoard-devel] Variation Trees

[h.g. muller]

I would like to have some feedback about the new variation support in 
XBoard 4.5.pre0.
The way it is currently implemented initiates a new variation (pushing the 
tail of the
existing game on a stack) every time you enter a move in Analyze or Edit 
Game mode
when not at the final position of the current line. (In the final position 
it would just append
the move.) Previously, the game would simply be truncated before appending 
the move.

The danger of the new method is that people that are used to analyzing 
without using 'revert',
but in stead by using '<' to step back through the current line, and then 
try an alternative move,
wil pretty quickly run into a 'stack overflow' error popup, as they save 
game tail after game tail
on the stack, and never pop anything. I can imagine they would perceive 
this as extremely
annoying. I never use Analyze mode myself, so I have no idea how it is 
typically used...

I guess people could get used to using 'revert' for retracting an entire 
variation to the point
where they started it. But when they want to try an alternative move from a 
position between
the point where they started the current variation, and its end, that would 
be very inconvenient,
as it would retract some of the moves they still want played. So the use of 
'<' and '>' to step
to the branching point, and enter a new move there, seems natural. This is 
fine if it was just
the first of a number of sub-variations on the current variation they 
wanted to explore:
when they are done with it they can then 'revert', and use '<', '>' to step 
through another
position to try another sub-varation. But it does not provide for the case 
where they want
to abandon the tail of the current variation entirely (because they feel it 
is refuted).
It would then be annoying to them to revert to it every time. Not only 
because they have
to hit 'revert' one extra time, but mostly because this interferes with 
saving the variation
they finaly do want to keep (which is now a sub-variation on a silly line) 
as variation
comment in the PGN through 'annotate'.

The logical way to solve this is to let them use 'truncate game' to 
truncate a current line
they don't want to keep, before entering new moves, so that entering these 
moves will
not start a new (sub-)variation, but simply replace the tail of the current 
line.
However, 'Truncate Game' is now implemented by first discarding the entire 
variation stack,
and making the current variation (after truncation) the main line, making 
it unusable for this
purpose. This might be an undesirable implementation of 'Truncate Game'. 
But if you make
'Truncate Game' just act on the current variation, the problem exists that 
there can be
game tails pushed on the variation stack that branch off on a move after the
truncation point, and an attempt to restore them would then leave a gap in 
the game.
I guess this could be handled by not discarding the complete stack, but 
just all game tails
on it that start behind the truncation point at the moment you truncate.

An alternative would be to not make the starting of a new variation automatic.
('autoTruncate mode', if you want.) Playing a move from within an existing 
line would then
result in the old behavior of truncating the line and appending the move, 
rather than pushing
the tail on the variation stack. A new variation could then be started, for 
example, by holding
the Shift key down while making the move. This might provide better 
backward compatibility,
but it is not essentially different from explicitly having 'Truncate Game'. 
(Just that you have to
press an extra key in the opposite case.) So it will pose the same problems 
w.r.t. game gaps.

An alternative way to solve the gap problem is to not just push game tails, 
but the entire game,
each time you start a variation. This could lead to an explosion of memory 
usage, however,
if you are trying out many short variations at the end of a long game, and 
thus is not very elegant.

I would like to know what people think should be the desired behavior here.