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

David Reitter david.reitter at gmail.com
Mon Oct 13 22:43:00 EDT 2008

On 13 Oct 2008, at 13:40, Adrian wrote:

> Well, I spent a weekend with Aquamacs and I got the opening of new  
> files to behave about as well as I can hope for.  I was interested  
> primarily in three issues, which are closely tied together: removing  
> the scratch buffer, automatically tiling new windows, and closing  
> unmodified untitled windows when they are overwritten by other  
> buffers.

OK, now we need to separate these things.

> As a caveat before all of this, I should mention that I operate in  
> one-buffer-one-frame mode, and most of my modifications will  
> probably fail miserably outside of this mode.

OK, that needs to be addressed!

> I should also confess that I am not very confident in these  
> modifications, as they seem like kludges operating on arcane Emacs  
> numerology, but they seem to work as far as I can tell on my  
> Aquamacs distribution on my particular computer.

Don't forget that Emacs Lisp and the API were designed to allow users  
to customize their Emacs - they weren't meant to do things as big as  
we're doing now.  A similar thing happened to TeX, which is a macro  
language.  Such things tend to be resilient...

> Before I delve too deeply into this, there is one question that I  
> still have.  I have not been able to figure out how to affect the  
> cursor focus between Aquamacs frames.

The cursor, as in where the point is? (i.e. not the mouse cursor,  

> When I open a new frame, I want the cursor to move to that frame  
> always, even if the frame was opened by invoking Aquamacs from the  
> command line.

Yes, that should be the case.  There have been some bugs in the past,  
and I'd recommend you work with the latest CVS builds.

> Neither select-frame nor select-frame-set-focus seem to have any  
> effect.

select-frame-set-input-focus (and perhaps select-window) should do the  
job.  Please post your code and maybe we'll find something wrong with  

>   I can access the desired buffer with set-buffer, and even modify  
> that buffer, but I can't put the actual cursor in that buffer.  Any  
> suggestions here?  Does Aquamacs have some other mechanism for  
> handling cursor position?

clearly no!

> It turned out that the code path as buffers and frames are created  
> and destroyed is about as intuitive as riding a bicycle... going  
> backwards, blindfolded, and with no hands.  Okay, maybe not that  
> bad, but still, not very clear.

100% agreement.  The code is probably 20 years old or so (don't know  
when they introduced frames).

> There is also some anomalous behaviour here and there.  Emacs  
> requires that a frame always be open.  If you try to kill all  
> frames, Emacs refuses.  The visibiliy of a frame "on the screen"  
> does not seem to correspond to the "visibility bit" that Emacs  
> maintains for each frame.  In particular, there is one frame that is  
> not visible until selected by the user (it usually appears as the  
> last frame on the list).  This frame doesn't inherit any of the  
> default window properties.  For some reason, Emacs seems to think  
> that this is the only visible frame and will not allow me to close it.

Aquamacs hides the last visible frame.

Default frame parameters are set when the frame is created, not when  
it is made visible or anything like that.
The first frame always has initial-frame-alist parameters.

> One of the biggest challenges in getting the behaviour I wanted was  
> to prevent Emacs from making this frame visible on the screen.  To  
> do so, I sometimes had to create dummy frames and then delete them  
> later so that Emacs was never left with only one frame (the  
> unkillable default frame with bad window properties) to choose from.

I don't think that this is the solution...

If you don't want a certain buffer, then please delete (kill) it.
> ;;    closes the scratch buffer and creates a blank buffer
> (defun my-close-scratch ()

use real doc strings!

>   (kill-buffer "*scratch*")
>   (new-empty-buffer)
>   (if (< 6 (length (buffer-list)))
>       (kill-buffer "untitled")

Why 6 and not 7?
> ;; after-make-frame hook
> ;;   if any goofy system buffers have popped, close them
> ;;   then tile remaining windows

I think this could better be handled by modifying the `frame-creation- 
function' (which is, in Aquamacs `smart-position-and-create-frame').
That way you can create the frames in a hidden state.
>   (setq real_buff_count (- (length (buffer-list)) 6))
>   (setq real_frame_count (- (length (frame-list)) 1))
>   (setq real_count_diff (- real_frame_count real_buff_count))
>   (setq i 0)
>   (if (and (= real_count_diff 2)  (not first_frame))
>     (delete-frame (nth 1 (frame-list)))
>   )

I think this makes a lot of `one-buffer-one-frame' assumptions.
Why not close frames according to their titles? (Use a regexp!)

Also, use (let (..) ...) here.

Congratulations to your first Emacs Lisp hacking session!

http://aquamacs.org -- Aquamacs: Emacs on Mac OS X
http://aquamacs.org/donate -- Could we help you? Return the favor and  
support the Aquamacs Project!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2193 bytes
Desc: not available
URL: <http://email.esm.psu.edu/pipermail/macosx-emacs/attachments/20081013/a9d9216b/attachment.p7s>

More information about the MacOSX-Emacs mailing list