Re: Autoupdating EntryCompletion (was Selectively trapping keypresses)

[muppet <scott asofyet org>]

On Apr 17, 2007, at 10:42 AM, Jeffrey Ratcliffe wrote:

> On 17/04/07, muppet <scott asofyet org> wrote:
> > I couldn't reproduce that after tinkering for just a few moments,  
> > but i think
> > i see it in the code...
>
> Replace "one" with "twelve" twice, and during the second replacement,
> the error comes.
>
> > Any change to a TreeModel invalidates existing TreeIters.
>
> > > $cmp_model -> signal_connect('row-inserted' => sub {
> > >   my ($model, $path, $iter) = @_;
> > >   my ($val) = $cmp_model->get($iter, 0);
> > > warn "inserted $val\n";
> > >
> > > # Weed out duplicates
> > >   my $iter2 = $cmp_model->iter_next($iter);
> > >  while ($iter2) {
> > >   my ($val2) = $cmp_model->get($iter2, 0);
> > > warn "list $val2\n";
> > >   if ($val eq $val2) {
> > > warn "removing $val2\n";
> > >    $cmp_model->remove ($iter2);
> > > warn "removed $val2\n";
>
> I can add a return statement here, as there will only ever one
> duplicate, and then there are no problems with iters. But the error
> still comes.

I spent a few minutes running this code under gdb with the --g-fatal- 
warnings option...

The EntryCompletion uses a TreeModelFilter to narrow down the  
contents of the completion model to match what you've already typed.   
By the time we're doing that, the completion model is in a rather  
hosed state, and we get warnings about iters not being valid.   
Specifically, the iter's stamp does not match the model, which means  
that something Very Bad has happened.

The basic situation in which i've seen this happen before is  
modifying the model while iterating over it, which is exactly what  
your row-inserted handler is doing.  I can't pinpoint exactly *how*  
it is getting corrupted; it would take a lot of tracing and digging  
through unfamiliar code, since the error happens quite a way after  
the actual corruption occurs, and i'm just not up for that tonight.

On a hunch that the problem stems from modifying the completion model  
in a handler for a signal that is emitted when the model is  
modified...  i tried a slightly different approach.

Your code is unconditionally adding the user's text to the completion  
model, and then scraping out any duplicates.  Why let the duplicates  
in there in the first place?

I removed the entire row-inserted handler, and did this, instead:

  sub update_completion_model {
      my ($model, $new_value) = @_;
      # If not already in there, append.

      my $iter = $model->get_iter_first;
      while ($iter) {
          my $old_value = $model->get ($iter, 0);
          return if $old_value eq $new_value;
          $iter = $model->iter_next ($iter);
      }

      $model->insert_with_values (-1, 0, $new_value);
  }

  $slist -> get_model -> signal_connect('row-changed' => sub {
      my ($model, $path, $iter) = @_;
      my $text = $slist->get_model->get($iter, 0);
      update_completion_model ($cmp_model, $text);
  });


And i can no longer trigger the assertion failures.


--
If the monkey could type one keystroke every nanosecond, the expected  
waiting time until the monkey types out Hamlet is so long that the  
estimated age of the universe is insignificant by comparison ... this  
is not a practical method for writing plays.
  -- Gian-Carlo Rota