I don't agree with this comment.

1) The 'detail' field also contains a string, one of the following: "NotifyAncestor", "NotifyNonlinearVirtual",...

2) When an event is received, the 'detail' and 'user_data' fields are de facto mixed up. Indeed, the "%d" field contains "the detail or user_data field from the event".

This information comes form the documentation I cited, http://www.tcl.tk/man/tcl8.5/TkCmd/bind.htm#M24 :

* The "%d" field contains "the detail or user_data field from the event".
* They are both strings:
* "the %d is replaced by a string identifying the detail"
* "For virtual events, the string will be whatever value is stored in the user_data field when the event was created (typically with event generate), or the empty string if the field is NULL"

From the document cited in msg165234 (http://www.tcl.tk/man/tcl8.5/TkCmd/event.htm#M16), my understanding is:

* For virtual events, the "data" string parameter given to "event generate" will be stored in the "user_data field" for the event. This string will then be available from the event through the "%d" substitution.

* For events "Enter", "Leave", "FocusIn" and "FocusOut", the "detail" field will store a string among "NotifyAncestor", etc. This string will then be available from the event through the "%d" substitution.

So, from the point of view of the guy who receives the event, the "%d" field can EITHER be a "detail" string like "NotifyAncestor" if event was "Enter"/"Leave"/"FocusIn"/"FocusOut" OR a "user_data" string in the case of a virtual event. It seems sensible that the Python interface provides both names. As a consequence, I think the patch should read:

+                # value passed to the data option is not a widget, take it
+                # as the detail field
+                e.data = None
+                e.detail = d
+                e.user_data = d

I hope I understood the doc correctly.