GNOME Bugzilla – Bug 602149
gtksourcecompletionwords problems with context GtkTextIter
Last modified: 2009-11-28 22:07:21 UTC
The words completion provider is modifying the current GtkTextIter. If we try to use it later, the iterator is invalid. The words completion provider must copy the given iter and work with that copy instead of use the given one.
Really the scene is: 1.- User writes something 2.- insert-text signal is emmited 3.- completion creates the context and store the iter in it 4.- words provider store the context/iter to get the written word in an iddle 5.- another application gets insert-text signal and modify text (by example an indentator) 6.- When the iddle function of words provider is called, the context iterator is not valid. I don't know how must control the iterator: * We should create a mark in gtksourcecompletioncontext instead of store the iterator? * We should create a mark in the words provider? * Other options...
I'm not sure which version you are using for this, but this problem has been fixed some time ago already. We decided it is up to the provider to handle this gracefully. In the case of words completion, it will store the word, and use that in the idle function. So there is no iter used there. However, the context iter _is_ used in get_start_iter, to get the text buffer corresponding to the iter. I haven't seen any problems there yet, but I can imagine this could be problematic if somehow the iter in the context was invalidated before calling this function. To fix this, I would suggest to simply use context_get_view for this instead of taking the buffer from the iter, so there are no problems there (get_view already exists in the current API). Do you agree? Or are there other problems I overlooked here.
I'm using the last commited changes. I will try to use get_view instead of iter.get_buffer and I tell you if it works. Thanks Jesse!
I know where is the error exactly now. I explain the steps: 1.- words provider is connected to insert-text (after) 2.- smart indentation is connected to insert-text (after) too. 3.- The user writes \n 4.- words provider handle the event on: on_insert_text_after_cb. All ok 5.- smart indentation handle the insert-text too and modify the buffer text to add the new indentation. This insertion emits a new insert-text signal 6.- words provider handle the event on: on_insert_text_after_cb again but the iterator is invalid now Perhaps the problem is in smart-indenter but I don't know how I can fix it.
If you ever modify the buffer in text-insert or delete-range, you _must_ revalidate the iters. So, the only thing you should need to do, is to make sure to revalidate the iter in your insert callback. The only problem here is that you will need to be nice towards other parties that might use these signals, so make sure to revalidate the iter to where that text was inserted.