RE: address@hidden: Lingering input pending withmotifmenu bar]

[Drew Adams]

        Because the exact list of events that are user-initiated
        might change (e.g. over releases), I wonder if it would be
        worth defining `user-event' as a type (category) of events
        and `user-event-p' as its test. Then, any code that deals
        with this would use that, and the exact set of user events
        would only be updated in one place.

    I don't understand how this would be used or what problem it is meant
    to solve.

It was just a thought - half-baked, no, hardly baked at all.

If user events are not easily distinguished from other, system-generated (?)
events, then code that wants to handle only user events needs to do the
filtering, event type by event type, to get only the events it wants to
handle. I'm guessing that much (most?) library code that handles events
wants to ignore all events not initiated by users.

The idea would be to have a simple test that code could use to tell whether
an event or an event type was user-initiated or not. Then, instead of
testing for multiple user event types, it could test an event with just
`user-event-p'. More generally, perhaps organize event types into sets
(categories) or, to put it another way, have a hierarchy of event types - at
least `user-event', from which all user event types would "inherit" (in some
way).

People who know more about events can speak to whether something like this
might actually be useful or not - I don't know.