emacs-x11: new clipboard size limitation?

emacs-x11: new clipboard size limitation?

[Markus Hoenicka]

Hi,

I'm running emacs-x11 24.3.1 on

CYGWIN_NT-5.1 sbhc123 1.7.25(0.270/5/3) 2013-08-31 20:39 i686 Cygwin

I used to be able to copy text from Emacs to Windows applications 
through the clipboard without practical size limitations. However, since 
my last Cygwin upgrade (which updated both Emacs and cygwin1.dll to the 
versions mentioned above) the clipboard seems to be limited in size. All 
I do is the following:

- open a file containing ASCII text, amounting to like three printed 
pages of text
- at the beginning of the buffer, press Ctrl-Space
- at the end of the buffer, press M-w
- switch to a Windows application (any that can handle unformatted text 
will do, use e.g. LibreOffice Writer)
- insert the text using Ctrl-v

stderr shows the following messages:

winClipboardWindowProc - timed out waiting for WIN_XEVENTS_NOTIFY_DATA
winClipboardFlushXEvents - SelectionNotify - X*TextPropertyToTextList 
returned: XConverterNotFound
winClipboardWindowProc - timed out waiting for 
WIN_XEVENTS_NOTIFY_TARGETS

On the receiving end, the message reads something like:

"Clipboard does not contain specified formatted data"

Trial and error tells me that I can copy 6104 characters without 
problems. Trying to copy 6105 or more characters triggers the error. 
I'll try and see if this number is constant across reboots. Copying 
within Emacs, i.e. by yanking the text into a different buffer, is not 
affected. The problem persists if I start Emacs using the -q flag.

regards,
Markus


-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: emacs-x11: new clipboard size limitation?

[Jon TURNEY]

On 02/12/2013 12:13, Markus Hoenicka wrote:
> I'm running emacs-x11 24.3.1 on
> 
> CYGWIN_NT-5.1 sbhc123 1.7.25(0.270/5/3) 2013-08-31 20:39 i686 Cygwin
> 
> I used to be able to copy text from Emacs to Windows applications through the
> clipboard without practical size limitations. However, since my last Cygwin
> upgrade (which updated both Emacs and cygwin1.dll to the versions mentioned
> above) the clipboard seems to be limited in size. All I do is the following:
> 
> - open a file containing ASCII text, amounting to like three printed pages of
> text
> - at the beginning of the buffer, press Ctrl-Space
> - at the end of the buffer, press M-w
> - switch to a Windows application (any that can handle unformatted text will
> do, use e.g. LibreOffice Writer)
> - insert the text using Ctrl-v
> 
> stderr shows the following messages:
> 
> winClipboardWindowProc - timed out waiting for WIN_XEVENTS_NOTIFY_DATA
> winClipboardFlushXEvents - SelectionNotify - X*TextPropertyToTextList
> returned: XConverterNotFound
> winClipboardWindowProc - timed out waiting for WIN_XEVENTS_NOTIFY_TARGETS
> 
> On the receiving end, the message reads something like:
> 
> "Clipboard does not contain specified formatted data"
> 
> Trial and error tells me that I can copy 6104 characters without problems.
> Trying to copy 6105 or more characters triggers the error. I'll try and see if
> this number is constant across reboots. Copying within Emacs, i.e. by yanking
> the text into a different buffer, is not affected. The problem persists if I
> start Emacs using the -q flag.

This looks like the same issue as reported in [1], so you might like to try
the snapshot from [2] and see if it improves things for you?

What you write does seem to support the theory that this is a regression in
select() in the cygwin DLL.  It might be useful if you could say what version
of the cygwin DLL you had when it was working correctly before you upgraded.

[1] http://cygwin.com/ml/cygwin-xfree/2013-10/msg00031.html
[2] http://cygwin.com/ml/cygwin-xfree/2013-11/msg00012.html

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: emacs-x11: new clipboard size limitation?

[Markus Hoenicka]

Around 2013-12-02 14:11, Jon TURNEY was heard to say:
> On 02/12/2013 12:13, Markus Hoenicka wrote:
>> I'm running emacs-x11 24.3.1 on
>> 
>> CYGWIN_NT-5.1 sbhc123 1.7.25(0.270/5/3) 2013-08-31 20:39 i686 Cygwin
>> 
>> I used to be able to copy text from Emacs to Windows applications 
>> through the
>> clipboard without practical size limitations. However, since my last 
>> Cygwin
>> upgrade (which updated both Emacs and cygwin1.dll to the versions 
>> mentioned
>> above) the clipboard seems to be limited in size. All I do is the 
>> following:
>> 
>> - open a file containing ASCII text, amounting to like three printed 
>> pages of
>> text
>> - at the beginning of the buffer, press Ctrl-Space
>> - at the end of the buffer, press M-w
>> - switch to a Windows application (any that can handle unformatted 
>> text will
>> do, use e.g. LibreOffice Writer)
>> - insert the text using Ctrl-v
>> 
>> stderr shows the following messages:
>> 
>> winClipboardWindowProc - timed out waiting for WIN_XEVENTS_NOTIFY_DATA
>> winClipboardFlushXEvents - SelectionNotify - X*TextPropertyToTextList
>> returned: XConverterNotFound
>> winClipboardWindowProc - timed out waiting for 
>> WIN_XEVENTS_NOTIFY_TARGETS
>> 
>> On the receiving end, the message reads something like:
>> 
>> "Clipboard does not contain specified formatted data"
>> 
>> Trial and error tells me that I can copy 6104 characters without 
>> problems.
>> Trying to copy 6105 or more characters triggers the error. I'll try 
>> and see if
>> this number is constant across reboots. Copying within Emacs, i.e. by 
>> yanking
>> the text into a different buffer, is not affected. The problem 
>> persists if I
>> start Emacs using the -q flag.
> 
> This looks like the same issue as reported in [1], so you might like to 
> try
> the snapshot from [2] and see if it improves things for you?
> 
> What you write does seem to support the theory that this is a 
> regression in
> select() in the cygwin DLL.  It might be useful if you could say what 
> version
> of the cygwin DLL you had when it was working correctly before you 
> upgraded.
> 
> [1] http://cygwin.com/ml/cygwin-xfree/2013-10/msg00031.html
> [2] http://cygwin.com/ml/cygwin-xfree/2013-11/msg00012.html

Hi,

thanks for your quick reply. Yes, the XWin.exe snapshot seems to fix the 
problem for me. I tried a few copy+paste cycles with the amount of text 
that I usually shuffle around, and there were no errors or warnings.

As for the Cygwin DLL version before upgrading, I can only guess. I 
update only when need arises, so it may well have been 6 months or so 
since the last update. I'm sorry that I can't be more specific here.

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: emacs-x11: new clipboard size limitation?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2484 bytes --]

On Dec  2 13:11, Jon TURNEY wrote:
> On 02/12/2013 12:13, Markus Hoenicka wrote:
> > I'm running emacs-x11 24.3.1 on
> > 
> > CYGWIN_NT-5.1 sbhc123 1.7.25(0.270/5/3) 2013-08-31 20:39 i686 Cygwin
> > 
> > I used to be able to copy text from Emacs to Windows applications through the
> > clipboard without practical size limitations. However, since my last Cygwin
> > upgrade (which updated both Emacs and cygwin1.dll to the versions mentioned
> > above) the clipboard seems to be limited in size. All I do is the following:
> > 
> > - open a file containing ASCII text, amounting to like three printed pages of
> > text
> > - at the beginning of the buffer, press Ctrl-Space
> > - at the end of the buffer, press M-w
> > - switch to a Windows application (any that can handle unformatted text will
> > do, use e.g. LibreOffice Writer)
> > - insert the text using Ctrl-v
> > 
> > stderr shows the following messages:
> > 
> > winClipboardWindowProc - timed out waiting for WIN_XEVENTS_NOTIFY_DATA
> > winClipboardFlushXEvents - SelectionNotify - X*TextPropertyToTextList
> > returned: XConverterNotFound
> > winClipboardWindowProc - timed out waiting for WIN_XEVENTS_NOTIFY_TARGETS
> > 
> > On the receiving end, the message reads something like:
> > 
> > "Clipboard does not contain specified formatted data"
> > 
> > Trial and error tells me that I can copy 6104 characters without problems.
> > Trying to copy 6105 or more characters triggers the error. I'll try and see if
> > this number is constant across reboots. Copying within Emacs, i.e. by yanking
> > the text into a different buffer, is not affected. The problem persists if I
> > start Emacs using the -q flag.
> 
> This looks like the same issue as reported in [1], so you might like to try
> the snapshot from [2] and see if it improves things for you?
> 
> What you write does seem to support the theory that this is a regression in
> select() in the cygwin DLL.  It might be useful if you could say what version
> of the cygwin DLL you had when it was working correctly before you upgraded.
> 
> [1] http://cygwin.com/ml/cygwin-xfree/2013-10/msg00031.html
> [2] http://cygwin.com/ml/cygwin-xfree/2013-11/msg00012.html

Are you sure this is a select problem?  If so, can you create an STC,
perhaps?


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: emacs-x11: new clipboard size limitation?

[Jon TURNEY]

On 02/12/2013 14:17, Corinna Vinschen wrote:
> On Dec  2 13:11, Jon TURNEY wrote:
>> On 02/12/2013 12:13, Markus Hoenicka wrote:
>>> I'm running emacs-x11 24.3.1 on
>>>
>>> CYGWIN_NT-5.1 sbhc123 1.7.25(0.270/5/3) 2013-08-31 20:39 i686 Cygwin
>>>
>>> I used to be able to copy text from Emacs to Windows applications through the
>>> clipboard without practical size limitations. However, since my last Cygwin
>>> upgrade (which updated both Emacs and cygwin1.dll to the versions mentioned
>>> above) the clipboard seems to be limited in size. All I do is the following:
>>>
>>> - open a file containing ASCII text, amounting to like three printed pages of
>>> text
>>> - at the beginning of the buffer, press Ctrl-Space
>>> - at the end of the buffer, press M-w
>>> - switch to a Windows application (any that can handle unformatted text will
>>> do, use e.g. LibreOffice Writer)
>>> - insert the text using Ctrl-v
>>>
>>> stderr shows the following messages:
>>>
>>> winClipboardWindowProc - timed out waiting for WIN_XEVENTS_NOTIFY_DATA
>>> winClipboardFlushXEvents - SelectionNotify - X*TextPropertyToTextList
>>> returned: XConverterNotFound
>>> winClipboardWindowProc - timed out waiting for WIN_XEVENTS_NOTIFY_TARGETS
>>>
>>> On the receiving end, the message reads something like:
>>>
>>> "Clipboard does not contain specified formatted data"
>>>
>>> Trial and error tells me that I can copy 6104 characters without problems.
>>> Trying to copy 6105 or more characters triggers the error. I'll try and see if
>>> this number is constant across reboots. Copying within Emacs, i.e. by yanking
>>> the text into a different buffer, is not affected. The problem persists if I
>>> start Emacs using the -q flag.
>>
>> This looks like the same issue as reported in [1], so you might like to try
>> the snapshot from [2] and see if it improves things for you?
>>
>> What you write does seem to support the theory that this is a regression in
>> select() in the cygwin DLL.  It might be useful if you could say what version
>> of the cygwin DLL you had when it was working correctly before you upgraded.
>>
>> [1] http://cygwin.com/ml/cygwin-xfree/2013-10/msg00031.html
>> [2] http://cygwin.com/ml/cygwin-xfree/2013-11/msg00012.html
> 
> Are you sure this is a select problem?  If so, can you create an STC,
> perhaps?

"Only a madman is absolutely sure".  I'm afraid the best test case I have a
the moment is:

Install xorg-server-debuginfo
Start XWin -noclipboard -multiwindow
Start xwinclip under gdb, and place a breakpoint at wndproc.c:133, and run it
Start emacs-x11, open the Shakespeare text from [1] in a buffer
Open notepad
Copy and paste the text from the emacs buffer into notepad
The breakpoint is hit.  Notice that select() has returned 0, the read ready
fd_set is empty and the timeout hasn't expired. I claim that the read ready
fd_set should indicate that the X connection socket is ready.

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: emacs-x11: new clipboard size limitation?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1618 bytes --]

On Dec  2 14:56, Jon TURNEY wrote:
> On 02/12/2013 14:17, Corinna Vinschen wrote:
> > On Dec  2 13:11, Jon TURNEY wrote:
> >> What you write does seem to support the theory that this is a regression in
> >> select() in the cygwin DLL.  It might be useful if you could say what version
> >> of the cygwin DLL you had when it was working correctly before you upgraded.
> >>
> >> [1] http://cygwin.com/ml/cygwin-xfree/2013-10/msg00031.html
> >> [2] http://cygwin.com/ml/cygwin-xfree/2013-11/msg00012.html
> > 
> > Are you sure this is a select problem?  If so, can you create an STC,
> > perhaps?
> 
> "Only a madman is absolutely sure".  I'm afraid the best test case I have a
> the moment is:
> 
> Install xorg-server-debuginfo
> Start XWin -noclipboard -multiwindow
> Start xwinclip under gdb, and place a breakpoint at wndproc.c:133, and run it
> Start emacs-x11, open the Shakespeare text from [1] in a buffer
> Open notepad
> Copy and paste the text from the emacs buffer into notepad
> The breakpoint is hit.  Notice that select() has returned 0, the read ready
> fd_set is empty and the timeout hasn't expired. I claim that the read ready
> fd_set should indicate that the X connection socket is ready.

Well, that's not exactly an STC...

So, IIUC, you're saying that, in fact, select doesn't return too early,
rather it returns without setting the return value correctly.  You
expect it to return a value > 0, right?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: emacs-x11: new clipboard size limitation?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2505 bytes --]

On Dec  3 11:31, Corinna Vinschen wrote:
> On Dec  2 14:56, Jon TURNEY wrote:
> > On 02/12/2013 14:17, Corinna Vinschen wrote:
> > > On Dec  2 13:11, Jon TURNEY wrote:
> > >> What you write does seem to support the theory that this is a regression in
> > >> select() in the cygwin DLL.  It might be useful if you could say what version
> > >> of the cygwin DLL you had when it was working correctly before you upgraded.
> > >>
> > >> [1] http://cygwin.com/ml/cygwin-xfree/2013-10/msg00031.html
> > >> [2] http://cygwin.com/ml/cygwin-xfree/2013-11/msg00012.html
> > > 
> > > Are you sure this is a select problem?  If so, can you create an STC,
> > > perhaps?
> > 
> > "Only a madman is absolutely sure".  I'm afraid the best test case I have a
> > the moment is:
> > 
> > Install xorg-server-debuginfo
> > Start XWin -noclipboard -multiwindow
> > Start xwinclip under gdb, and place a breakpoint at wndproc.c:133, and run it
> > Start emacs-x11, open the Shakespeare text from [1] in a buffer
> > Open notepad
> > Copy and paste the text from the emacs buffer into notepad
> > The breakpoint is hit.  Notice that select() has returned 0, the read ready
> > fd_set is empty and the timeout hasn't expired. I claim that the read ready
> > fd_set should indicate that the X connection socket is ready.
> 
> Well, that's not exactly an STC...
> 
> So, IIUC, you're saying that, in fact, select doesn't return too early,
> rather it returns without setting the return value correctly.  You
> expect it to return a value > 0, right?

I don't see any bigger changes in select since Cygwin 1.7.19.  Only one
change since then, and that's only in 1.7.26, not in 1.7.25 as the OP
claimed using.  The change in 1.7.19 is only 64 bit related, changing an
unsigned to a size_t cast and a few debug printfs.  Only in 1.7.18 is a
little bit bigger change but it should only affect signal handling.

Talking about wndproc.c, it only checks iReturn for being < 0.  After
that, we don't really know which value it has, we only know that
FD_ISSET(iConnNumber, &fdsRead) returns 0.  The value of iReturn should
be printed in the debug output at line 133.

What kind of object is the iConnNumber descriptor?  Pipe?  Fifo?
Socket?  /dev/windows?  We really need a simple testcase without the 
X and emacs overhead...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: emacs-x11: new clipboard size limitation?

[Jon TURNEY]

On 03/12/2013 11:28, Corinna Vinschen wrote:
> On Dec  3 11:31, Corinna Vinschen wrote:
>> On Dec  2 14:56, Jon TURNEY wrote:
>>> On 02/12/2013 14:17, Corinna Vinschen wrote:
>>>> On Dec  2 13:11, Jon TURNEY wrote:
>>>>> What you write does seem to support the theory that this is a regression in
>>>>> select() in the cygwin DLL.  It might be useful if you could say what version
>>>>> of the cygwin DLL you had when it was working correctly before you upgraded.
>>>>>
>>>>> [1] http://cygwin.com/ml/cygwin-xfree/2013-10/msg00031.html
>>>>> [2] http://cygwin.com/ml/cygwin-xfree/2013-11/msg00012.html
>>>>
>>>> Are you sure this is a select problem?  If so, can you create an STC,
>>>> perhaps?
>>>
>>> "Only a madman is absolutely sure".  I'm afraid the best test case I have a
>>> the moment is:
>>>
>>> Install xorg-server-debuginfo
>>> Start XWin -noclipboard -multiwindow
>>> Start xwinclip under gdb, and place a breakpoint at wndproc.c:133, and run it
>>> Start emacs-x11, open the Shakespeare text from [1] in a buffer
>>> Open notepad
>>> Copy and paste the text from the emacs buffer into notepad
>>> The breakpoint is hit.  Notice that select() has returned 0, the read ready
>>> fd_set is empty and the timeout hasn't expired. I claim that the read ready
>>> fd_set should indicate that the X connection socket is ready.
>>
>> Well, that's not exactly an STC...
>>
>> So, IIUC, you're saying that, in fact, select doesn't return too early,
>> rather it returns without setting the return value correctly.  You
>> expect it to return a value > 0, right?

Yes, I'm expecting it to return 1 with a bit set in the fd_set.

I'm not sure what it means to return before the timeout expires with value 0.

> I don't see any bigger changes in select since Cygwin 1.7.19.  Only one
> change since then, and that's only in 1.7.26, not in 1.7.25 as the OP
> claimed using.  The change in 1.7.19 is only 64 bit related, changing an
> unsigned to a size_t cast and a few debug printfs.  Only in 1.7.18 is a
> little bit bigger change but it should only affect signal handling.

Okay, so I did what I should have done in the first place and tried bisecting
through cygwin DLL versions for the past 6 months and they all behave the same
way.

Tried bisecting through the X server versions for the past 6 months, and it
seems that this problem first appears in X server 1.14.3-2

(As an aside, it's probably relevant to the recent discussion, that I can't
find the thread for, about how many previous versions we should keep around
that it's not possible to do this bisection without 'Secret Knowledge' at the
moment)

This does contain a few clipboard changes, and in particular it changes the
way the messages get processed so we will return to the select() more often
(after each stage of the conversion operation), which it looks like it could
be incorrect sometimes, but I'd expect this to cause unneeded blocking
(waiting in select() for a message which has already been placed on the event
queue by XPending() rather than the observed behaviour.

Anyhow, I guess I need to look at this some more...

> Talking about wndproc.c, it only checks iReturn for being < 0.  After
> that, we don't really know which value it has, we only know that
> FD_ISSET(iConnNumber, &fdsRead) returns 0.  The value of iReturn should
> be printed in the debug output at line 133.

It's 0 when I inspect it with the debugger, but yes, I'll change that.

> What kind of object is the iConnNumber descriptor?  Pipe?  Fifo?
> Socket?  /dev/windows?  We really need a simple testcase without the 
> X and emacs overhead...

It's a socket connected to the X server.

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Please try newest snapshot (was Re: emacs-x11: new clipboard size limitation?)

[Christopher Faylor]

On Tue, Dec 03, 2013 at 04:56:27PM +0000, Jon TURNEY wrote:
>Tried bisecting through the X server versions for the past 6 months, and it
>seems that this problem first appears in X server 1.14.3-2
>
>(As an aside, it's probably relevant to the recent discussion, that I can't
>find the thread for, about how many previous versions we should keep around
>that it's not possible to do this bisection without 'Secret Knowledge' at the
>moment)
>
>This does contain a few clipboard changes, and in particular it changes the
>way the messages get processed so we will return to the select() more often
>(after each stage of the conversion operation), which it looks like it could
>be incorrect sometimes, but I'd expect this to cause unneeded blocking
>(waiting in select() for a message which has already been placed on the event
>queue by XPending() rather than the observed behaviour.
>
>Anyhow, I guess I need to look at this some more...
>
>> Talking about wndproc.c, it only checks iReturn for being < 0.  After
>> that, we don't really know which value it has, we only know that
>> FD_ISSET(iConnNumber, &fdsRead) returns 0.  The value of iReturn should
>> be printed in the debug output at line 133.
>
>It's 0 when I inspect it with the debugger, but yes, I'll change that.
>
>> What kind of object is the iConnNumber descriptor?  Pipe?  Fifo?
>> Socket?  /dev/windows?  We really need a simple testcase without the 
>> X and emacs overhead...
>
>It's a socket connected to the X server.

I added an ugly hack to work around this symptom in the latest cygwin.
It shouldn't have any big impact on anything but this particular
scenario but I would appreciate it if people downloaded today's snapshot
and verified that things are still working ok.

I plan on addressing the actual problem for Cygwin 1.7.28.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Please try newest snapshot (was Re: emacs-x11: new clipboard size limitation?)

[Markus Hoenicka]

Am 2013-12-03 22:10, schrieb Christopher Faylor:
> On Tue, Dec 03, 2013 at 04:56:27PM +0000, Jon TURNEY wrote:
>> Tried bisecting through the X server versions for the past 6 months, 
>> and it
>> seems that this problem first appears in X server 1.14.3-2
>> 
>> (As an aside, it's probably relevant to the recent discussion, that I 
>> can't
>> find the thread for, about how many previous versions we should keep 
>> around
>> that it's not possible to do this bisection without 'Secret Knowledge' 
>> at the
>> moment)
>> 
>> This does contain a few clipboard changes, and in particular it 
>> changes the
>> way the messages get processed so we will return to the select() more 
>> often
>> (after each stage of the conversion operation), which it looks like it 
>> could
>> be incorrect sometimes, but I'd expect this to cause unneeded blocking
>> (waiting in select() for a message which has already been placed on 
>> the event
>> queue by XPending() rather than the observed behaviour.
>> 
>> Anyhow, I guess I need to look at this some more...
>> 
>>> Talking about wndproc.c, it only checks iReturn for being < 0.  After
>>> that, we don't really know which value it has, we only know that
>>> FD_ISSET(iConnNumber, &fdsRead) returns 0.  The value of iReturn 
>>> should
>>> be printed in the debug output at line 133.
>> 
>> It's 0 when I inspect it with the debugger, but yes, I'll change that.
>> 
>>> What kind of object is the iConnNumber descriptor?  Pipe?  Fifo?
>>> Socket?  /dev/windows?  We really need a simple testcase without the
>>> X and emacs overhead...
>> 
>> It's a socket connected to the X server.
> 
> I added an ugly hack to work around this symptom in the latest cygwin.
> It shouldn't have any big impact on anything but this particular
> scenario but I would appreciate it if people downloaded today's 
> snapshot
> and verified that things are still working ok.
> 
> I plan on addressing the actual problem for Cygwin 1.7.28.
> 

Hi,

the nightly snapshot does not seem to do me any good with regard to the 
clipboard problem. I performed the following test, and I hope this is 
what you had in mind:

- make sure all Cygwin processes have terminated
- rename /bin/cygwin1.dll to /bin/cygwin1.dll.backup
- copy the nightly snapshot of 2013-12-04 to /bin and rename it 
cygwin1.dll
- rename /bin/XWin.exe (the test version mentioned by Jon) to 
/bin/XWin.exe.test
- rename /bin/XWin.exe.backup (the stock version that came with my last 
update) to /bin/XWin.exe

A quick test shows that trying to copy approx. two printed pages worth 
of ASCII text from an Emacs buffer to LibreOffice Writer still triggers 
the clipboard failure.

If I revert the changes above, i.e. reactivate the stock cygwin1.dll 
(1.7.25) and Jon's XWin test version, the clipboard works again.

regards,
Markus




-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Please try newest snapshot (was Re: emacs-x11: new clipboard size limitation?)

[Bengt Larsson]

Christopher Faylor wrote:
>
>I added an ugly hack to work around this symptom in the latest cygwin.
>It shouldn't have any big impact on anything but this particular
>scenario but I would appreciate it if people downloaded today's snapshot
>and verified that things are still working ok.
>
>I plan on addressing the actual problem for Cygwin 1.7.28.

Tested the 32 and 64 bit DLLs doing my usual stuff. I created some
scripts so I can volunteer to be DLL tester.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Please try newest snapshot (was Re: emacs-x11: new clipboard size limitation?)

[Jon TURNEY]

On 04/12/2013 08:09, Markus Hoenicka wrote:
> Am 2013-12-03 22:10, schrieb Christopher Faylor:
>> I added an ugly hack to work around this symptom in the latest cygwin.
>> It shouldn't have any big impact on anything but this particular
>> scenario but I would appreciate it if people downloaded today's snapshot
>> and verified that things are still working ok.
>>
>> I plan on addressing the actual problem for Cygwin 1.7.28.
> 
> the nightly snapshot does not seem to do me any good with regard to the
> clipboard problem. I performed the following test, and I hope this is what you
> had in mind:

There is also a bug in xwinclip which needs fixing for this test to work
reliably, but it was difficult to see what that was without this fix in the
cygwin DLL.

> - make sure all Cygwin processes have terminated
> - rename /bin/cygwin1.dll to /bin/cygwin1.dll.backup
> - copy the nightly snapshot of 2013-12-04 to /bin and rename it cygwin1.dll
> - rename /bin/XWin.exe (the test version mentioned by Jon) to /bin/XWin.exe.test
> - rename /bin/XWin.exe.backup (the stock version that came with my last
> update) to /bin/XWin.exe
> 
> A quick test shows that trying to copy approx. two printed pages worth of
> ASCII text from an Emacs buffer to LibreOffice Writer still triggers the
> clipboard failure.
> 
> If I revert the changes above, i.e. reactivate the stock cygwin1.dll (1.7.25)
> and Jon's XWin test version, the clipboard works again.

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Please try newest snapshot (was Re: emacs-x11: new clipboard size limitation?)

[Markus Hoenicka]

Around 2013-12-04 16:59 Jon TURNEY was heard to say:
> On 04/12/2013 08:09, Markus Hoenicka wrote:
>> Am 2013-12-03 22:10, schrieb Christopher Faylor:
>>> I added an ugly hack to work around this symptom in the latest 
>>> cygwin.
>>> It shouldn't have any big impact on anything but this particular
>>> scenario but I would appreciate it if people downloaded today's 
>>> snapshot
>>> and verified that things are still working ok.
>>> 
>>> I plan on addressing the actual problem for Cygwin 1.7.28.
>> 
>> the nightly snapshot does not seem to do me any good with regard to 
>> the
>> clipboard problem. I performed the following test, and I hope this is 
>> what you
>> had in mind:
> 
> There is also a bug in xwinclip which needs fixing for this test to 
> work
> reliably, but it was difficult to see what that was without this fix in 
> the
> cygwin DLL.
> 

I see. Let me know whenever it makes sense to do any further testing.

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Please try newest snapshot (was Re: emacs-x11: new clipboard size limitation?)

[Jon TURNEY]

On 04/12/2013 22:14, Markus Hoenicka wrote:
> Around 2013-12-04 16:59 Jon TURNEY was heard to say:
>> On 04/12/2013 08:09, Markus Hoenicka wrote:
>>> Am 2013-12-03 22:10, schrieb Christopher Faylor:
>>>> I added an ugly hack to work around this symptom in the latest cygwin.
>>>> It shouldn't have any big impact on anything but this particular
>>>> scenario but I would appreciate it if people downloaded today's snapshot
>>>> and verified that things are still working ok.
>>>>
>>>> I plan on addressing the actual problem for Cygwin 1.7.28.
>>>
>>> the nightly snapshot does not seem to do me any good with regard to the
>>> clipboard problem. I performed the following test, and I hope this is what you
>>> had in mind:
>>
>> There is also a bug in xwinclip which needs fixing for this test to work
>> reliably, but it was difficult to see what that was without this fix in the
>> cygwin DLL.
> 
> I see. Let me know whenever it makes sense to do any further testing.

I just uploaded X server 1.14.4-2, which should have this fixed.

(With cygwin DLL prior to the nightly snapshot of 2013-12-04, you may see
"Spurious wake" recorded in XWin's log, but pasting should still work correctly)

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Please try newest snapshot (was Re: emacs-x11: new clipboard size limitation?)

[Markus Hoenicka]

At 2013-12-10 21:40 quoth Jon TURNEY:
> On 04/12/2013 22:14, Markus Hoenicka wrote:
>> Around 2013-12-04 16:59 Jon TURNEY was heard to say:
>>> On 04/12/2013 08:09, Markus Hoenicka wrote:
>>>> Am 2013-12-03 22:10, schrieb Christopher Faylor:
>>>>> I added an ugly hack to work around this symptom in the latest 
>>>>> cygwin.
>>>>> It shouldn't have any big impact on anything but this particular
>>>>> scenario but I would appreciate it if people downloaded today's 
>>>>> snapshot
>>>>> and verified that things are still working ok.
>>>>> 
>>>>> I plan on addressing the actual problem for Cygwin 1.7.28.
>>>> 
>>>> the nightly snapshot does not seem to do me any good with regard to 
>>>> the
>>>> clipboard problem. I performed the following test, and I hope this 
>>>> is what you
>>>> had in mind:
>>> 
>>> There is also a bug in xwinclip which needs fixing for this test to 
>>> work
>>> reliably, but it was difficult to see what that was without this fix 
>>> in the
>>> cygwin DLL.
>> 
>> I see. Let me know whenever it makes sense to do any further testing.
> 
> I just uploaded X server 1.14.4-2, which should have this fixed.
> 
> (With cygwin DLL prior to the nightly snapshot of 2013-12-04, you may 
> see
> "Spurious wake" recorded in XWin's log, but pasting should still work 
> correctly)
> 

I'm away from my Windows box at work, but I'll make sure to test your 
new version when I'll be back early next week.

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Please try newest snapshot (was Re: emacs-x11: new clipboard size limitation?)

[Markus Hoenicka]

Am 2013-12-10 21:40, schrieb Jon TURNEY:
> On 04/12/2013 22:14, Markus Hoenicka wrote:
>> Around 2013-12-04 16:59 Jon TURNEY was heard to say:
>>> On 04/12/2013 08:09, Markus Hoenicka wrote:
>>>> Am 2013-12-03 22:10, schrieb Christopher Faylor:
>>>>> I added an ugly hack to work around this symptom in the latest 
>>>>> cygwin.
>>>>> It shouldn't have any big impact on anything but this particular
>>>>> scenario but I would appreciate it if people downloaded today's 
>>>>> snapshot
>>>>> and verified that things are still working ok.
>>>>> 
>>>>> I plan on addressing the actual problem for Cygwin 1.7.28.
>>>> 
>>>> the nightly snapshot does not seem to do me any good with regard to 
>>>> the
>>>> clipboard problem. I performed the following test, and I hope this 
>>>> is what you
>>>> had in mind:
>>> 
>>> There is also a bug in xwinclip which needs fixing for this test to 
>>> work
>>> reliably, but it was difficult to see what that was without this fix 
>>> in the
>>> cygwin DLL.
>> 
>> I see. Let me know whenever it makes sense to do any further testing.
> 
> I just uploaded X server 1.14.4-2, which should have this fixed.
> 
> (With cygwin DLL prior to the nightly snapshot of 2013-12-04, you may 
> see
> "Spurious wake" recorded in XWin's log, but pasting should still work 
> correctly)
> 

Hi,

this is just to confirm that the problem appears to be fixed after I 
updated my installation today, using cygwin 1.7.27-2 and xorg-server 
1.14.4-2. Thanks to you and Christopher for making things work again.

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Please try newest snapshot (was Re: emacs-x11: new clipboard size limitation?)

[Christopher Faylor]

On Wed, Dec 18, 2013 at 01:10:40PM +0100, Markus Hoenicka wrote:
>Am 2013-12-10 21:40, schrieb Jon TURNEY:
>> On 04/12/2013 22:14, Markus Hoenicka wrote:
>>> Around 2013-12-04 16:59 Jon TURNEY was heard to say:
>>>> On 04/12/2013 08:09, Markus Hoenicka wrote:
>>>>> Am 2013-12-03 22:10, schrieb Christopher Faylor:
>>>>>> I added an ugly hack to work around this symptom in the latest 
>>>>>> cygwin.
>>>>>> It shouldn't have any big impact on anything but this particular
>>>>>> scenario but I would appreciate it if people downloaded today's 
>>>>>> snapshot
>>>>>> and verified that things are still working ok.
>>>>>> 
>>>>>> I plan on addressing the actual problem for Cygwin 1.7.28.
>>>>> 
>>>>> the nightly snapshot does not seem to do me any good with regard to 
>>>>> the
>>>>> clipboard problem. I performed the following test, and I hope this 
>>>>> is what you
>>>>> had in mind:
>>>> 
>>>> There is also a bug in xwinclip which needs fixing for this test to 
>>>> work
>>>> reliably, but it was difficult to see what that was without this fix 
>>>> in the
>>>> cygwin DLL.
>>> 
>>> I see. Let me know whenever it makes sense to do any further testing.
>> 
>> I just uploaded X server 1.14.4-2, which should have this fixed.
>> 
>> (With cygwin DLL prior to the nightly snapshot of 2013-12-04, you may 
>> see
>> "Spurious wake" recorded in XWin's log, but pasting should still work 
>> correctly)
>> 
>
>Hi,
>
>this is just to confirm that the problem appears to be fixed after I 
>updated my installation today, using cygwin 1.7.27-2 and xorg-server 
>1.14.4-2. Thanks to you and Christopher for making things work again.

Good to hear.  Thanks for letting us know.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple