bug#1109: Suggestions on emacs's scratch buffer

[xah lee]

Hi emacs developers,

Here's a suggestion on emacs scratch buffer i thought might be  
interesting.

Last month there's a maybe 200 messages flamefeast in gnu.emacs.help  
on this issue.

I am not sure this suggestion about removing *scratch* buffer is  
sensible to most emacs developers, but i thought i'd put it in bug  
database for what's its worth.

The full article of my reasons and suggestions is at:

http://xahlee.org/emacs/modernization_scratch_buffer.html

plain text version follows below my sig.

Thanks for your consideration.

Best,

  Xah
∑ http://xahlee.org/

☄

---------------------------------------------
Suggestions on Emacs's Scratch Buffer

Xah Lee, 2008-09

In the article The Modernization of Emacs, i suggested that emacs's  
“*scratch*” buffer be removed. In this article, i 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.

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

Here are few minor reasons:

    • There is no easy, intuitive way to create multiple scratch  
buffers. (it is done by using the switch-to-buffer command (C-x b)  
and give name that is not one of existing buffers.)

    • When the scratch buffer is closed, emacs does not prompt user  
to save it. This easily causes data loss.

    • A scratch pad can be very useful not just for temporary elisp  
code but for any scratch notes or programing in other languages. (For  
example, well known programer Stevey Yegg in his popular Effective  
Emacs↗ blog list it as a top 10 tip in emacs productivity.)  
Emacs's “*scratch*” buffer is narrowly geared for elisp editing  
only, defaulting to emacs-lisp-mode.

    • Emacs does not provide a user level function to create a new  
buffer. It has menu “File‣Open file...” (a wrapper to the find- 
file command), which immediately prompt user for a full file path.  
This is annoying. Modern apps's New File command actually just create  
a new untitled file without prompting, and only when user save it it  
prompt a file name. If user closes it, it prompts for saving.

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:

    • The menu command “New” is a widely adopted standard among  
apps across Mac, Windows, unixes. It is familiar to all software users.

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

    • A New Buffer command (where the corresponding elisp command  
name might be named new-empty-buffer), can completely cover the  
functionality of emacs's “*scratch*” 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.

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

    • The name “untitled” is conventional, far more widely  
understood, and more general than “scratch”.

    • For those who use scratch buffer for elisp coding, she can  
set a preference (e.g. emacs customize feature) so that the new  
buffer default to emacs-lisp-mode.

    • Adopting the suggestion would fix several problems for those  
who actually use emacs's “*scratch*” buffer. (1) emacs no longer  
mysteriously spawn a “*scratch*” when emacs starts, or respawn  
the “*scratch*” buffer when user tries to close all buffers. (2)  
Multiple scratch buffers can be created by a keyboard shortcut. (3)  
Data lose is prevented because closing a scratch buffer will prompt  
for save.

Note: the proposed keybinding “Ctrl+n” and “Ctrl+w” need not  
be part of this proposal because emacs already use “Ctrl+n” and  
“Ctrl+w” for basic cursor movement and cut. However, it could be  
adapted in conjunction with newly designed Ergonomic Keybinding. (see  
below)
Draft Implementation

The above suggestion is experimentally implemented in my Ergonomic  
Keyboard Shortcut Layout For Emacs. The following are the elisp files.

    • ergonomic_keybinding_dvorak.el.
    • ergonomic_keybinding_qwerty.el.

Some detail about the implementation:

    • create-new-buffer will create a new empty buffer named  
“untitled”. (this should be added to the menu under “File‣New  
Buffer” but i haven't done that yet.)

    • create-new-buffer has standard keyboard shortcut Ctrl+n.

    • elisp command close-current-buffer will close the current  
buffer, and if it is a buffer not associated with a file (such as  
“untitled”), it'll ask user to save (unless it has no content)

    • close-current-buffer has the standard keyboard shortcut Ctrl+w.

    • close-current-buffer should have menu under  
“File‣Close”, but it is not currently done. The existing  
“File‣Close” menu command in emacs 22.2 calls kill-this-buffer,  
which has 2 problems. (1) it doesn't have a shortcut. (2) it doesn't  
ask users to save a buffer that are not associated with file (in  
effect, any text in the buffer is irreversibly lost immediately). The  
standard emacs command used to close a file is kill-buffer (Ctrl+x  
k). It has a major problem of prompting user even if the file is  
already saved.

I have been using the above code daily since late 2007, with  
incremental improvement and bug fixes. i'm sure it can use a lot more  
polishing for public use. The code is GPL'd, so feel free to grab  
pieces for your own use or submit into GNU.



☄