bug#4070: 23.1; ns: cut buffers don't work with --daemon

bug#4070: 23.1; ns: cut buffers don't work with --daemon

[Dan Ports]

I'm using the Aqua (ns) port interface on OS X. After starting emacs
with --daemon and firing up an emacs client, it's unable to access the
cut buffers, causing killing/yanking to fail.

Specifically, ns-store-cut-buffer-internal fails silently, and
ns-get-cut-buffer-internal fails with the message "empty or
unsupported pasteboard type".

I'm guessing that some part of the ns interface isn't being
initialized properly when started headless, and presumably it's part
of the C code given that ns-{get/set}-cut-buffer-internal fail. But
this is already straining at the limits of my knowledge of emacs
internals.

In GNU Emacs 23.1.1 (i386-apple-darwin9.7.0, NS apple-appkit-949.46)
 of 2009-08-05 on ambulatory-clam.local
Windowing system distributor `Apple', version 10.3.949 configured using `configure  '--prefix=/opt/local' '--with-ns' 'CC=/usr/bin/gcc-4.0' 'CFLAGS=-O2' 'LDFLAGS=-L/opt/local/lib' 'CPPFLAGS=-I/opt/local/include' 'CPP=/usr/bin/cpp-4.0''

bug#4070: 23.1; ns: cut buffers don't work with --daemon

[Adrian Robert]

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4070

I can't reproduce it, starting .../Emacs --daemon and then  
running .../emacsclient -c foo.bar

Can you post your exact steps to reproduce?  Also, could you try  
doing the build with just "./configure --with-ns"?  I'm not sure of  
the effect of all the extra arguments you are giving.

bug#4070: 23.1; ns: cut buffers don't work with --daemon

[Dan Ports]

On Fri, Sep 18, 2009 at 06:31:18PM -0400, Adrian Robert wrote:
> Can you post your exact steps to reproduce?  Also, could you try  
> doing the build with just "./configure --with-ns"?  I'm not sure of  
> the effect of all the extra arguments you are giving.

So, I just experimented with it some more to get you the exact steps to
reproduce. Along the way I realized that the problem is apparently
something different.

I'll provide the steps to reproduce below, but first the insight I just
had: everything seems to work perfectly fine unless I'm launching Emacs
from a shell inside GNU screen. It seems to work fine launched from a
shell in Apple's Terminal or a rxvt in X11, but not when running
screen. This is strange. I do not know why this is.

It doesn't actually have anything to do with daemon mode after all, as
far as I can tell -- I just thought it did before because I launched
Emacs --daemon from my shell whereas I opened Emacs.app from the GUI.

I will experiment with this a bit more but I'm still rather confused.

For the record, the steps to reproduce (not that I expect you'll find
anything about them especially surprising). This is with a fresh build
of emacs-23.1 with only --with-ns
  1) ./nextstep/Emacs.app/Contents/MacOS/Emacs <file>
  2) set mark and copy some text with M-w
  3) try to yank wih C-y; get message "empty or unsupported pasteboard
     type"
  4) show the clipboard (Edit: Show Clipboard in the Finder); notice
     that the clipboard contents weren't set by Emacs

To poke the internals some more:
  5) eval (ns-set-cut-buffer-internal 'PRIMARY "test"); no error but
     clipboard contents don't change (should be replaced with "test")
  6) eval (ns-get-cut-buffer-internal 'PRIMARY); get "empty or
     unsupported pasteboard type error"

 Dan

bug#4070: 23.1; ns: cut buffers don't work with --daemon

[Adrian Robert]

> I'll provide the steps to reproduce below, but first the insight I  
> just
> had: everything seems to work perfectly fine unless I'm launching  
> Emacs
> from a shell inside GNU screen. It seems to work fine launched from a

Hi,

Thanks for the further info.  What is "GNU screen"?

(It seems that x-open-connection in nsfns.m is not being called,  
which in turn means ns-initialize-window-system in lisp/term/ns- 
win.el is not called, but I'm not sure how that could be.  If you hit  
M-x ns-service- <tab for completion> do you get a list of services?)

bug#4070: 23.1; ns: cut buffers don't work with --daemon

[Dan Ports]

On Sat, Sep 19, 2009 at 07:36:32AM -0400, Adrian Robert wrote:
> Thanks for the further info.  What is "GNU screen"?

http://www.gnu.org/software/screen/

> (It seems that x-open-connection in nsfns.m is not being called,  
> which in turn means ns-initialize-window-system in lisp/term/ns- 
> win.el is not called, but I'm not sure how that could be.  If you hit  
> M-x ns-service- <tab for completion> do you get a list of services?)

Nope, no completions for ns-service-*.

Still at a loss for what's going on. I'm guessing that something about
the environment is different when run in screen -- maybe an environment
variable or the pty or something. I'll play around with it some
tomorrow and see what I can figure out.

Dan

bug#4070: 23.1; ns: cut buffers don't work with --daemon

[Adrian Robert]

On Sep 20, 2009, at 12:57 AM, Dan Ports wrote:

> On Sat, Sep 19, 2009 at 07:36:32AM -0400, Adrian Robert wrote:
>> Thanks for the further info.  What is "GNU screen"?
>
> http://www.gnu.org/software/screen/
>
>> (It seems that x-open-connection in nsfns.m is not being called,
>> which in turn means ns-initialize-window-system in lisp/term/ns-
>> win.el is not called, but I'm not sure how that could be.  If you hit
>> M-x ns-service- <tab for completion> do you get a list of services?)
>
> Nope, no completions for ns-service-*.
>
> Still at a loss for what's going on. I'm guessing that something about
> the environment is different when run in screen -- maybe an  
> environment
> variable or the pty or something. I'll play around with it some
> tomorrow and see what I can figure out.

I compiled and ran screen in the build directory like this "./ 
screen", then tried to run /Applications/.../Emacs -Q and did not see  
the phenomena you describe.  So hopefully you'll be able to find  
something.  One thing you should check is whether ns_term_init() is  
being called..

bug#4070: 23.1; ns: cut buffers don't work with --daemon

[Dan Ports]

So it has been a while since I replied to this one. I have been pretty
busy lately and fixing it has not been a high priority since an obvious
workaround now exists: don't start Emacs in screen. :-)

But here is what I found since I more or less gave up on it:

The problem seems to be that [NSPasteboard generalPasteboard] returns
nil. I wasn't able to come up with any reason this should ever happen.
I did find the following thread relating to a similar problem with
MacVim, but it doesn't look like thy found a solution either:
http://markmail.org/message/6epymamtdw27uzgy

I also noticed that this has also been reported as a bug in MacPorts
four years ago, so I'll post a link to this ticket over there.

http://trac.macports.org/ticket/6495

Dan

bug#4070: 23.1; ns: cut buffers don't work with --daemon

[Dan Ports]

On Fri, Nov 27, 2009 at 08:17:31PM -0500, Dan Ports wrote:
> So it has been a while since I replied to this one. I have been pretty
> busy lately and fixing it has not been a high priority since an obvious
> workaround now exists: don't start Emacs in screen. :-)

It has now been even longer since I've thought about this bug at all,
but an insight occurred to me today and I believe I now know what's
going on.

> The problem seems to be that [NSPasteboard generalPasteboard] returns
> nil. I wasn't able to come up with any reason this should ever happen.

A fine reason for this to happen would be if Emacs was unable to
communicate with the pasteboard server because they were in different
Mach bootstrap contexts. Apparently in 10.5 and prior, screen moved
itself from the per-session namespace to the enclosing per-user
namespace in order to persist across GUI sessions. This breaks its
ability to communicate with the pasteboard server.

Apparently in 10.6 the distinction between per-user and per-session
namespaces is gone (unfortunately I can't find many details of what
exactly changed, but that much I've been able to glean) so all of this
is moot. Indeed, since my first bug report I've upgraded to 10.6 and I
believe I'm no longer able to reproduce it.

Isn't it nice when a problem magically goes away?

Dan

-- 
Dan R. K. Ports              MIT CSAIL                http://drkp.net/

bug#4070: 23.1; ns: cut buffers don't work with --daemon

[Adrian Robert]

>> The problem seems to be that [NSPasteboard generalPasteboard] returns
>> nil. I wasn't able to come up with any reason this should ever happen.
>
> A fine reason for this to happen would be if Emacs was unable to
> communicate with the pasteboard server because they were in different
> Mach bootstrap contexts. Apparently in 10.5 and prior, screen moved
> itself from the per-session namespace to the enclosing per-user
> namespace in order to persist across GUI sessions. This breaks its
> ability to communicate with the pasteboard server.

That really sounds like an impressive hack on Screen's part, but I
guess if the API is there...


> Apparently in 10.6 the distinction between per-user and per-session
> namespaces is gone (unfortunately I can't find many details of what
> exactly changed, but that much I've been able to glean) so all of this
> is moot. Indeed, since my first bug report I've upgraded to 10.6 and I
> believe I'm no longer able to reproduce it.
>
> Isn't it nice when a problem magically goes away?

Well there are still quite a lot of 10.4 systems around, let alone
10.5.  But now that we know what the problem is it might be possible
to check on startup and generate a warning, and/or work-around to at
least not break within-emacs pasting.


-Adrian

bug#4070: 23.1; ns: cut buffers don't work with --daemon

[Dan Ports]

On Wed, Jan 20, 2010 at 10:24:38AM -0500, Adrian Robert wrote:
> That really sounds like an impressive hack on Screen's part, but I
> guess if the API is there...

Even worse! It's an undocumented launchd private API that Apple has
patched screen to use, pulling in a private header file from the
launchd source. I haven't found any information about it at all, and
I'm not even sure what exactly it's doing under 10.6.

(This came up while I was hunting for an unrelated bug that turned out
to also involve launchd and screen.)

Suffice it to say I wasn't too pleased to discover all this!

> Well there are still quite a lot of 10.4 systems around, let alone
> 10.5.  But now that we know what the problem is it might be possible
> to check on startup and generate a warning, and/or work-around to at
> least not break within-emacs pasting.

True. I'd consider checking if generalPasteboard returns nil and, if
so, printing an error about being unable to contact the pasteboard
server. 

I guess another way this could come up would be if someone started
emacs over ssh, not that starting a Quartz version of emacs over ssh is
really a reasonable thing to do.

Dan

-- 
Dan R. K. Ports              MIT CSAIL                http://drkp.net/

bug#4070: 23.1; ns: cut buffers don't work with --daemon

[Glenn Morris]

Version: 24.1

Support for cut buffers was removed altogether in Emacs 24.1.