GNOME Bugzilla – Bug 491207
gtk_text_buffer_delete_interactive() robustness against custom ::delete
Last modified: 2007-10-28 22:30:49 UTC
Say that you had a text buffer, and hooked up a ::insert-text handler so
that for every a typed in the buffer, you inserted a non-editable
b after it.
(Saby thabt you habd ab text buffer abd ..)
And then you wanted to hook up a ::delete-range handler so that when
an a was deleted, you deleted the b.
Right now, what happens is that this confuses the logic in delete_interactive()
Say the user deletes the range:
[Saby] that you
First ::delete-range is called for [Sa]. The ::delete-range handler
deletes the text, and the following b, so the next segment to process
is [y]. But delete interactive is hardcoded to think that after it's
called ::delete-range, the next segment is not-editable (it's assuming
that ::delete-range doesn't affect the alternation of editable and
I'll attach a patch to fix this by simply requerying for the editable
status after each call to ::delete-range.
Created attachment 98052 [details] [review]
Patch fixing the problem
Committing immediately. If you are reading this, and actually were
going to review the patch, you can still do so!
2007-10-28 Owen Taylor <email@example.com>
* gtk/gtktextbuffer.c (gtk_text_buffer_delete_interactive): Allow
the ::delete-range handler to delete text after the text it was
explicitly asked to delete without confusing us as to whether
we're currently on an editable or not-editable segment.