<div dir="ltr">I thought that perhaps this discussion could use a dedicated thread by this point.  I probably shouldn't have hijacked my own post to begin with.<div><br></div><div>If anyone can suggest where to look for some of the Aquamacs new buffer behaviour or interaction with the scratch buffer, I would be willing to try to make some changes in the source code, although I can't promise much as I just started working with lisp.  Removing the scratch buffer is something I feel strongly about and I believe would improve the usability of Aquamacs and make it behave more like other OS-X-native applications.  It seemed like overkill to me to try to learn a bit of a new language and wade through source code to try to achieve customized window positioning that probably wouldn't apply to any other user, but for the sake of removing the scratch buffer, I'm more game.</div>
<div><br></div><div>This might be going way too far afield, but I question whether the Emacs-owned buffers really have a place in the list of active buffers at all.  This is obviously a matter of opinion and programming style, so there probably won't be much agreement.  I've already made some of my case against the *scratch* buffer, but I also feel that the *messages* buffer is better accessed in a separate way than the other, user-created, buffers.  In particular, when I'm switching between the active buffers, I almost never want to see the *messages* buffer in a large frame window; it just gives me an extra key press on my way to buffers I actually want to see.  Maybe others can correct me on this?  Do other people often view the *messages* buffer as a large frame and find it useful to be able to switch to it while cycling through buffers?  Would it be sufficient to view the *messages* buffer, and perhaps other Emacs-owned buffers, using a separate syntax than that for user-created buffers?  The *messages* buffer is probably too deeply embedded in the implementation of Emacs to parse out exactly what a "fix" would constitute in this case.</div>
<div><br></div><div>I also wanted to report a failed attempt at a kludge for preventing the *scratch* buffer from appearing in a separate frame so that others might avoid reproducing my mistake.  My approach was to add an after-make-frame-functions hook that would kill any buffer with the name *scratch*.  I created a script that could successfully extract the name of the most recently created frame (posted below, just for the record).  However, the *scratch* buffer is sneakier than I anticipated: creating a new frame containing the *scratch* buffer does not call the make-frame hooks.  Even when the initial *scratch* frame is created, these hooks are not invoked.</div>
<div><br></div><div>Adrian</div><div><br></div><div><div>(defun my-no-scratch (frame)</div><div>  (setq params (frame-parameters frame))</div><div>  (setq params (car (nthcdr 7 params)))</div><div>  (setq framename (cdr params))</div>
<div>  ; framename now contains the name of the most recent frame</div><div>  ; could be closed if desired</div><div>)</div><div><br></div><div>; functions are arranged this way so that additional functions</div><div>; can be easily added to the hook later if desired</div>
<div>(defun my-after-make-frame-functions (frame)</div><div>  (my-no-scratch frame)</div><div>)</div><div><br></div><div>; after-make-frame hooks pass last created frame as argument</div><div>(add-hook 'after-make-frame-functions 'my-after-make-frame-functions)</div>
</div></div>