Org mode's agenda list as initial-buffer-choice with Emacs' daemon mode
Normally when I want to do anything with Emacs it's a matter of writing some Elisp code and poof, I've got what I want. Anything can be realized, it's usually just a matter of knowing which internal to tweak or what to implement. With that in mind, now that I'm getting into the swing of using Org mode I thought it would be great to have org-agenda-list as my default buffer when I open Emacs. As it turns out, simply doing something like (setq initial-buffer-choice 'org-agenda-list) won't yield the same results between daemon and non-daemon Emacs. Wheee!
While initially testing out this idea, using the setq mentioned above, I fired up /usr/bin/emacs to ensure a fresh instance and not my daemonized one that's been running for a while (and without evaluating the new init code, which in hindsight would have been apropos.) Emacs fired right up and the org agenda list opened, just like I wanted. Kickass! I make a few more tweaks and then kill my current daemon process and hit my WM's keycombo for opening Emacs. After a few seconds, I notice that it hasn't started (it's usually about a 1.5 second startup time, give or take.) Something is wrong, wheee again!
I proceed to try a few things like starting the daemon from the command line, but it would just hang there. It then began to occur to me that the daemon was hanging on trying to load the agenda list buffer when there were no open frames, which is the case even when you start the daemon implicitly with emacsclient. In the end I was able to make this work with Elisp, but it's ran with the --eval command-line argument instead of adding a line to my init.el:
emacsclient -c -n --alternate-editor="" --eval '(org-agenda-list)'
Using the above method, it is ensured that (org-agenda-list) isn't called until there's a frame to display it in. Per the emacsclient manpage, when you pass --eval, the Emacs client program doesn't also open arguments as files. If you try to do this, what you think you are giving as file names will be interpreted as lisp forms, and instead of your file being opened an error is spat out to stdout. I work around this by making my Emacs hotkey use the --eval arg, but not my command-line alias function.
This could be taken a step further and implemented conditionally, such that when non-daemon Emacs is opened it too runs (org-agenda-list), but I rarely use non-daemon Emacs and am OK without that. Your mileage may vary, and of course there may be better ways to do this as well. Regardless, this was a fun look into the internals of Emacs' startup process and I learned more than I expected.