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

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

Re: Emacs: Problems of the Scratch Buffer


From: Aaron Meurer
Subject: Re: Emacs: Problems of the Scratch Buffer
Date: Wed, 18 Apr 2012 13:33:47 -0600

On Wed, Apr 18, 2012 at 6:00 AM, Xah Lee <address@hidden> wrote:
> for entertainment purpose only.
>
> 〈Emacs: Problems of the Scratch Buffer〉
> http://xahlee.org/emacs/modernization_scratch_buffer.html
>
> ---------------------------------------------
>
> Emacs: Problems of the Scratch Buffer
>  By Xah Lee, 2008-09, …, 2012-04-18
>
> Here are reasons that the scratch buffer is not useful to most people:
>
>  1.It is not useful for 99% of emacs users. If people wanted a scratch
> pad, they can open a new document and not save it. This way is
> familiar to all software users.
>  2.The “*scratch*” “buffer” is designed for emacs lisp programers. (it
> defaults to lisp-interaction-mode.) 99% of emacs users are not lisp
> coders.
>  3.The “*scratch*” “buffer” is a INTRUSIVE IDIOSYNCRASY. New users are
> not familiar what it is. It is the first thing presented to users, and
> it persists.
>
> Scratch Buffer is Inconvenient
>
> Here are reasons that a alternative to “*scratch*” “buffer” is more
> useful:
>
>  1.There is no easy, intuitive way to create multiple scratch buffers.
> (it is done by calling switch-to-buffer 【Ctrl+x b】 then give a name
> that is not one of existing buffers.)
>  2.When the scratch buffer is closed, emacs does not prompt user to
> save it. This easily causes data loss.

I think this is the whole point.

>  3.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 blog article
> Effective Emacs↗, considers creating new temp buffer as a top 10 tip
> in emacs productivity.)

I agree.  The scratch buffer seems to be made so you could easily type
and execute lisp code interactively.  But even if you just want to run
one lisp command, you can type it literally anywhere and type C-x C-e
(the disadvantage is you won't get syntax highlighting or completion
if you are not in lisp-mode).  IMHO, *scratch* should default to
text-mode.

>  4.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 prompt only when user wants to
> save it. If user closes it, it prompts for saving.
>
> Proposed Fix: Adding a “new-buffer” Command
>
> I propose that emacs should add a command “new-buffer” with menu
> 〖File▸New〗. Once called, it should create a empty buffer titled
> {untitled, untitled<2>, untitled<3>, …}.
>
>  1.Users can now create multiple temp buffers easily, by just calling
> “new-buffer”. No more work-around using “switch-to-buffer” method.
>  2.Data lose is prevented because closing any unsaved buffer will
> prompt for save.
>  3.For lisp coders, new buffer can default to a lisp mode. Other
> programers can default it to python mode, ruby mode, etc.

+1 for this plan.

One thing, though.  I do like how opening emacs with no files gives
you the scratch buffer.  I just think it should default to text mode.

>
>  1.No more redundant and mysterious “*scratch*” concept.
>  2.The menu command “New” is a widely adopted standard among apps
> across Mac, Windows, Linux.
>  3.A “new-buffer” command completely cover the functionality of
> emacs's “*scratch*” buffer.
>  4.The name “untitled” is conventional, widely understood.
>
> Implementation
>
> The above suggestion is implemented in ErgoEmacs Keybinding, where you
> simply press 【Ctrl+n】 to create a new buffer.

Well you'd need a normal keybinding too, assumedly one that's C-x
C-something.  C-n moves down a line, and I don't think that's going to
change any time soon.

Aaron Meurer



reply via email to

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