get-selection-timestamp.

Hi, At the moment, get-selection-timestamp behaves like so, after you've selected a region and clicked Edit -> Copy within XEmacs; (get-selection-timestamp 'CLIPBOARD) => #<INTERNAL OBJECT (XEmacs bug?) (opaque, size=4) 0x8a68320> Fget_selection_timestamp is called several times from C, and the thirty-two bit integer value is directly compared to non-XEmacs data--cf. select-gtk.c:161 temp_obj = Fget_selection_timestamp (selection_symbol); if (NILP (temp_obj)) { /* We don't appear to have the selection. */ gtk_decline_selection_request (selection_data); goto DONE_LABEL; } local_selection_time = * (guint32 *) XOPAQUE_DATA (temp_obj); if (time_stamp != GDK_CURRENT_TIME && local_selection_time > time_stamp) { /* Someone asked for the selection, and we have one, but not the one they're looking for. */ gtk_decline_selection_request (selection_data); goto DONE_LABEL; } Elsewhere, within select.el, thirty-two bit integers--such are X11 timestamps--are encoded as (high-sixteen-bits . low-sixteen-bits). If get-selection-timestamp returned data in this format, it could usefully be used to pass across selection timestamp data to other apps, without the succeeding-but-causing-an-XEmacs-error that it does at the moment. I propose reworking get-selection-timestamp to return such a cons, and putting in place an alternative function on the C level, to be called from such contexts like the select-gtk.c extract above. Does anyone have any conceptual objections to this? Best regards, - Aidan -- “Ah come on now Ted, a Volkswagen with a mind of its own, driving all over the place and going mad, if that’s not scary I don’t know what is.”