summaryrefslogtreecommitdiff
path: root/src/util/string.vala
diff options
context:
space:
mode:
Diffstat (limited to 'src/util/string.vala')
-rw-r--r--src/util/string.vala14
1 files changed, 8 insertions, 6 deletions
diff --git a/src/util/string.vala b/src/util/string.vala
index bf7e605..89424d0 100644
--- a/src/util/string.vala
+++ b/src/util/string.vala
@@ -13,13 +13,13 @@ public inline bool is_string_empty(string? s) {
}
// utf8 case sensitive compare
-public int utf8_cs_compare(void *a, void *b) {
- return ((string) a).collate((string) b);
+public int utf8_cs_compare(string a, string b) {
+ return a.collate(b);
}
// utf8 case insensitive compare
-public int utf8_ci_compare(void *a, void *b) {
- return ((string) a).down().collate(((string) b).down());
+public int utf8_ci_compare(string a, string b) {
+ return a.down().collate(b.down());
}
// utf8 array to string
@@ -145,7 +145,7 @@ public string? prepare_input_text(string? text, PrepareInputTextOptions options,
// Using composed form rather than GLib's default (decomposed) as NFC is the preferred form in
// Linux and WWW. More importantly, Pango seems to have serious problems displaying decomposed
// forms of Korean language glyphs (and perhaps others). See:
- // http://trac.yorba.org/ticket/2952
+ // https://bugzilla.gnome.org/show_bug.cgi?id=716914
if ((options & PrepareInputTextOptions.NORMALIZE) != 0)
prepped = prepped.normalize(-1, NormalizeMode.NFC);
@@ -237,6 +237,8 @@ public string remove_diacritics(string istring) {
case UnicodeType.ENCLOSING_MARK:
// Ignore those
continue;
+ default:
+ break;
}
builder.append_unichar(ch);
}
@@ -255,7 +257,7 @@ public string to_hex_string(string str) {
// A note on the collated_* and precollated_* methods:
//
-// A bug report (http://trac.yorba.org/ticket/3152) indicated that two different Hirigana characters
+// A bug report (https://bugzilla.gnome.org/show_bug.cgi?id=717135) indicated that two different Hirigana characters
// as Tag names would trigger an assertion. Investigation showed that the characters' collation
// keys computed as equal when the locale was set to anything but the default locale (C) or
// Japanese. A related bug was that another hash table was using str_equal, which does not use