Emacs come demone su OS X con sistema a finestre

Sto eseguendo gnu emacs 23.3.1 build cacao su OS X 10.6.
Ho aggiunto quanto segue a ~ / Library / LaunchAgents / gnu.emacs.daemon.plist in modo che avvii un demone e riavvii automaticamente emacs se lo uccido involontariamente.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" 
    "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> 
 <plist version="1.0">
  <dict> 
    <key>Label</key>
    <string>gnu.emacs.daemon</string>
    <key>ProgramArguments</key>
    <array>
      <string>/Applications/Emacs.app/Contents/MacOS/Emacs</string>
      <string>--daemon</string>
    </array>
   <key>RunAtLoad</key>
   <true/>
   <key>KeepAlive</key>
   <true/>
   <key>ServiceDescription</key>
   <string>Gnu Emacs Daemon</string>
  </dict>
</plist>

Questa specie funziona ma ho notato che il tema del mio colore non funzionava correttamente. Poi mi sono ricordato di aver aggiunto quanto segue al mio file init:

(when window-system 
  (require 'alpha)
  (require 'color-theme-ir-black)
  (modify-frame-parameters (selected-frame) '((alpha . 85)))
  (color-theme-ir-black))

Quando avviato come un sistema a finestre daemon è apparentemente falso e questo ha senso, tuttavia il motivo per cui l'ho aggiunto è perché a volte mi piace avviare il normale emacs compilato in un terminale da ssh ecc e questo schema di colori è completamente illeggibile in iTerm quindi il (quando il sistema di finestre ...). C'è un modo per forzare emacs ad avviare la modalità finestra quando si avvia con --daemon?

Un altro problema che ho notato è che quando eseguo premere sw (delete-frame) in modalità dameon non ottengo il tentativo di errore di eliminare solo il frame visibile o iconizzato ed emacs continua a funzionare in background. Mi piace per la maggior parte, tuttavia ho notato che una volta ucciso l'ultimo fotogramma non riesco più a riaprire emacs dal documento e anche se emacs si attiverà e verranno visualizzati i menu non funzionano e non riesco a creare un nuovo fotogramma tranne che usando emacsclient dalla riga di comando. Qualcun altro ha questo problema e / o raccomandazione sulla soluzione alternativa? forse posso legare sw per rilevare se l'ultimo frame e iconify-frame invece, ma non sono sicuro del motivo per cui pensa che non sia l'ultima finestra e mi ha permesso di ucciderlo in primo luogo.

AGGIORNARE:

Ho trovato un commento sul seguente blog di Steve Purcell con una soluzione per un problema molto simile: http://emacs-fu.blogspot.com/2009/03/color-theming.html

Il segreto sembra usare l'hook after after make frame per impostare il frame appena creato e anche (setq color-theme-is-global nil) in modo che ogni frame possa avere il suo tema cromatico. Quindi le sezioni rilevanti del mio init ora appaiono così:

(defvar after-make-console-frame-hooks '()
"Hooks to run after creating a new TTY frame")
(defvar after-make-window-system-frame-hooks '()
"Hooks to run after creating a new window-system frame")

(defun run-after-make-frame-hooks (frame)
"Selectively run either `after-make-console-frame-hooks' or
`after-make-window-system-frame-hooks'"
  (select-frame frame)
  (run-hooks (if window-system
               'after-make-window-system-frame-hooks
               'after-make-console-frame-hooks)))

(add-hook 'after-make-frame-functions 'run-after-make-frame-hooks)
(add-hook 'after-init-hook (lambda ()
  (run-after-make-frame-hooks (selected-frame))))


(setq color-theme-is-global nil)

(add-hook 'after-make-window-system-frame-hooks
          '(lambda ()
             (require 'alpha)
             (require 'color-theme-ir-black)
             (modify-frame-parameters (selected-frame) '((alpha . 85)))
             (color-theme-ir-black)
             (global-set-key (kbd "s-w") 'delete-frame)))

Tuttavia, sto ancora riscontrando il problema in cui delete-frame chiude l'ultimo frame quando emacs è stato avviato come demone e non mi consente di creare un nuovo frame diverso dall'uso di emacsclient.

AGGIORNARE:

Se eval (frame-list)vedo ci sono 2 frame elencati anche se solo uno è visibile. Ho notato che ciò non si verifica se avvio Emacs con open /Applications/Emacs.appanziché emacsclient. Normalmente avvio emacs dalla riga di comando con un alias e='emacsclient -c -n 'che è ciò che crea il secondo frame. Posso solo collegarmi all'altro frame avviando emacs con il comando open. Se provo emacsclient -n somefile senza -cnon ottenere nulla, e se corro emacsclient -n -e '(frame-list)'vedo che c'è un frame che non è visibile fino a quando non uso -cper creare un nuovo frame o aprire emacs dalla cartella delle applicazioni.

L'esecuzione di un processo o di un'applicazione come demone launchd gli conferisce un ambiente molto diverso dall'eseguirlo normalmente o dalla riga di comando. Mi chiedo se potrebbe non funzionare meglio invece utilizzare uno script di shell come elemento di accesso.

Per esempio:

#!/bin/bash
while true
do
  open -W /Applications/Emacs.app
done

Questo script dovrebbe essere salvato in un file con .commandun'estensione e 755 autorizzazioni ( chmod 0755 myemacsscript.command) e quindi aggiunto al riquadro Preferenze di Sistema: Accesso: Elementi di accesso.

Quando effettui il login, Terminal avvierà ed eseguirà questo script. Probabilmente vorrai impostare un profilo terminale predefinito che escluda il terminale dalla richiesta di chiusura per questo particolare script, in modo da non trattenerti quando esci.

Non ho idea se questo risolverà i problemi particolari con Emacs.app, ma potrebbe almeno fornire un ambiente più vicino a ciò che si aspetta Emacs.app.