help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to get rid of *GNU Emacs* buffer on start-up?


From: Alan Mackenzie
Subject: Re: How to get rid of *GNU Emacs* buffer on start-up?
Date: Fri, 19 Sep 2008 20:36:19 +0000 (UTC)
User-agent: tin/1.6.2-20030910 ("Pabbay") (UNIX) (FreeBSD/4.11-RELEASE (i386))

Xah Lee <xah@xahlee.org> wrote:

> In the article The Modernization of Emacs, i suggested that emacs's
> ?*scratch*? buffer be removed. In this article, we give some detail
> about it.

> In the article, i gave the following as primary reasons that scratch
> buffer should be removed:

>    * It is not useful by 99% of letter writers. If they wanted a
> scratch pad, they can open a new document and not save it. This way is
> familiar to all software users.

It is necessary to have _some_ buffer when starting Emacs.  I don't know
where you get your figure of 99% from.  Even when it is not used, it's
not that big a nuisance.

>    * The ?*scratch*? ?buffer? is primarily designed for elisp
> programers. (it defaults to lisp mode) Majority of people who use
> emacs are not lisp coders. For lisp coders, they can easily customize
> their emacs to have a ?*scratch*? ?buffer?.

It's designed for any rough notes, including bits of Lisp.  The only
thing here I found bothersome was having C-j bound to
`eval-print-last-sexp', but I just rebound it to `newline-and-indent'.

>    * The ?*scratch*? ?buffer? is a intrusive idiosyncrasy. It is
> persistent, cannot be closed (it regenerates). It is foreign to all
> programers. This idiosyncrasy is the first thing presented to users,
> and it persists.

Have you considered coding an option so that this buffer would only be
created when, at startup time, there was no other buffer?  And coding
another option so that when you killed it, it would stay killed?  Write
a patch, and submit it to emacs-devel@gnu.org.  It might well be
accepted for Emacs 23.

[ .... ]

> Proposed Fix

> I propose that emacs should also add a menu command ?New buffer?, with
> the keyboard shortcut ?Ctrl+n?. Once called, it should create a
> scratch buffer titled ?untitled?. If one already exists, append
> numbers such ?untitled 2?. Here are the reasons:

As you know very well, there's already an important binding for C-n.

>    * The New command is a standard across Mac, Windows, Unix (Linux).
> It is familiar to all software users.

However, in Emacs, which uses many more key bindings than just about any
other program, such a prime binding can't be spared for a command used
only sporadically.  Of course, anybody who wants to rebind it is welcome.

>    * The Ctrl+n shortcut for New is standard and familiar to all
> software users.

That's not true.  It's not familiar to me.

>    * A New Buffer command (where the corresponding elisp command name
> might will be named new-empty-buffer), can supplant completely the
> functionality of *scratch* buffer.

This exists already: C-x b <new-name>.  I suggest you hack
`switch-to-buffer', possibly using advice at first, so that a C-u prefix
would cause it to create this new buffer.

>    * When users want to have a scratch buffer, he can create it by
> simply pressing the shortcut, and when he doesn't want it, he can
> simply close it with a standard keystroke Ctrl+w.

<sigh>.  Yet again, a prime binding like C-w can't be spared for such a
minor command.  As you know, C-w is bound to `kill-region'.

>    * By adopting the New Buffer and Ctrl+n, users can intuitively
> create multiple scratch buffers for any purpose.

Being able to create several *scratch*'es might well be useful.

>    * The name ?untitled? is conventional, far more widely understood,
> and more general than ?scratch?.

A mere unimportant trifle.

>    * For those who uses scratch buffer for elisp coding, she can set
> the default mode for untitled buffer to emacs lisp mode.

Or, more precisely, Lisp Interaction Mode.  But this option exists
already: `initial-major-mode'.

>    * Adopting the suggestion would fix several problems for those who
> actually use emacs's scratch buffer. (1) emacs no longer mysteriously
> respawn the ?*scratch*? buffer when user didn't want it. (2) user can
> create multiple scratch buffers by just pressing a shortcut. (3) User
> can close a scratch buffer and emacs will ask the user if she wants to
> save it.

> Draft Implementation

> The above suggestion is experimentally implemented in my Ergonomic
> Keyboard Shortcut Layout For Emacs.

Just as a suggestion, this seems silly.  Creating buffers has nothing to
do with keyboard layouts.  Why not separate out the functionality?

[ .... ]

>  Xah

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]