GNOME Bugzilla – Bug 728916
Can't find "_" in the results
Last modified: 2015-02-16 08:41:31 UTC
devhelp-3.12.1-1.fc20.x86_64 1. Launch devhelp, and look for the _() macro as can be found here: https://developer.gnome.org/glib/stable/glib-I18N.html#gettext-macro 2. Type "_", remove it, type it again, remove it, "_" doesn't show up in the list of results 3. Type "gettext" and select one of the glib gettext wrappers such as "g_dcgettext" 4. Remove the search term, and type "_" 5. Result!
Created attachment 275491 [details] [review] Always look for exact match in other books The patch addresses the issue; which was actually a nasty corner case (very short search word with an exact hit in other books and lots of non-exact hits in current book). With the patch in we give priority to prefix-results and therefore also to an exact match which may be in other non-current-books. Still, maybe we should just simplify the thing and totally skip making a difference between current and other books; i.e. don't necessarily give priority to the current book in the search results. At the end, a user will likely search using a prefix, and libraries tend to use different prefixes... and also, since we visually mix the book/chapter list and the search results there is no more a clear indication of which the current book is... Fred, what do you think?
There is the case of having both GTK+ 2 and 3 docs; in that situation looking in the current book is useful. (that's the only one I found); but we could ignore that if we get documentation bundles (GTK+ 2 would be in a "compat" bundle, and wouldn't be searched unless active).
(In reply to comment #2) > There is the case of having both GTK+ 2 and 3 docs; in that situation looking > in the current book is useful. (that's the only one I found); but we could > ignore that if we get documentation bundles (GTK+ 2 would be in a "compat" > bundle, and wouldn't be searched unless active). Ah, true... gtk+2 and gtk+3... What about the patch, how does it look like?
Let's git this in 3.16.