[OS X Emacs] Removing the *scratch* buffer in Aquamacs

Adrian adrian.down at gmail.com
Sat Oct 11 01:21:26 EDT 2008

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

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.

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.


(defun my-no-scratch (frame)
  (setq params (frame-parameters frame))
  (setq params (car (nthcdr 7 params)))
  (setq framename (cdr params))
  ; framename now contains the name of the most recent frame
  ; could be closed if desired

; functions are arranged this way so that additional functions
; can be easily added to the hook later if desired
(defun my-after-make-frame-functions (frame)
  (my-no-scratch frame)

; after-make-frame hooks pass last created frame as argument
(add-hook 'after-make-frame-functions 'my-after-make-frame-functions)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://email.esm.psu.edu/pipermail/macosx-emacs/attachments/20081010/2e47034c/attachment.html>

More information about the MacOSX-Emacs mailing list