Modify Entity Suggestion support and Add Profile Suggest support

chrome/common/autocomplete_match_type.h

Index: chrome/common/autocomplete_match_type.h
diff --git a/chrome/common/autocomplete_match_type.h b/chrome/common/autocomplete_match_type.h
index 7255bf6993ae3aedd6d7f0daa6f2ceb573009df8..542c4716c7a519b459ea162c27ce04f3c24e95d2 100644
--- a/chrome/common/autocomplete_match_type.h
+++ b/chrome/common/autocomplete_match_type.h
@@ -11,22 +11,27 @@ struct AutocompleteMatchType {
   // Type of AutocompleteMatch. Typedef'ed in autocomplete_match.h. Defined here
   // to pass the type details back and forth between the browser and renderer.
   enum Type {
-    URL_WHAT_YOU_TYPED = 0,  // The input as a URL.
-    HISTORY_URL,             // A past page whose URL contains the input.
-    HISTORY_TITLE,           // A past page whose title contains the input.
-    HISTORY_BODY,            // A past page whose body contains the input.
-    HISTORY_KEYWORD,         // A past page whose keyword contains the input.
-    NAVSUGGEST,              // A suggested URL.
-    SEARCH_WHAT_YOU_TYPED,   // The input as a search query (with the default
-                             // engine).
-    SEARCH_HISTORY,          // A past search (with the default engine)
-                             // containing the input.
-    SEARCH_SUGGEST,          // A suggested search (with the default engine).
-    SEARCH_OTHER_ENGINE,     // A search with a non-default engine.
-    EXTENSION_APP,           // An Extension App with a title/url that contains
-                             // the input.
-    CONTACT,                 // One of the user's contacts.
-    BOOKMARK_TITLE,          // A bookmark whose title contains the input.
+    URL_WHAT_YOU_TYPED = 0,      // The input as a URL.

[Peter Kasting, 2013/11/05 23:36:58]

Why indent all these comments more?

[Anuj, 2013/11/06 00:18:28]

I was about to add SEARCH_SUGGEST_PERSONALIZED too :)

[Peter Kasting, 2013/11/06 00:34:26]

OK, assuming you do so in this CL.

[Anuj, 2013/12/09 08:24:56]

Done.

+    HISTORY_URL,                 // A past page whose URL contains the input.
+    HISTORY_TITLE,               // A past page whose title contains the input.
+    HISTORY_BODY,                // A past page whose body contains the input.
+    HISTORY_KEYWORD,             // A past page whose keyword contains the
+                                 // input.
+    NAVSUGGEST,                  // A suggested URL.
+    SEARCH_WHAT_YOU_TYPED,       // The input as a search query (with the
+                                 // default engine).
+    SEARCH_HISTORY,              // A past search (with the default engine)
+                                 // containing the input.
+    SEARCH_SUGGEST,              // A suggested search (with the default
+                                 // engine).
+    SEARCH_OTHER_ENGINE,         // A search with a non-default engine.
+    EXTENSION_APP,               // An Extension App with a title/url that
+                                 // contains the input.
+    CONTACT,                     // One of the user's contacts.
+    BOOKMARK_TITLE,              // A bookmark whose title contains the input.
+    SEARCH_SUGGEST_ENTITY,       // A suggested search for an entity.
+    SEARCH_SUGGEST_INFINITE,     // A suggested search to complete the tail of

[Peter Kasting, 2013/11/05 23:36:58]

Nit: Place these two after SEARCH_SUGGEST.  I am pretty sure this enum's values
don't need to be fixed.

However, you should also muck with omnibox_event.proto, and the order/values may
matter there.  Consult mpearson about this issue in general as he knows the
rules better than I do.

[Anuj, 2013/11/06 00:18:28]

My understanding of protos and logs is that you don't mess with the enum values.
(Always add new properties, never remove old, only mark obsolete.)

Also, these values also have a mapping in Clank codebase.

[Peter Kasting, 2013/11/06 00:34:26]

Which is why I said that the .proto file may have different rules.

However, this enum is not used directly in protobufs, but is translated in the
proto file, which is why regardless of the rules there, this enum should be
reordered as we add new values, to keep them in the ideal order.

Mark and I discussed this in the past and agreed (as far as I recall) that this
enum doesn't need to stay in the same order as the .proto file in principle.

I don't know what you mean by "mapping in Clank codebase".

[Anuj, 2013/12/09 08:24:56]

After consulting with clank team, it is okay to modify this enum. Done.

+                                 // the query.
     NUM_TYPES,
   };