Merged in changes from CVS trunk.

Patches applied:

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-226
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-227
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-228
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-229
   Remove TeX output files from the archive


git-archimport-id: lorentey@elte.hu--2004/emacs--multi-tty--0--patch-146

2 files changed, 14 insertions, 2 deletions

diff --git a/src/ChangeLog b/src/ChangeLog
index 702f3be6046..babc20c57c5 100644
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,3 +1,8 @@
+2004-04-18  Jason Rumney  <jasonr@gnu.org>
+
+        * w32select.c (Fw32_set_clipboard_data): Get sequence number
+        after closing the clipboard.
+
 2004-04-16  Luc Teirlinck  <teirllm@auburn.edu>
 
         * buffer.c (Fbuffer_base_buffer): Doc fix.
diff --git a/src/w32select.c b/src/w32select.c
index 940cce35772..0c8849c7be6 100644
--- a/src/w32select.c
+++ b/src/w32select.c
@@ -259,11 +259,18 @@ DEFUN ("w32-set-clipboard-data", Fw32_set_clipboard_data,
 
   ok = EmptyClipboard () && SetClipboardData (CF_TEXT, htext);
 
+  CloseClipboard ();
+
+  /* Common sense says to read the sequence number inside the
+     OpenClipboard/ CloseClipboard block to avoid race conditions
+     where another app puts something on the clipboard straight after
+     us. But experience suggests that the sequence number from the
+     SetClipboardData is not allocated until we close the clipboard!
+     Since clipboard operations are normally user-driven, the race
+     condition is probably not going to really happen.  */
   if (clipboard_sequence_fn)
     last_clipboard_sequence_number = clipboard_sequence_fn ();
 
-  CloseClipboard ();
-
   if (ok) goto done;
 
  error: