RE: Scratch buffer annoyance

["Drew Adams" <drew.adams@oracle.com>]

>     Wouldn't it be smarter to make the initial splash screen the current
>     buffer when Emacs starts instead?  It would make sense for that to be
>     read-only, and when one does C-x C-q, it could for example clear it
>     and toggle the read-only status of the buffer (with a brief note in
>     the initial splash screen that one can do C-x C-q to convert it into a
>     "scratch" buffer).
>
> It is an interesting idea.  What do others think?

There are two different questions: (1) what to do about saving *scratch*,
and (2) what to show/visit when Emacs is started.

1. Wrt #1, I agree with some others that *scratch* should not be read-only,
and it should not be automatically saved -  it is a scratch pad. And I think
you should not be asked whether you want to save it - "scratch" means
scratch, just as "toss" means toss. IOW, I prefer the traditional behavior.
I don't feel strongly about this, however.

I figure that you can use *scratch* without expecting to save or be reminded
about saving, or else you can visit a new file, in which case you are
reminded about saving. You also have the option, if you change your mind, of
using `C-x C-w' to save *scratch* to a file. If you want a file named
*scratch* from the beginning, then use `C-x C-f *scratch*' and set the mode
to `lisp-interaction-mode'. I use *scratch* rarely - I usually open a
throwaway file foo.el.


2. Wrt #2, I prefer my idea of having a user option, `visit-on-startup', to
specify the startup behavior. The default value could be whatever you like,
but users should be able to customize it. I personally prefer that the
default behavior be to visit a directory with Dired, and that the default
directory be `~/':

(defcustom visit-on-startup "~/"
  "What Emacs visits initially."
  :type '(choice
          (directory :tag "Directory"        :value "~/")
          (file      :tag "File"             :value "~/new.txt")
          (const     :tag "*scratch* buffer" :value "*scratch*")
          (const     :tag "Splash screen"    nil))
  :group 'emacs)

Note that if you visit a file or directory first, `C-x b' will quickly give
you *scratch*. IMO, *scratch* should definitely not be the default.

If the value is nil, then the current behavior is used: show the splash
screen. I suspect that you (RMS) will want the default value to be nil.

If you (RMS) in fact want the splash screen to _always_ show at first, then
we can eliminate the nil value, and `visit-on-startup' could then also
determine what is shown after the splash screen disappears (instead of
always showing *scratch*):

(defcustom visit-on-startup "~/"
  "What Emacs visits after the start-up splash screen."
  :type '(choice
          (directory :tag "Directory"        :value "~/")
          (file      :tag "File"             :value "~/new.txt")
          (const     :tag "*scratch* buffer" :value "*scratch*"))
  :group 'emacs)

The code that uses `visit-on-startup' could do something like this, when the
splash screen goes bye-bye:

(if (string= "*scratch*" visit-on-startup)
    (switch-to-buffer "*scratch*"))
  (find-file visit-on-startup))

If it's deemed important, we could have two different choices for a startup
file: `file' (new or existing) and `new-file' (new only). That way, a user
could be sure to start with a new file if s?he wanted - the name could add
"<2>" etc. as needed. BTW, is (file :must-match nil) allowed in a `choice'?
I see only (file :must-match t) documented.


3. Related to #1
: We could have a user option that is an alist of buffer names. When you
quit Emacs or kill such a buffer, the buffer is either automatically saved
or you are prompted to save it. The alist keys would be buffer names and the
values would be either `ask' or a file name (absolute or relative).

Those who want to save *scratch* should then be able to do so either with
prompting or without, and either in the same file each time or in a
different (relative) file, depending on the current default-directory. Those
of us who don't want to save *scratch* would not have an alist entry for it.
I'd argue for the default value of the option to be nil.

Perhaps something such as this exists already, but I'm unaware of it.