[gspell] Entry: explain more in-depth why input-hints are not taken into account

[Sébastien Wilmet <swilmet src gnome org>]

commit 697a3c86b72e11716b463e80f5bf63e4459c7f6a
Author: Sébastien Wilmet <swilmet gnome org>
Date:   Fri Dec 23 18:24:12 2016 +0100

    Entry: explain more in-depth why input-hints are not taken into account
    
    input-hints are great for input methods, but for GspellEntry I don't see
    how it could be used conveniently.

 gspell/gspell-entry.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)
---
diff --git a/gspell/gspell-entry.c b/gspell/gspell-entry.c
index d9bd2b1..5098f97 100644
--- a/gspell/gspell-entry.c
+++ b/gspell/gspell-entry.c
@@ -99,6 +99,19 @@ inline_spell_checking_is_enabled (GspellEntry *gspell_entry)
         * other types of spell checking, for example based on GspellNavigator
         * to check an entire form or check a list of forms, even though such
         * feature is probably rare).
+        *
+        * In other words, it might be desirable to set
+        * GTK_INPUT_HINT_SPELLCHECK but keeping the inline spell checking of
+        * GspellEntry disabled. But when the inline spell checker of
+        * GspellEntry is enabled, it is normally always desirable to set
+        * GTK_INPUT_HINT_SPELLCHECK, which can be seen as duplicated state, but
+        * it is not, because if the GspellEntry:inline-spell-checking property
+        * is removed, another boolean property would be needed to tell
+        * GspellEntry whether it needs to bind the input-hints settings to its
+        * inline spell checker.
+        *
+        * Anyway, the mere fact of calling gspell_entry_get_from_gtk_entry()
+        * should not have unexpected side effects.
         */
 
        return (gspell_entry->inline_spell_checking &&