[gtksourceview/gnome-3-20] SearchContext: Ensure occurrences_count is updated in an edge case



commit c6385a25d0b9f73c4eb6759ca5a8816087d81aa6
Author: Matthew Leeds <mleeds redhat com>
Date:   Thu Jun 23 10:38:49 2016 -0400

    SearchContext: Ensure occurrences_count is updated in an edge case
    
    When at_word_boundaries is set in the SearchSettings and an insertion
    occurs on a word boundary, the affected occurrence needs to be
    re-scanned. This commit changes remove_occurrences_in_range to
    properly adjust the given boundaries to accomplish this.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=767978

 gtksourceview/gtksourcesearchcontext.c |   26 +++++++++++++++-----------
 1 files changed, 15 insertions(+), 11 deletions(-)
---
diff --git a/gtksourceview/gtksourcesearchcontext.c b/gtksourceview/gtksourcesearchcontext.c
index 05ab598..dc8f5fa 100644
--- a/gtksourceview/gtksourcesearchcontext.c
+++ b/gtksourceview/gtksourcesearchcontext.c
@@ -200,13 +200,13 @@
  *
  * For non-regex searches, when there is an insertion or deletion in the buffer,
  * we don't need to re-scan all the buffer. If there is an unmodified match in
- * the neighborhood, no need to re-scan it. For a regex search, it is more
- * complicated. An insertion or deletion outside a match can modify a match
- * located in the neighborhood. Take for example the regex "(aa)+" with the
- * buffer contents "aaa". There is one occurrence: the first two letters. If we
- * insert an extra 'a' at the end of the buffer, the occurrence is modified to
- * take the next two letters. That's why the buffer is re-scanned entirely on
- * each insertion or deletion in the buffer.
+ * the neighborhood, no need to re-scan it (unless at_word_boundaries is set).
+ * For a regex search, it is more complicated. An insertion or deletion outside
+ * a match can modify a match located in the neighborhood. Take for example the
+ * regex "(aa)+" with the buffer contents "aaa". There is one occurrence: the
+ * first two letters. If we insert an extra 'a' at the end of the buffer, the
+ * occurrence is modified to take the next two letters. That's why the buffer
+ * is re-scanned entirely on each insertion or deletion in the buffer.
  *
  * For searching the matches, the easiest solution is to retrieve all the buffer
  * contents, and search the occurrences on this big string. But it takes a lot
@@ -1490,14 +1490,18 @@ remove_occurrences_in_range (GtkSourceSearchContext *search,
        GtkTextIter match_start;
        GtkTextIter match_end;
 
-       if (gtk_text_iter_has_tag (start, search->priv->found_tag) &&
-           !gtk_text_iter_starts_tag (start, search->priv->found_tag))
+       if ((gtk_text_iter_has_tag (start, search->priv->found_tag) &&
+            !gtk_text_iter_starts_tag (start, search->priv->found_tag)) ||
+           (gtk_source_search_settings_get_at_word_boundaries (search->priv->settings) &&
+            gtk_text_iter_ends_tag (start, search->priv->found_tag)))
        {
                gtk_text_iter_backward_to_tag_toggle (start, search->priv->found_tag);
        }
 
-       if (gtk_text_iter_has_tag (end, search->priv->found_tag) &&
-           !gtk_text_iter_starts_tag (end, search->priv->found_tag))
+       if ((gtk_text_iter_has_tag (end, search->priv->found_tag) &&
+            !gtk_text_iter_starts_tag (end, search->priv->found_tag)) ||
+           (gtk_source_search_settings_get_at_word_boundaries (search->priv->settings) &&
+            gtk_text_iter_starts_tag (end, search->priv->found_tag)))
        {
                gtk_text_iter_forward_to_tag_toggle (end, search->priv->found_tag);
        }


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]