[vile] longstanding fence buglet

[Paul Fox]

there's an old, old, bug in vile that i've mentioned before, but
is very hard to reproduce.  last night i had the perfect
confluence of a) being able to reproduce it relatively reliably,
b) while running a copy of the editor built with debug symbols,
and c) for which i still had a matching source tree.  win!  so i
spent some time and tracked it down.

the symptom of the bug is that sometimes when performing an
operator command on a fence-match motion, the operator will leave
the closing fence untouched.  i notice this mostly on C comments
and ifdefs -- for instance, i position the cursor on "#if foo",
type 'd%', and the '#endif' gets left behind.  undo, redo, and it
goes away.

it turns out that the behavior is timing sensitive, and related
to syntax coloring.  the colorizer runs based on a timeout from
the character input routine -- i.e., if you stop typing for half
a second, the color filter will be forked.  the problem is that
the colorizer is itself an operator command.  when an operator
runs, it sets a global "doingopcmd" flag, which informs the rest
of the editor what's going on.  in particular, it causes some
motions to behave differently.  for instance, if you're on the
'#' in "#ifdef foo" and just type '%', you want your cursor to
land on the '#' of the "#endif".  but if you do 'd%', you want
the motion to span the whole terminator instead.

the problem occurs if you make an unrelated change to the file,
and before the colorizer can run, you start an operator-based
change.  for instance, if you delete the line above an #ifdef
with 'dd', then immediately commence a d%:
    ddd<pause>%
the colorizer is poised to run after "dd', but you beat the
timeout with the next d character.  the colorizer then runs
during the pause (and here's the bug) it clears the doingopcmd
flag when it's finished.  you then type '%' to finish up, but the
motion it causes doesn't include the "#endif", because doingopcmd
is no longer set.

i'm going to let tom decide how he wants to fix this -- either
the autocolor hook should be kept from running during an
operator, or it should save/restore the doingopcmd flag.  the
latter is preferable, i think, but there's probably some other
stuff (pre_op_dot, post_op_dot) that needs saving/restoring as
well -- perhaps they should be bundled into an "operator_state"
structure of some sort.

anyway, this bug has been niggling at me for a long time -- i'm
happy to finally understand it.

paul
=---------------------
 paul fox, address@hidden (arlington, ma, where it's 73.4 degrees)