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.”