bug#11298: 24.0.95; (WISH) Re-look scratch buffers

bug#11298: 24.0.95; (WISH) Re-look scratch buffers

[Jambunathan K]

Feel free to close it or add to it.

An exact copy of my post in help-gnu-emacs.
http://lists.gnu.org/archive/html/help-gnu-emacs/2012-04/msg00332.html

Increasingly, I am feeling the need for multiple scratch buffers.  By
default, my scratch buffer is in emacs-lisp mode.  Some times, I switch
that scratch buffer to Org-mode when I create lists, tables or just
copy-paste some plain text from interwebs purely for reasons of
wrapping/filling.

1. Allow multiple scratch buffers one for each mode the user is
   interested in.  The defcustom can have a solitary text-mode entry.  A
   user wanting no scratch buffer at all can null-ify the mode list.  A
   user like me can add emacs-lisp-mode and org-mode to it.

2. Just in case I need a one-off scratch buffer, I need a quick way to
   create it without having to think of (or type) out the full name Or
   confirm my intentions (This latter part is *very* annoying).  

      C-u C-x b can offer to create *scratch-%s* (or %s-scratch) in
      %s-mode.

3. I think it is not the scratch buffer that is idiosyncratic but the
   /name/.  Instead of using scratch one could call it say a notes
   buffer or a temp buffer.

That said I am happy with the way things are.  I know how to kill my
scratch buffer and I also know how to create multiple ones if needed.  I
also know how to type 'y' if prompted :-).

bug#11298: 24.0.95; (WISH) Re-look scratch buffers

[Stefan Monnier]

> 1. Allow multiple scratch buffers one for each mode the user is
>    interested in.

We do not disallow that, so could you be more specific in what you mean
by that?

>    The defcustom can have a solitary text-mode entry.

Which defcustom?

>       C-u C-x b can offer to create *scratch-%s* (or %s-scratch) in
>       %s-mode.

Interesting idea.  It might not even need a C-u: we could simply make
C-x b query the user for a major-mode when the buffer doesn't exist yet
(and we could try and take a hint from the buffer name to guess a good
default: e.g. looking for a major-mode name in the buffer name, or
matching the buffer name against auto-mode-alist).

> 3. I think it is not the scratch buffer that is idiosyncratic but the
>    /name/.  Instead of using scratch one could call it say a notes
>    buffer or a temp buffer.

I'm not married to "*scratch*", but "notes" sounds like something you'd
want to save, and "temp" sounds like something that might disappear
without warning.


        Stefan

bug#11298: 24.0.95; (WISH) Re-look scratch buffers

[Jambunathan K]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> 1. Allow multiple scratch buffers one for each mode the user is
>>    interested in.
>
> We do not disallow that, so could you be more specific in what you mean
> by that?
>

Instead of creating one scratch buffer, make changes such a way that N
scratch buffers are created. N = 0, 1, 2, 3 etc etc.

>>    The defcustom can have a solitary text-mode entry.
>
> Which defcustom?

This defcustom will be newly introduced as part of this change.  Let's
call it `scratch-buffer-modes'.  With the below setting,

  (setq scratch-buffer-modes '(emacs-lisp-mode org-mode))

I will get 2 scratch buffers by default on startup.  One *org-scratch*
in org-mode and one *emacs-lisp-scratch* in emacs-lisp mode.

If someone is unhappy with having any scratch buffers at all, then one
could just do a

  (setq scratch-buffer-mode nil)


>>       C-u C-x b can offer to create *scratch-%s* (or %s-scratch) in
>>       %s-mode.
>
> Interesting idea.  It might not even need a C-u: we could simply make
> C-x b query the user for a major-mode when the buffer doesn't exist yet
> (and we could try and take a hint from the buffer name to guess a good
> default: e.g. looking for a major-mode name in the buffer name, or
> matching the buffer name against auto-mode-alist).

Whatever is chosen, this prompt "No buffer matching whatever, create one
(y/n)?" should be removed.  This is annoying.  I am not destroying
things.  I am not sure why the world is against people creating stuff
:-).

A sensible name *must* be offered, which I can just RET with possibly a
minor modification.

>> 3. I think it is not the scratch buffer that is idiosyncratic but the
>>    /name/.  Instead of using scratch one could call it say a notes
>>    buffer or a temp buffer.
>
> I'm not married to "*scratch*", but "notes" sounds like something you'd
> want to save, and "temp" sounds like something that might disappear
> without warning.

May be, marry scratch buffer with emacs-lock-mode...

I don't use persistent scratch buffers. 

A persistent scratch buffer could be same as what we now call an
`initial-buffer-choice'.  Only difference is that the file is
~/.emacs.d/scratch ("secretly" chosen by the Emacs).

bug#11298: 24.0.95; (WISH) Re-look scratch buffers

[Richard Stallman]

    Instead of creating one scratch buffer, make changes such a way that N
    scratch buffers are created. N = 0, 1, 2, 3 etc etc.

rename-uniquely is a good way to do that.  Whenever you want a new one,
go to *scratch* and type M-x rename-uniquely.  Then the next thing
that tries to make *scratch* will create a new one.


--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

bug#11298: 24.0.95; (WISH) Re-look scratch buffers

[Jambunathan K]

Richard Stallman <rms@gnu.org> writes:

>     Instead of creating one scratch buffer, make changes such a way that N
>     scratch buffers are created. N = 0, 1, 2, 3 etc etc.
>
> rename-uniquely is a good way to do that.  Whenever you want a new one,
> go to *scratch* and type M-x rename-uniquely.  Then the next thing
> that tries to make *scratch* will create a new one.

I believe what I am saying is this:

Can the scratch buffers be uniquified st. that the major mode of the
buffer is reflected in it's name.  This way I can have *scratch-org*,
*scratch-text*, *scratch-emacs-lisp* etc.

Just brainstorming.

> --
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>   Use Ekiga or an ordinary phone call

bug#11298: 24.0.95; (WISH) Re-look scratch buffers

[Stefan Monnier]

>>> 1. Allow multiple scratch buffers one for each mode the user is
>>> interested in.
>> We do not disallow that, so could you be more specific in what you mean
>> by that?
> Instead of creating one scratch buffer, make changes such a way that N
> scratch buffers are created. N = 0, 1, 2, 3 etc etc.

You mean start up Emacs with several scratch buffers?
Hmm, now that's an unexpected request: most people don't even know what
to do with the single *scratch* buffer.
I'd rather move towards eliminating *scratch* (after all, we have the
splash screen to replace it nowadays).

>>> C-u C-x b can offer to create *scratch-%s* (or %s-scratch) in
>>> %s-mode.
>> Interesting idea.  It might not even need a C-u: we could simply make
>> C-x b query the user for a major-mode when the buffer doesn't exist yet
>> (and we could try and take a hint from the buffer name to guess a good
>> default: e.g. looking for a major-mode name in the buffer name, or
>> matching the buffer name against auto-mode-alist).
> Whatever is chosen, this prompt "No buffer matching whatever, create one
> (y/n)?" should be removed.  This is annoying.

This is the fault of `ido'.  The normal C-x b just asks for an extra RET
to confirm you do want to create a new buffer (under the control of
confirm-nonexistent-file-or-buffer).


        Stefan

bug#11298: 24.0.95; (WISH) Re-look scratch buffers

[Lennart Borgman]

On Mon, Apr 23, 2012 at 21:39, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>>> 1. Allow multiple scratch buffers one for each mode the user is
>>>> interested in.
>>> We do not disallow that, so could you be more specific in what you mean
>>> by that?
>> Instead of creating one scratch buffer, make changes such a way that N
>> scratch buffers are created. N = 0, 1, 2, 3 etc etc.
>
> You mean start up Emacs with several scratch buffers?
> Hmm, now that's an unexpected request: most people don't even know what
> to do with the single *scratch* buffer.
> I'd rather move towards eliminating *scratch* (after all, we have the
> splash screen to replace it nowadays).

In the nXhtml package I have a command that creates a new buffer from
the content in the clipboard. I now often use that instead of the
*scratch* buffer.

bug#11298: 24.0.95; (WISH) Re-look scratch buffers

[Drew Adams]

> This is the fault of `ido'.  The normal C-x b just asks for 
> an extra RET to confirm you do want to create a new buffer
> (under the control of confirm-nonexistent-file-or-buffer).

Actually, with the default value of `after-completion' I do not see it ever
asking for confirmation.  Did you mean only if the user has customized that
option to something other than nil and the default value?  If not, I guess I'm
missing something.

The doc says that confirmation is required for `after-completion' only if
`minibuffer-complete-and-exit' is called immediately after
`minibuffer-complete'.

[The doc actually phrases that backward.  Why it does that, and why it does not
mention the keys `C-j' and `TAB' instead of the commands, I don't know.  Just to
make it harder to understand, I guess. ;-)]

But I don't see any `C-x b' scenario that leads to confirmation being required,
if the option has the default value of `after-completion'.  AFAICT, when that is
the option value, `C-x b' (`switch-to-buffer'), does not even use a `must-match'
completion keymap to read the buffer name, so `minibuffer-complete-and-exit' is
not even bound to a key.

(No, I didn't check the C source code to be sure, but the debugger shows that
`C-j' invokes `exit-minibuffer' for `read-buffer-to-switch' with an option value
of `after-completion'.)

What am I missing?  Is there a way to hit TAB for a nonexistent buffer name and
have confirmation be requested?  If I type a nonexistent name and hit TAB
(getting "No match"), and then hit `C-j' or `RET', the name is accepted without
confirmation.

bug#11298: 24.0.95; (WISH) Re-look scratch buffers

[Stefan Monnier]

> But I don't see any `C-x b' scenario that leads to confirmation being
> required, if the option has the default value of `after-completion'.

   % emacs23 -Q
   C-x b foo TAB RET

Asks for confirmation here.


        Stefan

bug#11298: 24.0.95; (WISH) Re-look scratch buffers

[Drew Adams]

> > But I don't see any `C-x b' scenario that leads to 
> > confirmation being required, if the option has the
> > default value of `after-completion'.
> 
>    % emacs23 -Q
>    C-x b foo TAB RET
> Asks for confirmation here.

Yes, in Emacs 23.3, it does act as you describe:

In GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600)
 of 2011-03-10 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.5) --no-opt --cflags
-Ic:/imagesupport/include'

But it does not here (Emacs 24 latest build, `emacs -Q'):

In GNU Emacs 24.1.50.1 (i386-mingw-nt5.1.2600)
 of 2012-04-23 on MARVIN
Bzr revision: 108006
agustin.martin@hispalinux.es-20120423103325-xmra3329elgzhmpc
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include
 -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
 -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'

bug#11298: Recipe to surface *code-conversion-work* buffer

[Jambunathan K]

[Recipe to surface *code-conversion-work* buffer]
-------------------------------------------------

Summary
-------

This is my little excursion in to killing *scratch* (to death?)

Now I am wondering whether:
1. *scratch* buffer re-generates itself
2. Why some buffers like *code-conversion-work* (and other internal
   buffers like "Minibuf", "Echo Area") gets /surfaced/ in some buffer
   listings, but totally disappears in the next buffer listing.

For want of better place to put this, I am attaching it to *scratch*
buffer bug report.

Read on.

Steps to reproduce:
------------------

1. Emacs -Q
2. C-x b TAB gives me
    ,----
    | Click <mouse-2> on a completion to select it.
    | In this buffer, type RET to select the completion near point.
    | 
    | Possible completions are:
    | *Messages*
    `----
3. C-g. Now you are in *scratch*
4. Kill *scratch* => *Messages* shows up
5. Kill *Messages* => *Completions* shows up
6. Kill *Completions* => *scratch* shows up

   Now I get confused.  Why does *scratch* show up again. Didn't I kill
   it before? 

7. C-x b TAB TAB gets me this
    ,----
    | Click <mouse-2> on a completion to select it.
    | In this buffer, type RET to select the completion near point.
    | 
    | Possible completions are:
    |  *Echo Area 0* 	 *Echo Area 1*
    |  *Minibuf-0* 	 *Minibuf-1*
    |  *code-conversion-work*
    `----

   I choose to examine *code-conversion-work*.  The name seems
   interesting.  This is what I see there when I visit it:

    ,----
    | c:/Program Files/emacs-24.0.95/lisp/emacs-lisp/easymenu.elc
    `----

8. C-x b TAB now shows 
    ,----
    | Click <mouse-2> on a completion to select it.
    | In this buffer, type RET to select the completion near point.
    | 
    | Possible completions are:
    | *Completions*
    | *Messages*
    | *scratch*
    `----

   Note that special buffers that show up in step 7 has disappeared.

bug#11298: Recipe to surface *code-conversion-work* buffer

[martin rudalics]

 >> This is my little excursion in to killing *scratch* (to death?)
 >
 > Now I am wondering whether:
 > 1. *scratch* buffer re-generates itself

It does because Emacs needs at least one buffer it can display.

 > 2. Why some buffers like *code-conversion-work* (and other internal
 >    buffers like "Minibuf", "Echo Area") gets /surfaced/ in some buffer
 >    listings, but totally disappears in the next buffer listing.

Usually they are not displayed because their names start with a space.

 > For want of better place to put this, I am attaching it to *scratch*
 > buffer bug report.
 >
 > Read on.
 >
 > Steps to reproduce:
 > ------------------
 >
 > 1. Emacs -Q
 > 2. C-x b TAB gives me
 >     ,----
 >     | Click <mouse-2> on a completion to select it.
 >     | In this buffer, type RET to select the completion near point.
 >     |
 >     | Possible completions are:
 >     | *Messages*
 >     `----
 > 3. C-g. Now you are in *scratch*
 > 4. Kill *scratch* => *Messages* shows up
 > 5. Kill *Messages* => *Completions* shows up
 > 6. Kill *Completions* => *scratch* shows up
 >
 >    Now I get confused.  Why does *scratch* show up again. Didn't I kill
 >    it before?

Because when you killed the last other buffer whose name didn't start
with a space, *scratch* got regenerated.

 > 7. C-x b TAB TAB gets me this
 >     ,----
 >     | Click <mouse-2> on a completion to select it.
 >     | In this buffer, type RET to select the completion near point.
 >     |
 >     | Possible completions are:
 >     |  *Echo Area 0* 	 *Echo Area 1*
 >     |  *Minibuf-0* 	 *Minibuf-1*
 >     |  *code-conversion-work*
 >     `----
 >
 >    I choose to examine *code-conversion-work*.  The name seems
 >    interesting.  This is what I see there when I visit it:
 >
 >     ,----
 >     | c:/Program Files/emacs-24.0.95/lisp/emacs-lisp/easymenu.elc
 >     `----
 >

Usually, buffers whose names start with a space are not proposed.  But
since you killed all other buffers what do you want Emacs to propose?

 > 8. C-x b TAB now shows
 >     ,----
 >     | Click <mouse-2> on a completion to select it.
 >     | In this buffer, type RET to select the completion near point.
 >     |
 >     | Possible completions are:
 >     | *Completions*
 >     | *Messages*
 >     | *scratch*
 >     `----
 >
 >    Note that special buffers that show up in step 7 has disappeared.

Because these buffer have been recreated in the meantime.

Is there anything bad about the behavior you observed?

martin

bug#11298: Recipe to surface *code-conversion-work* buffer

[Jambunathan K]

martin rudalics <rudalics@gmx.at> writes:

>>> This is my little excursion in to killing *scratch* (to death?)
>>
>> Now I am wondering whether:
>> 1. *scratch* buffer re-generates itself
>
> It does because Emacs needs at least one buffer it can display.

As a programmer, I understand the purpose scratch buffer serves.  I also
understand that a purpose has been "thrust upon it" to make it seem
(passably) legitimate.

Make that one-true-buffer, the Emacs splash screen or banner.

Kill the banner, when (> buffer-count 0)
Generated banner, when (zerop buffer-count)

Instead of the banner buffer, one can replace it with an immutable,
empty, no-name buffer.  By immutable, I mean the user never does
anything with it apart from "seeing it" when conditions so necessitate.

> Is there anything bad about the behavior you observed?

No.

I wrote that mainly to confirm for myself what you observe above the
need for atleast one buffer.

bug#11298: Scratch buffer (Summary of Xah's proposals, as I see it)

[Jambunathan K]

Let me rephrase ideas in Xah's post -
http://lists.gnu.org/archive/html/help-gnu-emacs/2012-04/msg00260.html.

The recommendations involve,

1. "Menu->File->Visit New File" should be changed to "File->New".  This
   will create an 'Untitled N' buffer.  This will mark the buffer as
   `potentially-file-visiting'.  Specifically it will not ask for the
   name of the file.

2. Introduce "File->Save as" will mark a `potentially-file-visiting'
   buffer as a `real-file-visiting-buffer'.

3. `potentially-file-visiting-buffer' should be queried for save on
    exit.

Speaking of scratch buffer,
--------------------------

Emacs has a notion of buffers that are *not* and *never will be (?)*
file-visiting.  Their only purpose is to do THROWAWAY work ("use and
throw") with an understanding that Emacs will promise /not/ to annoy the
user with "Should I save this THROWAWAY work?  It seems valuable to me
even though you think otherwise".

(Hmm, I like the way Emacs gives primacy to throwaway work.)

1. It is useful to have scratch buffers.  Though most users will have no
   use for it.

2. There could be mutliple user-created scratch buffers and they could
   be created in multiple programming lang modes, depending on user's
   needs.  


I think, 
--------

If Emacs *deduces* file-visitedness based on the name of the buffer, I
think much of the problem could be elegantly dealt with.

1. C-x b => Create "Untitled N".  It is potentially-file-visiting.  Such
   buffers always queried on exit.

2. C-u C-x b => Creates "*throway-%s*".  Note that the default offered
   to the user names the buffer specially with leading and trailing
   asterisks, These are non-file-visiting buffers.

bug#11298: Scratch buffer (Summary of Xah's proposals, as I see it)

[Jambunathan K]

> If Emacs *deduces* file-visitedness based on the name of the buffer

Let me elaborate on what I mean by "deduction".

I think there is a rule (unwritten but understood?) on how
non-file-visiting buffers are named.  I think these rules can be entered
in law books are recognized as a precedent that cannot be breached.

In the new scheme,

A buffer created with the name "testing" will be deemed as
potentially-file-visiting, while one created with name "*testing*" will
be treated as non-file-visiting.

One has to just settle on the pattern of names that make a buffer
non-file-visiting.  Anything that doesn't match this pattern will be
potentitally-file-visiting.

bug#11298: Scratch buffer (Summary of Xah's proposals, as I see it)

[martin rudalics]

 > Emacs has a notion of buffers that are *not* and *never will be (?)*
 > file-visiting.

A user is always able to save _any_ buffer to a new file (if there's
sufficient space) so the "*never will be (?)*" is not a valid notion.

martin

bug#11298: Scratch buffer (Summary of Xah's proposals, as I see it)

[Jambunathan K]

martin rudalics <rudalics@gmx.at> writes:

>> Emacs has a notion of buffers that are *not* and *never will be (?)*
>> file-visiting.
>
> A user is always able to save _any_ buffer to a new file (if there's
> sufficient space) so the "*never will be (?)*" is not a valid notion.

What will be lost if Emacs forbids such a write? 

I can mark the buffer, switch to a file-visiting buffer and yank my
scratch contents there.

bug#11298: Scratch buffer (Summary of Xah's proposals, as I see it)

[Jan D.]

Jambunathan K skrev 2012-04-24 14:20:
>
> Let me rephrase ideas in Xah's post -
> http://lists.gnu.org/archive/html/help-gnu-emacs/2012-04/msg00260.html.
>
> The recommendations involve,
>
> 1. "Menu->File->Visit New File" should be changed to "File->New".  This
>     will create an 'Untitled N' buffer.  This will mark the buffer as
>     `potentially-file-visiting'.  Specifically it will not ask for the
>     name of the file.
>
> 2. Introduce "File->Save as" will mark a `potentially-file-visiting'
>     buffer as a `real-file-visiting-buffer'.
>
> 3. `potentially-file-visiting-buffer' should be queried for save on
>      exit.
>

Giving a file name at 1. allows Emacs to set major mode.  If there is 
just "Untitled N", the user would have to manually set major mode for 
all new files.  This is not userfriendly.

	Jan D.

bug#11298: Scratch buffer (Summary of Xah's proposals, as I see it)

[Jambunathan K]

"Jan D." <jan.h.d@swipnet.se> writes:

> Jambunathan K skrev 2012-04-24 14:20:
>>
>> Let me rephrase ideas in Xah's post -
>> http://lists.gnu.org/archive/html/help-gnu-emacs/2012-04/msg00260.html.
>>
>> The recommendations involve,
>>
>> 1. "Menu->File->Visit New File" should be changed to "File->New".  This
>>     will create an 'Untitled N' buffer.  This will mark the buffer as
>>     `potentially-file-visiting'.  Specifically it will not ask for the
>>     name of the file.
>>
>> 2. Introduce "File->Save as" will mark a `potentially-file-visiting'
>>     buffer as a `real-file-visiting-buffer'.
>>
>> 3. `potentially-file-visiting-buffer' should be queried for save on
>>      exit.
>>
>
> Giving a file name at 1. allows Emacs to set major mode.  If there is
> just "Untitled N", the user would have to manually set major mode for
> all new files.  This is not userfriendly.

Does it matter what mode an empty or almost empty file is in?  

If a user wants to exploit facilities offered by a major mode he has to
do a File->Save as.  May be Emacs can query for the modes in which a
buffer has to be opened?

bug#11298: Scratch buffer (Summary of Xah's proposals, as I see it)

[Jan D.]

Jambunathan K skrev 2012-04-24 18:26:
> "Jan D."<jan.h.d@swipnet.se>  writes:
>>
>> Giving a file name at 1. allows Emacs to set major mode.  If there is
>> just "Untitled N", the user would have to manually set major mode for
>> all new files.  This is not userfriendly.
>
> Does it matter what mode an empty or almost empty file is in?

Well, an empty file will be filled with something, be it Java, C, C++, 
Javascript, XML, SQL, Lisp or whatever.  I seldom create empty files for 
random notes.

>
> If a user wants to exploit facilities offered by a major mode he has to
> do a File->Save as.  May be Emacs can query for the modes in which a
> buffer has to be opened?

Even Eclipse and Netbeans have the ability to specify file type when 
starting a new file.  It sounds to me that what you really want is 
"Visit New Unknown File" or something like it.

	Jan D.

bug#11298: Scratch buffer (Summary of Xah's proposals, as I see it)

[Stefan Monnier]

> The recommendations involve,
> 1. "Menu->File->Visit New File" should be changed to "File->New".  This
>    will create an 'Untitled N' buffer.  This will mark the buffer as
>    `potentially-file-visiting'.  Specifically it will not ask for the
>    name of the file.
> 2. Introduce "File->Save as" will mark a `potentially-file-visiting'
>    buffer as a `real-file-visiting-buffer'.
> 3. `potentially-file-visiting-buffer' should be queried for save on
>     exit.

Other than "to do like others do", what would be the advantage?  I see
a bunch of disadvantages, starting with the choice of major-mode, the
location of auto-save files, the VC state, etc...

IOW, I think this is a case where the Emacs way is "objectively"
superior, so I'd need pretty compelling evidence to add support for such
"new file buffer whose file doesn't have a name yet".

OTOH, I'd be happy to rename "Visit New File" to something like "New"
(while keeping the behavior of requesting a file name) if that can help.

> 2. There could be mutliple user-created scratch buffers and they could
>    be created in multiple programming lang modes, depending on user's
>    needs.

While I can see users appreciating this feature, I think it'd be good
enough to offer it via a package that users could elect to use.
I.e. I'd be happy to accept patches needed to allow writing such
a package, but as for having such a feature by default, I think it's
over-engineering.

In my mind, the *scratch* used to be a kind of slash screen, and it only
exists now aside from the actual splash screen for historical reasons.
So I think the best solution is to try and hide/eliminate the
*scratch* buffer.


        Stefan

bug#11298: 24.0.95; (WISH) Re-look scratch buffers

[Jambunathan K]

OP here.  Closed.