Emacs jako demon w systemie OS X z systemem okien

Używam kakao GNU emacs 23.3.1 na OS X 10.6.
Dodałem następujące do ~ / Library / LaunchAgents / gnu.emacs.daemon.plist, aby uruchomił demona i automatycznie zrestartował emacsa, jeśli go przypadkowo zabiję.

<?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>

Ten rodzaj działa, ale zauważyłem, że mój motyw koloru nie działa poprawnie. Potem przypomniałem sobie, że dodałem następujące elementy do mojego pliku init:

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

Kiedy uruchamiany jako demon-system okienny jest najwyraźniej fałszywy i ma to sens, jednak dodałem to dlatego, że czasami lubię uruchamiać normalną emacsa w terminalu z ssh itp. I ten schemat kolorów jest całkowicie nieczytelny w iTerm, więc (gdy system okien ...). Czy istnieje sposób, aby zmusić emacsa do uruchomienia trybu okna, gdy zaczyna się od --daemon?

Innym problemem, który zauważyłem, jest to, że kiedy uruchamiam naciśnij sw (delete-frame) w trybie dameon, nie pojawia się błąd próby usunięcia jedynej widocznej lub ikonicznej ramki, a emacs nadal działa w tle. W większości to lubię, ale zauważyłem, że po zabiciu ostatniej ramki nie mogę już ponownie otwierać emacsa z dokumentu i chociaż emacs się aktywuje i wyświetlane są menu, nie działają i nie mogę utworzyć nowej ramki z wyjątkiem używania emacsclient z wiersza poleceń. Czy ktoś jeszcze ma ten problem lub zalecenie dotyczące obejścia? być może uda mi się powiązać sw, aby wykryć, czy ostatnia klatka i iconify-klatka zamiast tego, ale nie jestem pewien, dlaczego uważa, że ​​to nie ostatnie okno i pozwolił mi go zabić w pierwszej kolejności.

AKTUALIZACJA:

Znalazłem komentarz na następującym blogu autorstwa Steve'a Purcella z naprawą bardzo podobnego problemu: http://emacs-fu.blogspot.com/2009/03/color-theming.html

Wydaje się, że sekret polega na użyciu haka po utworzeniu ramki, aby skonfigurować nowo utworzoną ramkę, a także (setq color-theme-is-global zero), aby każda ramka mogła mieć własny motyw koloru. Odpowiednie sekcje mojego init wyglądają teraz tak:

(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)))

Nadal jednak mam problem polegający na tym, że delete-frame zamyka ostatnią ramkę, gdy emacs został uruchomiony jako demon i nie pozwala mi na tworzenie nowej ramki inaczej niż za pomocą emacsclient.

AKTUALIZACJA:

Jeśli eval (frame-list)widzę, są na liście 2 ramki, chociaż tylko jedna jest widoczna. Zauważyłem, że tak się nie stanie, jeśli uruchomię Emacsa z open /Applications/Emacs.appzamiast emacsclient. Zwykle uruchamiam emacsa z wiersza poleceń z aliasem, e='emacsclient -c -n 'który tworzy drugą ramkę. Mogę tylko dołączyć do drugiej ramki, uruchamiając emacsa za pomocą polecenia open. Jeśli spróbuję emacsclient -n gdzieś bez -c, nic nie dostanę, a jeśli uruchomię emacsclient -n -e '(frame-list)', zobaczę, że istnieje ramka, która jest po prostu niewidoczna, dopóki nie użyję -cdo utworzenia nowej ramki lub otwarcia emacsa z folderu aplikacji.

Uruchamianie procesu lub aplikacji jako uruchomionego demona daje mu zupełnie inne środowisko niż normalne uruchamianie lub w wierszu poleceń. Zastanawiam się, czy zamiast tego lepiej użyć skryptu powłoki jako elementu logowania.

Na przykład:

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

Ten skrypt należy zapisać w pliku z .commandrozszerzeniem i uprawnieniami 755 ( chmod 0755 myemacsscript.command), a następnie dodać do Preferencji systemowych: Logowanie: okienko Elementy logowania.

Po zalogowaniu terminal uruchomi i uruchomi ten skrypt. Prawdopodobnie zechcesz ustawić domyślny profil terminala, który wyklucza monitowanie terminala o zakończenie dla tego konkretnego skryptu, aby nie blokował cię po wylogowaniu.

Nie mam pojęcia, czy to rozwiąże konkretne problemy z Emacs.app, ale może przynajmniej zapewnić środowisko bliższe oczekiwaniom Emacs.app.