Re: a little feedback on Cocoa Emacs.app

[Dan Nicolaescu <dann@ics.uci.edu>]

Ken Raeburn <raeburn@gnu.org> writes:

  > On Aug 4, 2008, at 13:04, Dan Nicolaescu wrote:
  > > Ken Raeburn <raeburn@gnu.org> writes:
  > >
  > >> A variation I'd be more interested in, though, might be the ability
  > >> to
  > >> run window-less.  Much like some Mac apps will let you close the last
  > >> window, but keep running, and let you open new windows (or quit)
  > >> through the menus that are displayed even without any open windows.
  > >> I
  > >> don't know if there's a good analog for this behavior for X11 and
  > >> Windows, though, so I'm not going to hold my breath.
  > >
  > > This behavior has been on the wish list for X11 for a while...  It
  > > might
  > > not even be that hard to implement, but nobody has volunteered to do
  > > it
  > > so far.
  > 
  > Are there specific ideas for how to keep talking to Emacs in that case
  > other than emacsclient or gnuclient to tell it to run make-frame, or
  > is that the way?  

IMHO emacsclient should be the way.
It could work like this: 
emacs --daemon
then use "emacsclient" to create window system frames, and "emacsclient -t"
to create terminal frames.
(There is a functionally equivalent workaround for the missing --daemon
functionality that people are using now: start "emacs -nw -fserver-start" 
in a "screen" session, and then suspend the "screen" session)
Maybe at some point emacsclient should be folded in emacs.

  > (Which reminds me... my old usage pattern for Emacs
  > used to be to run Emacs on the local X display while in front of the
  > machine, and tell it to invoke make-frame-on-display over ssh when
  > logged in remotely.  One Emacs process, one long-lived Gnus session,
  > etc.  I'd really like to be able to do something like that now, but
  > with the local display on my Mac using the NS support, which means
  > supporting both X and NS in one executable, and in one process....  

Both NS and X are not supported in one executable, never heard of anyone
planning to support that.
You can use terminal frames now when logged in remotely (via emacsclient
-t), in a 256 color terminal they work pretty well.

  > I also tended to have -- on the local display -- a minibuffer-only
  > frame, and zero or more minibuffer-less editing frames, so I could
  > certainly have no editing frames open at times, though there was
  > always the minibuffer at least.)

Unfortunately terminal frames won't work very well in this setup... 

Hope this helps.