Scratch buffer annoyance

Scratch buffer annoyance

[Chong Yidong]

This recent change leads to annoying behavior:

2007-07-02  Richard Stallman  <rms@gnu.org>

	* startup.el (command-line): Set buffer-offer-save in *scratch*
	and enable auto-save in it.

After this was checked in, I noticed Emacs kept asking me if I wanted
to save the *scratch* buffer upon each exit.  That was annoying, but
tolerable, so I just answered "no".  A while later, I happened to do
an `ls' in my home directory, and found it cluttered with 10-20
auto-save files:

#*scratch*#10823QZW#
#*scratch*#220140RY#
#*scratch*#72802aU#
...

At the very least, we should (i) offer an option to adopt the Emacs 22
behavior for the *scratch* buffer, i.e. with buffer-offer-save and
auto-save disabled, and (ii) delete the auto-save file if the user
answers "no" when asked if *scratch* should be saved.

Re: Scratch buffer annoyance

[Stefan Monnier]

> This recent change leads to annoying behavior:
> 2007-07-02  Richard Stallman  <rms@gnu.org>

> 	* startup.el (command-line): Set buffer-offer-save in *scratch*
> 	and enable auto-save in it.

> After this was checked in, I noticed Emacs kept asking me if I wanted
> to save the *scratch* buffer upon each exit.  That was annoying, but
> tolerable, so I just answered "no".  A while later, I happened to do
> an `ls' in my home directory, and found it cluttered with 10-20
> auto-save files:

> #*scratch*#10823QZW#
> #*scratch*#220140RY#
> #*scratch*#72802aU#
> ...

> At the very least, we should (i) offer an option to adopt the Emacs 22
> behavior for the *scratch* buffer, i.e. with buffer-offer-save and
> auto-save disabled, and (ii) delete the auto-save file if the user
> answers "no" when asked if *scratch* should be saved.

And also, it shouldn't be saved in the home directory but somewhere in the
.emacs.d directory.


        Stefan

Re: Scratch buffer annoyance

[Leo]

On 2007-07-06 01:06 +0100, Chong Yidong wrote:
> This recent change leads to annoying behavior:
>
> 2007-07-02  Richard Stallman  <rms@gnu.org>
>
> 	* startup.el (command-line): Set buffer-offer-save in *scratch*
> 	and enable auto-save in it.
>
> After this was checked in, I noticed Emacs kept asking me if I wanted
> to save the *scratch* buffer upon each exit.  That was annoying, but
> tolerable, so I just answered "no".  A while later, I happened to do
> an `ls' in my home directory, and found it cluttered with 10-20
> auto-save files:
>
> #*scratch*#10823QZW#
> #*scratch*#220140RY#
> #*scratch*#72802aU#
> ...
>
> At the very least, we should (i) offer an option to adopt the Emacs 22
> behavior for the *scratch* buffer, i.e. with buffer-offer-save and
> auto-save disabled, and (ii) delete the auto-save file if the user
> answers "no" when asked if *scratch* should be saved.

I agree 100%.

This new behavior is just annoying.

Everybody knows what *scratch* means. Why would someone want to save
things in scratch? Or why would they put important things in *scratch*
in the first place?

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Re: Scratch buffer annoyance

[David Reitter]

On 15 Jul 2007, at 22:37, Leo wrote:

> Everybody knows what *scratch* means. Why would someone want to save
> things in scratch? Or why would they put important things in *scratch*
> in the first place?

Many users seem to do just that. See the discussion earlier on this  
mailing list.

But why do the auto-save files have to go in ~/, and not somewhere  
where they don't annoy the user? Why is there more than one auto-save  
file? Isn't that a bug?

Why is the user asked at all whether *scratch* should be saved? That  
is annoying. If anything, *scratch* should be automatically  
persistent. It's still not meant to be a buffer that is saved to a  
user-managed file. It's just supposed to be persistent so that  
restarting Emacs doesn't have a devastating effect!

Re: Scratch buffer annoyance

[Zhang Wei]

David Reitter <david.reitter@gmail.com> writes:

[...]

> But why do the auto-save files have to go in ~/, and not somewhere
> where they don't annoy the user? Why is there more than one auto-save
> file? Isn't that a bug?

The auto-save files not just go in ~/, wherever you startup emacs,
they will to there, you will find tons of #scratch...# files scattered
everywhere in your directory tree after days of work.

I don't think it's a good idea to make *scratch* buffer auto-save.

Re: Scratch buffer annoyance

[Juri Linkov]

> But why do the auto-save files have to go in ~/, and not somewhere  where
> they don't annoy the user?

I have many backup files in ~/.emacs.d/auto-save-list/, and they don't
bother me in this directory.  So scratch backup files could go to a
special directory like ~/.emacs.d/scratch/.

> Why is there more than one auto-save file?  Isn't that a bug?

With a proper implementation, more than one auto-save file will be
necessary only for many simultaneous Emacs sessions.

> Why is the user asked at all whether *scratch* should be saved? That  is
> annoying.

I'm one of the few people who could benefit from saving the scratch buffer
because I often forget to save some "expiremental" pieces of code in it
so I need to have a window with the scratch buffer always visible
to not forget to save it, and this is inconvenient.  But the current
implementation with asking the question and leaving auto-save files
everywhere is very annoying.

> If anything, *scratch* should be automatically persistent. It's still
> not meant to be a buffer that is saved to a user-managed file. It's just
> supposed to be persistent so that restarting Emacs doesn't have
> a devastating effect!

I agree that this would be a better solution to make it automatically
persistent without asking questions.  So after restarting Emacs,
it could restore the old content of the scratch buffer, and automatically
save it after modifications.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

Our previous discussion concluded that we need to turn on auto-save in
*scratch*.

People's complaints show that some details of this need to be changed.
We need to change the details of saving and auto-saving *scratch* so
that this doesn't inconvenience users who are not interested in it.

Would people please turn attention to desiging those details?  We can
add new code in the low levels of auto-saving, if necessary, in order
to make this work in the most convenient possible way.

I am sorry that I have been too busy to fix this up further myself.

Re: Scratch buffer annoyance

[Karl Fogel]

Leo <sdl.web@gmail.com> writes:
> This new behavior is just annoying.
>
> Everybody knows what *scratch* means. Why would someone want to save
> things in scratch? Or why would they put important things in *scratch*
> in the first place?

Then the new behavior is not the right solution to a real problem.

People clearly do not know what "*scratch*" means, which isn't
surprising, considering that it behaves differently from virtually
every other text editing interface out there (they'll ask you if you
want to save unsaved work before exiting).

Re: Scratch buffer annoyance

[Alfred M. Szmidt]

   > This new behavior is just annoying.
   >
   > Everybody knows what *scratch* means. Why would someone want to
   > save things in scratch? Or why would they put important things in
   > *scratch* in the first place?

   Then the new behavior is not the right solution to a real problem.

   People clearly do not know what "*scratch*" means, which isn't
   surprising, considering that it behaves differently from virtually
   every other text editing interface out there (they'll ask you if
   you want to save unsaved work before exiting).

I sent the following suggestion, which I think is a very good solution
to the problem, but nobody commented on it.

>From ams Sat Jun 23 20:58:50 +0200 2007
From: "Alfred M. Szmidt" <ams@gnu.org>
To: rms@gnu.org
CC: dak@gnu.org, kfogel@red-bean.com, wilde@sha-bang.de,
	hacksaw@hacksaw.org, emacs-devel@gnu.org, jasonr@gnu.org
In-reply-to: <E1I2AK4-0006rB-8s@fencepost.gnu.org> (message from Richard
	Stallman on Sat, 23 Jun 2007 14:27:00 -0400)
Subject: Re: A wish, a plea
Reply-to: ams@gnu.org
References: <4679F561.4030600@hacksaw.org> <87d4zomyiw.fsf@red-bean.com>
	<m2fy4latun.fsf@kenny.sha-bang.de> <87fy4kjy0k.fsf@red-bean.com>
	<467AF6CC.2000300@gnu.org> <E1I1lwH-0007FG-OZ@fencepost.gnu.org>
	<467BFAAB.8060601@gnu.org> <E1I1r4I-0000Fj-E4@fencepost.gnu.org>
	<851wg3chsm.fsf@lola.goethe.zz> <E1I2AK4-0006rB-8s@fencepost.gnu.org>

       Making *scratch* or even something like *unnamed* readonly would
       pretty much defeat its intent.

   The principal intent of *scratch* is to be the current buffer when
   Emacs starts up.  Secondarily, it provides a place to enter notes you
   don't want to save, and eval Lisp expressions.  Making it read-only,
   so you need to type C-x C-q before inserting anything, would not spoil
   the principal intent.  It would slightly inconvenience the secondary
   intent, but that MIGHT be worth while in exchange for making it less
   likely to lose data.

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).

Currently the initial splash screen vanishes really quickly, if you
try to do anything it will vanish.  You cannot copy the URL to the
guided Emacs tour, for example.  If it was the current buffer that
didn't vanish (like *scratch*), then this wouldn't happen.

Re: Scratch buffer annoyance

[Richard Stallman]

    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?

Re: Scratch buffer annoyance

[David Reitter]

On 17 Jul 2007, at 16:05, Richard Stallman wrote:

>     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?

This will make Emacs even more difficult to use for new or occasional  
users. They would need to know a key combination just to get started.  
And it would be much more annoying than the current situation.

What's wrong with

- automatically saving *scratch* in a place other than ~/ (where it  
is out of the way)
   via auto-save and before exiting Emacs, without any user interaction
- automatically restoring *scratch* from that file upon startup (i.e.  
making it persistent)
- not offering to save it anywhere else (even though users may to C-x  
C-w and save it, thereby converting it to a normal, non-persistent  
buffer, and creating an empty *scratch* buffer automatically).

This would preserve the equivalence to a real-life scratch paper that  
one keeps on one's desk, which will not magically disappear  
overnight, but which may be filed somewhere else when needed.

It would be unobtrusive and solve the original problem.

Oh, and it should be in text-mode, because most users will not want  
to hack Elisp.

Re: Scratch buffer annoyance

[Tassilo Horn]

David Reitter <david.reitter@gmail.com> writes:

> On 17 Jul 2007, at 16:05, Richard Stallman wrote:
>
>>     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?
>
> This will make Emacs even more difficult to use for new or occasional
> users. They would need to know a key combination just to get started.
> And it would be much more annoying than the current situation.

Then all users that like the scratch buffer as it is right now would
need to `C-x C-q' on startup. And what if you don't want the
splash-screen at all?

So I like David's idea better.

> What's wrong with
>
> - automatically saving *scratch* in a place other than ~/ (where it is
> out of the way) via auto-save and before exiting Emacs, without any
> user interaction

Yes, something like ~/.emacs.d/scratch would make sense.

> - automatically restoring *scratch* from that file upon startup
> (i.e. making it persistent)

That would be very nice. Deleting the buffers contents is easy whereas
losing important scratched down work when mindlessly closing emacs is
very annoying.

> - not offering to save it anywhere else (even though users may to C-x
> C-w and save it, thereby converting it to a normal, non-persistent
> buffer, and creating an empty *scratch* buffer automatically).

And I would enable auto-saving for it, too.

> This would preserve the equivalence to a real-life scratch paper that
> one keeps on one's desk, which will not magically disappear overnight,
> but which may be filed somewhere else when needed.

I agree.

> Oh, and it should be in text-mode, because most users will not want to
> hack Elisp.

Probably, but I think it would be good if the mode was specified by a
variable, e.g. `scratch-buffer-mode' which defaulted to text-mode. So
users could easily configure what mode they want to use.

Bye,
Tassilo

Re: Scratch buffer annoyance

[Johan Bockgård]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Probably, but I think it would be good if the mode was specified by a
> variable, e.g. `scratch-buffer-mode' which defaulted to text-mode. So
> users could easily configure what mode they want to use.

initial-major-mode is a variable defined in `startup.el'.
Its value is 
lisp-interaction-mode


Documentation:
Major mode command symbol to use for the initial `*scratch*' buffer.

You can customize this variable.

-- 
Johan Bockgård

Re: Scratch buffer annoyance

[David Reitter]

On 17 Jul 2007, at 16:50, Tassilo Horn wrote:

>> Oh, and it should be in text-mode, because most users will not  
>> want to
>> hack Elisp.
>
> Probably, but I think it would be good if the mode was specified by a
> variable, e.g. `scratch-buffer-mode' which defaulted to text-mode. So
> users could easily configure what mode they want to use.

It already is, `initial-major-mode'. People could set it back to  
`lisp-interaction-mode' when needed.

Re: Scratch buffer annoyance

[Tassilo Horn]

David Reitter <david.reitter@gmail.com> writes:

Hi David,

>>> Oh, and it should be in text-mode, because most users will not want
>>> to hack Elisp.
>>
>> Probably, but I think it would be good if the mode was specified by a
>> variable, e.g. `scratch-buffer-mode' which defaulted to text-mode. So
>> users could easily configure what mode they want to use.
>
> It already is, `initial-major-mode'. People could set it back to
> lisp-interaction-mode' when needed.

Ah, then I'm satisfied with all your proposals.

Bye,
Tassilo

Re: Scratch buffer annoyance

[Robert J. Chassell]

Please remember to

 1. provide a variable to prevent automatic saving of the *scratch*
    buffer when you exit;

 2. provide a variable to set the *scratch* buffer's initial major mode
    to lisp-interaction-mode.

Then I can put those settings in my .emacs file and forget about them.
Various people, including me, use the *scratch* buffer as intended and
as documented.  Indeed, the initial-scratch-message says `This buffer
is for notes you don't want to save ...' and the buffer is in
lisp-interaction-mode.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Scratch buffer annoyance

[David Reitter]

On 17 Jul 2007, at 20:37, Robert J. Chassell wrote:

>  1. provide a variable to prevent automatic saving of the *scratch*
>     buffer when you exit;

Can we implement this as a minor mode, which could be used for other  
buffers as well? That way, users could define further persistent  
buffers that would exist across Emacs sessions. I'd find that useful.

>  2. provide a variable to set the *scratch* buffer's initial major  
> mode
>     to lisp-interaction-mode.

`initial-major-mode' already exists and does just that.

> Indeed, the initial-scratch-message says `This buffer
> is for notes you don't want to save ...' and the buffer is in
> lisp-interaction-mode.

I just don't get why people would take "notes" in lisp-interaction-mode.

Mathias Dahl wrote:

> Another popular editor, vim, seems to work just like that. No way I
> can edit as a new user of vim without following the on-screen
> instructions.

Is that a good thing? I don't think so.

Alfred M Szmidt wrote:

> That message could be in the scratch buffer, just like for the
> splash-screen.  Infact, inhibit-splash-screen would become unnecessary
> with this scheme, the splash-screen would be *scratch*.  One could
> then have a inhibit-read-only-splash-screen variable that people could
> flip to get what is the current behaviour.

Why so complicated? Perhaps one could show an empty buffer that has  
buffer-offer-save set to t and leave *scratch* the way it is. People  
would then stop using *scratch* for important stuff that should  
really be saved, but they could start writing right away.

In Aquamacs, we don't display a splash screen, but we display the GNU  
message and copyrights in the Echo area. People get a *scratch*  
buffer in text-mode with buffer-offer-save. I think this gets the  
message across and still allows people to begin their work. But  
displaying an empty buffer as described before might be even better,  
if one really doesn't like the idea of a persistent scratch pad.

Re: Scratch buffer annoyance

[Richard Stallman]

     2. provide a variable to set the *scratch* buffer's initial major mode
	to lisp-interaction-mode.

initial-major-mode.

Re: Scratch buffer annoyance

[Robert J. Chassell]

         2. provide a variable to set the *scratch* buffer's initial
            major mode to lisp-interaction-mode.

    initial-major-mode.

 * The name of the variable initial-major-mode could mislead; and,

 * the if clause that implements initial-major-mode fails unless the
   `*scratch*' buffer is in Fundamental mode.  

   (That is what the clause should do.  It is documented.  Normally,
   the buffer is in Lisp Interaction mode.  Unfortunately, the Emacs
   Lisp for the clause tells us that one of the proposals, as written,
   prevents resetting the mode of the `*scratch*' buffer.)

Firstly, the documentation for the `*scratch*' buffer says

    Major mode command symbol to use for the initial `*scratch*' buffer.

which suggests the possibility that `initial' has priority over `*scratch*'.

Secondly, emacs/lisp/startup.el says,

  ;; If *scratch* exists and init file didn't change its mode, initialize it.
  (if (get-buffer "*scratch*")
      (with-current-buffer "*scratch*"
	(if (eq major-mode 'fundamental-mode)
	    (funcall initial-major-mode))
	;; Don't lose text that users type in *scratch*.
	(setq buffer-offer-save t)
	(auto-save-mode 1)))

If the major mode is Text, the clause will not change the major mode
to the value of initial-major-mode.

There are many people who never bother to read anything.  I understand
that.  Also, I understand that the goal is to change Emacs so they do
not lose because of their lack of reading.  That is fine.

I just want to make sure that I can return to the traditional,
documented intent of `*scratch*'.  Lightning burnt out a mother board
last summer and even though I have surge protectors, I am turning off
and unplugging this computer when the weather looks dicey and I am
going away or to sleep.  Also, I frequently test a new CVS snapshot of
Emacs by doing work on it.  So I am often running into `*scratch*'
buffer annoyance and would like to end that.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Scratch buffer annoyance

[Alfred M. Szmidt]

   >>     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?
   >
   > This will make Emacs even more difficult to use for new or
   > occasional users. They would need to know a key combination just
   > to get started.  And it would be much more annoying than the
   > current situation.

   Then all users that like the scratch buffer as it is right now
   would need to `C-x C-q' on startup. And what if you don't want the
   splash-screen at all?

The splash screen can always be disabled using inhibit-splash-screen.

Re: Scratch buffer annoyance

[Tassilo Horn]

"Alfred M. Szmidt" <ams@gnu.org> writes:

Hi Alfred,

>    > This will make Emacs even more difficult to use for new or
>    > occasional users. They would need to know a key combination just
>    > to get started.  And it would be much more annoying than the
>    > current situation.
>
>    Then all users that like the scratch buffer as it is right now
>    would need to `C-x C-q' on startup. And what if you don't want the
>    splash-screen at all?
>
> The splash screen can always be disabled using inhibit-splash-screen.

Yes, I know that. But how would I get a *scratch* buffer if I've set
inhibit-splash-screen to t? Then I cannot read the "Type C-x C-q to get
a scratch buffer" message.

Well, of course I can add the command C-x C-q is bound to in the splash
screen to my ~/.emacs, but I like the fact that *scratch* is there by
default. Else a new user possibly won't find out how useful it is.

Bye,
Tassilo
-- 
A morning without coffee is like something without something else.

Re: Scratch buffer annoyance

[Alfred M. Szmidt]

   >    > This will make Emacs even more difficult to use for new or
   >    > occasional users. They would need to know a key combination
   >    > just to get started.  And it would be much more annoying
   >    > than the current situation.
   >
   >    Then all users that like the scratch buffer as it is right now
   >    would need to `C-x C-q' on startup. And what if you don't want
   >    the splash-screen at all?
   >
   > The splash screen can always be disabled using
   > inhibit-splash-screen.

   Yes, I know that. But how would I get a *scratch* buffer if I've
   set inhibit-splash-screen to t? Then I cannot read the "Type C-x
   C-q to get a scratch buffer" message.

That message could be in the scratch buffer, just like for the
splash-screen.  Infact, inhibit-splash-screen would become unnecessary
with this scheme, the splash-screen would be *scratch*.  One could
then have a inhibit-read-only-splash-screen variable that people could
flip to get what is the current behaviour.  

   Well, of course I can add the command C-x C-q is bound to in the splash
   screen to my ~/.emacs, but I like the fact that *scratch* is there by
   default. Else a new user possibly won't find out how useful it is.

New users have even less possibility to learn about emacs when the
splash-screen vanishes as soon as you do anything.  Making *scratch*
equivialent to the splash-screen, would be a good way to solve this,
and since it is read-only, those who by accident wish to use *scratch*
for non-scartch data would get beeps.

Re: Scratch buffer annoyance

[David Kastrup]

David Reitter <david.reitter@gmail.com> writes:

> On 17 Jul 2007, at 16:05, Richard Stallman wrote:
>
>>     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?
>
> This will make Emacs even more difficult to use for new or occasional
> users. They would need to know a key combination just to get started.
> And it would be much more annoying than the current situation.
>
> What's wrong with
>
> - automatically saving *scratch* in a place other than ~/ (where it is
> out of the way) via auto-save and before exiting Emacs, without any
> user interaction

That it doesn't work when one has more than one Emacs active at one
time.  It is not like we have not been through that already.

-- 
David Kastrup

Re: Scratch buffer annoyance

[David Reitter]

On 17 Jul 2007, at 17:02, David Kastrup wrote:

>  That it doesn't work when one has more than one Emacs active at one
> time.  It is not like we have not been through that already.

Then deal with that problem, e.g. by asking the user "scratch file  
changed on disk - really save?" at the end of the session.

One could even synchronize the buffer across sessions (automatic  
revert-buffer when needed). Are there no modes for collaborative  
editing around?

Re: Scratch buffer annoyance

[Richard Stallman]

    > - automatically saving *scratch* in a place other than ~/ (where it is
    > out of the way) via auto-save and before exiting Emacs, without any
    > user interaction

    That it doesn't work when one has more than one Emacs active at one
    time.  It is not like we have not been through that already.

It is easy to solve that by making the file name depend on the pid and
host name.

The code for reloading previous scratch buffers files will need to
take a certain amount of care to DTRT when there is more than one.
Including perhaps sometimes asking the user questions -- but we want
to try to avoid that if we can.

Re: Scratch buffer annoyance

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > - automatically saving *scratch* in a place other than ~/ (where it is
>     > out of the way) via auto-save and before exiting Emacs, without any
>     > user interaction
>
>     That it doesn't work when one has more than one Emacs active at one
>     time.  It is not like we have not been through that already.
>
> It is easy to solve that by making the file name depend on the pid
> and host name.

Which will make those buffers survive into the next session just how?

> The code for reloading previous scratch buffers files will need to
> take a certain amount of care to DTRT when there is more than one.
> Including perhaps sometimes asking the user questions -- but we want
> to try to avoid that if we can.

I think this is a mess asking for trouble.  We are trying to patch
around a problem that comes from some default usage pattern for
single-mode single-session applications.  Emacs with its multiple
major modes and kitchen-sink usefulness is just not suited to this
paradigm.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Scratch buffer annoyance

[Richard Stallman]

    > It is easy to solve that by making the file name depend on the pid
    > and host name.

    Which will make those buffers survive into the next session just how?

By default, only one of them can be restored.  Perhaps it should
choose the one with the latest modtime.

Most people only run one Emacs.  For them, this won't be an issue.

    I think this is a mess asking for trouble.  We are trying to patch
    around a problem that comes from some default usage pattern for
    single-mode single-session applications.  Emacs with its multiple
    major modes and kitchen-sink usefulness is just not suited to this
    paradigm.

It's not that bad a mismatch.

Re: Scratch buffer annoyance

[Alfred M. Szmidt]

   >     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?

   This will make Emacs even more difficult to use for new or
   occasional users. They would need to know a key combination just to
   get started.  And it would be much more annoying than the current
   situation.

That would be documented in the splash screen.  Right now when a new
user does anything (click the mouse, hit a key) when emacs starts up,
the splash screen vanishes and you get the unwelcoming text of the
scratch buffer.  Using C-c C-q to make the scratch buffer writable is
not required to use emacs; it is there for those who wish to have a
scratch buffer.

   What's wrong with

   - automatically saving *scratch* in a place other than ~/ (where it
     is out of the way) via auto-save and before exiting Emacs,
     without any user interaction

As other have pointed out, this won't work when you have multiple
emacses running.

   - automatically restoring *scratch* from that file upon startup
     (i.e.  making it persistent)

This defeats the whole concept of *scratch* IMHO.

   - not offering to save it anywhere else (even though users may to C-x  
     C-w and save it, thereby converting it to a normal, non-persistent  
     buffer, and creating an empty *scratch* buffer automatically).

   This would preserve the equivalence to a real-life scratch paper
   that one keeps on one's desk, which will not magically disappear
   overnight, but which may be filed somewhere else when needed.

   It would be unobtrusive and solve the original problem.

I disagree, and strongly.  It defeats the whole concept of a scratch
buffer.

Re: Scratch buffer annoyance

[David Kastrup]

"Alfred M. Szmidt" <ams@gnu.org> writes:

[...]

> That would be documented in the splash screen.  Right now when a new
> user does anything (click the mouse, hit a key) when emacs starts up,
> the splash screen vanishes and you get the unwelcoming text of the
> scratch buffer.  Using C-c C-q to make the scratch buffer writable is
> not required to use emacs; it is there for those who wish to have a
> scratch buffer.

For what it's worth: I think I would like this sort of setup very
much.  It is quite convenient.  However, there is no real logic in
replacing the buffer contents when the buffer is turned r/w, and it
does not address the original problem, namely that people seem to
blindly type into an editor they have started without any options and
complain when their work gets lost in this manner.

Now I personally don't want an "unnamed buffer" for starting stuff,
not least of all because it won't be in a suitable mode for doing so.

If the original splash screen persists read-only, however, it will
beep at any attempt of modifying it, so chances are people will read
what they should do.  If the splash screen offers "open or visit a new
file before starting to type", perhaps it will not be all bad.  And
maybe people will do it.

Sure, it means changing habits, but without a file extension to go by,
Emacs has no useful defaults for a file, anyway.

-- 
David Kastrup

Re: Scratch buffer annoyance

[Mathias Dahl]

> If the original splash screen persists read-only, however, it will
> beep at any attempt of modifying it, so chances are people will read
> what they should do.  If the splash screen offers "open or visit a new
> file before starting to type", perhaps it will not be all bad.  And
> maybe people will do it.

Another popular editor, vim, seems to work just like that. No way I
can edit as a new user of vim without following the on-screen
instructions.

Re: Scratch buffer annoyance

[Jason Rumney]

David Kastrup wrote:
> However, there is no real logic in
> replacing the buffer contents when the buffer is turned r/w

Maybe another binding could be used, C-c C-c seems to be commonly used
by mode specific "I've finished with this" type commands. The point is
to force new users into consciously choosing what they want to do next
(edit something they might want to save, or create a *scratch* buffer in
Lisp Interaction mode for its traditional purpose. More advanced users
can customize inhibit-splash-screen to avoid the extra keypresses.

Re: Scratch buffer annoyance

[Johan Bockgård]

Jason Rumney <jasonr@gnu.org> writes:

> More advanced users can customize inhibit-splash-screen to avoid the
> extra keypresses.

FWIW, I use scratch buffers in `emacs -Q' several times a day. I hope
that they will work as traditional in this situation. (As -Q implies
--no-splash, maybe the proposed scheme takes care of that
automatically.)

-- 
Johan Bockgård

Re: Scratch buffer annoyance

[Tassilo Horn]

"Alfred M. Szmidt" <ams@gnu.org> writes:

Hi Alfred,

>    What's wrong with
>
>    - automatically saving *scratch* in a place other than ~/ (where it
>      is out of the way) via auto-save and before exiting Emacs,
>      without any user interaction
>
> As other have pointed out, this won't work when you have multiple
> emacses running.

There are other modes facing the same problem. For example
`desktop-save-mode' uses a lock file and asks the user what to do.

And when multy-tty gets merged there are no good reasons to start
multiple emacsen anyway.

>    - automatically restoring *scratch* from that file upon startup
>      (i.e.  making it persistent)
>
> This defeats the whole concept of *scratch* IMHO.

I don't think so. If you scratch up some notes on a paper they will
still be there when you return to the office. (Well, maybe that depends
on the charwomen.)

And the effort to delete the contents of a buffer is not really a
matter.

>    - not offering to save it anywhere else (even though users may to C-x  
>      C-w and save it, thereby converting it to a normal, non-persistent  
>      buffer, and creating an empty *scratch* buffer automatically).
>
>    This would preserve the equivalence to a real-life scratch paper
>    that one keeps on one's desk, which will not magically disappear
>    overnight, but which may be filed somewhere else when needed.
>
>    It would be unobtrusive and solve the original problem.
>
> I disagree, and strongly.  It defeats the whole concept of a scratch
> buffer.

Well, I would like that new behavior. So users could use *scratch* to
quickly write down some todos that need to be done the next day.

Bye,
Tassilo
-- 
Chuck Norris can skeletize a cow in two minutes. 

Re: Scratch buffer annoyance

[Andreas Schwab]

Tassilo Horn <tassilo@member.fsf.org> writes:

> And when multy-tty gets merged there are no good reasons to start
> multiple emacsen anyway.

There still is.  Emacs is not multi-threaded.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Scratch buffer annoyance

[Jan Djärv]

Andreas Schwab skrev:
> Tassilo Horn <tassilo@member.fsf.org> writes:
> 
>> And when multy-tty gets merged there are no good reasons to start
>> multiple emacsen anyway.
> 
> There still is.  Emacs is not multi-threaded.
> 

I run several Emacs instances all the time so I can keep different projects 
separate and they can save desktop to different files.  I don't think 
multi-tty changes this.

	Jan D.

Re: Scratch buffer annoyance

[Tassilo Horn]

Jan Djärv <jan.h.d@swipnet.se> writes:

Hi Jan,

> I run several Emacs instances all the time so I can keep different
> projects separate and they can save desktop to different files.

Maybe filesets are something useful for you.

,----[ (info "(emacs)Filesets") ]
| If you regularly edit a certain group of files, you can define them as
| a "fileset".
`----

Bye,
Tassilo
-- 
When Bruce Banner  gets mad, he turns into the Hulk.  When the Hulk gets
mad, he turns into Chuck Norris.

Re: Scratch buffer annoyance

[Jan Djärv]

Tassilo Horn skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
> Hi Jan,
> 
>> I run several Emacs instances all the time so I can keep different
>> projects separate and they can save desktop to different files.
> 
> Maybe filesets are something useful for you.
> 
> ,----[ (info "(emacs)Filesets") ]
> | If you regularly edit a certain group of files, you can define them as
> | a "fileset".
> `----
> 

No, it is a different thing.  Say you are editing several similar source
trees, for example, Emacs HEAD, Emacs BASE_22, Emacs Unicode-2.  I wan't
different TAGS for them, different saved dekstop files, different compile
commands.  Things like speedbar are also faster in several instances instead
of moving around between trees.  Plus if there are similar files, remembering
which was xterm.c, xterm.c<2> and xterm.c<3> takes some effort.

In my day to day job (which isn't Emacs BTW :-) I usually work on 2-4 similar
branches.

	Jan D.

Re: Scratch buffer annoyance

[Richard Stallman]

    > As other have pointed out, this won't work when you have multiple
    > emacses running.

    There are other modes facing the same problem. For example
    `desktop-save-mode' uses a lock file and asks the user what to do.

Maybe the same approach would be good for preserving *scratch*.  But
this suggests another idea: ask the question just once and have it
apply to all features to preserve anything and everything from a
previous session.

Re: Scratch buffer annoyance

[Richard Stallman]

       - automatically restoring *scratch* from that file upon startup
	 (i.e.  making it persistent)

    This defeats the whole concept of *scratch* IMHO.

The concept of *scratch* is that it is a place to put notes
that are not important enough to put in a specific file.
I see no conflict between this concept and preserving it from
session to session.

Re: Scratch buffer annoyance

[Richard Stallman]

    - automatically saving *scratch* in a place other than ~/ (where it  
    is out of the way)
       via auto-save and before exiting Emacs, without any user interaction

That is a good idea, but remember that Emacs needs to create the directory
if it doesn't exist.  So just setting auto-save-file-name isn't quite enough.

    - automatically restoring *scratch* from that file upon startup (i.e.  
    making it persistent)

That could be good, but there should be a message saying
"Type M-x erase-buffer to clear this out."

    - not offering to save it anywhere else

Sure.

    Can we implement this as a minor mode, which could be used for other  
    buffers as well? That way, users could define further persistent  
    buffers that would exist across Emacs sessions. I'd find that useful.

That sounds good.

Re: Scratch buffer annoyance

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     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?

What's wrong with my original suggestion?

  (i) offer an option to adopt the Emacs 22 behavior for the *scratch*
  buffer, i.e. with buffer-offer-save and auto-save disabled, and (ii)
  delete the auto-save file if the user answers "no" when asked if
  *scratch* should be saved.

Re: Scratch buffer annoyance

[Richard Stallman]

    What's wrong with my original suggestion?

      (i) offer an option to adopt the Emacs 22 behavior for the *scratch*
      buffer, i.e. with buffer-offer-save and auto-save disabled, and (ii)
      delete the auto-save file if the user answers "no" when asked if
      *scratch* should be saved.

I understand the first point but not the second.

Regarding the first point, I am not strongly against such an option,
but that is a side issue.  The main issue is to make the default
behavior convenient.  Once we do that, the option may not be needed.

RE: Scratch buffer annoyance

[Drew Adams]

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

Re: Scratch buffer annoyance

[Juri Linkov]

> 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)

The default depends on the question what is Emacs?  If Emacs is a file
browser then the default should be to visit the HOME directory with Dired.
If Emacs is a web browser then the default should be to visit its home
page.  If Emacs is a Lisp interpreter then the default should be the
*scratch* buffer in lisp-interaction-mode (as is supposed now).

Since Emacs can do everything then the splash screen could contain links
to the most common initial actions, e.g.:

[Visit home directory]
[Open new file]
[Open buffer for notes you don't want to save]
[Emacs Tutorial]
[Emacs FAQ]
[Read the Emacs Manual]
...

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Scratch buffer annoyance

[Drew Adams]

> > 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)
>
> The default depends on the question what is Emacs?  If Emacs is a file
> browser then the default should be to visit the HOME directory with Dired.
> If Emacs is a web browser then the default should be to visit its home
> page.  If Emacs is a Lisp interpreter then the default should be the
> *scratch* buffer in lisp-interaction-mode (as is supposed now).
>
> Since Emacs can do everything then the splash screen could contain links
> to the most common initial actions, e.g.:
>
> [Visit home directory]
> [Open new file]
> [Open buffer for notes you don't want to save]
> [Emacs Tutorial]
> [Emacs FAQ]
> [Read the Emacs Manual]
> ...

Good idea: provide for more than just visiting *scratch* or a file or
directory.

But rather than putting a bunch of links on the splash page, we should
define the defcustom in such a way that users can customize it to do the
kinds of things you mention. The doc string and/or the tags of
`visit-on-startup' can make clear the kinds of things you can do.

This would be analogous to defining one's startup page for a Web browser:
some people want it to be Google, some people want it to be `blank', and so
on.

Re: Scratch buffer annoyance

[Mathias Dahl]

> Since Emacs can do everything then the splash screen could contain links
> to the most common initial actions, e.g.:
>
> [Visit home directory]
> [Open new file]
> [Open buffer for notes you don't want to save]
> [Emacs Tutorial]
> [Emacs FAQ]
> [Read the Emacs Manual]

I like that!

Re: Scratch buffer annoyance

[David Kastrup]

"Mathias Dahl" <mathias.dahl@gmail.com> writes:

>> Since Emacs can do everything then the splash screen could contain links
>> to the most common initial actions, e.g.:
>>
>> [Visit home directory]
>> [Open new file]
>> [Open buffer for notes you don't want to save]
>> [Emacs Tutorial]
>> [Emacs FAQ]
>> [Read the Emacs Manual]
>
> I like that!

Yes.  Yes, oh YES!  I'd like to add

>> [Omit this screen in future when started with a file name]

That makes clear how to get back at the information, it makes clear
that the user will _have_ to read the splash screen before getting rid
of it, and... [Breaking down in tears]

This is so beautiful.

-- 
David Kastrup

Re: Scratch buffer annoyance

[Peter Lee]

>>>> Mathias Dahl writes:

    >> Since Emacs can do everything then the splash screen could contain links
    >> to the most common initial actions, e.g.:
    >> 
    >> [Visit home directory]
    >> [Open new file]
    >> [Open buffer for notes you don't want to save]
    >> [Emacs Tutorial]
    >> [Emacs FAQ]
    >> [Read the Emacs Manual]

    > I like that!

I would like this as well...

Re: Scratch buffer annoyance

[Richard Stallman]

	>> Since Emacs can do everything then the splash screen could contain links
	>> to the most common initial actions, e.g.:
	>> 
	>> [Visit home directory]
	>> [Open new file]
	>> [Open buffer for notes you don't want to save]
	>> [Emacs Tutorial]
	>> [Emacs FAQ]
	>> [Read the Emacs Manual]

	> I like that!

    I would like this as well...

Would someone please try implementing this?  They we can see
what it is like.

RE: Scratch buffer annoyance

[Drew Adams]

> 	>> Since Emacs can do everything then the splash screen
>     >> could contain links
> 	>> to the most common initial actions, e.g.:
> 	>>
> 	>> [Visit home directory]
> 	>> [Open new file]
> 	>> [Open buffer for notes you don't want to save]
> 	>> [Emacs Tutorial]
> 	>> [Emacs FAQ]
> 	>> [Read the Emacs Manual]
>
> Would someone please try implementing this?  They we can see
> what it is like.

How about adding a link at the end: [Customize Startup Screen]?

If you choose this link, you customize `visit-on-startup'. The default value
of `visit-on-startup' could be nil, which means the splash screen (with the
links).

That way, you get the splash screen with the links, by default, and one of
the links lets you set your startup preference. No need to hunt for a way to
customize the startup screen.

Re: Scratch buffer annoyance

[Mathias Dahl]

> How about adding a link at the end: [Customize Startup Screen]?

> That way, you get the splash screen with the links, by default, and one of
> the links lets you set your startup preference. No need to hunt for a way to
> customize the startup screen.

A good idea!

Re: Scratch buffer annoyance

[David Kastrup]

"Mathias Dahl" <mathias.dahl@gmail.com> writes:

>> How about adding a link at the end: [Customize Startup Screen]?
>
>> That way, you get the splash screen with the links, by default, and one of
>> the links lets you set your startup preference. No need to hunt for a way to
>> customize the startup screen.
>
> A good idea!

We should use the startup screen group for that with the same
interface as Emacs/Options/Browse Customization groups.  In that
manner, people get kicked into using the customize browser right from
the start.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Scratch buffer annoyance

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> "Mathias Dahl" <mathias.dahl@gmail.com> writes:
>
>>> How about adding a link at the end: [Customize Startup Screen]?
>>
>>> That way, you get the splash screen with the links, by default, and one of
>>> the links lets you set your startup preference. No need to hunt for a way to
>>> customize the startup screen.
>>
>> A good idea!
>
> We should use the startup screen group for that with the same
> interface as Emacs/Options/Browse Customization groups.  In that
> manner, people get kicked into using the customize browser right from
> the start.

To clarify: the link [Customize Startup Screen] should enter the
customize browser in the right customization group.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: Scratch buffer annoyance

[Drew Adams]

> >>> How about adding a link at the end: [Customize Startup Screen]?
> >>
> >>> That way, you get the splash screen with the links, by
> >>> default, and one of the links lets you set your startup
> >>> preference. No need to hunt for a way to customize the
> >>> startup screen.
> >>
> >> A good idea!
> >
> > We should use the startup screen group for that with the same
> > interface as Emacs/Options/Browse Customization groups.  In that
> > manner, people get kicked into using the customize browser right from
> > the start.
>
> To clarify: the link [Customize Startup Screen] should enter the
> customize browser in the right customization group.

Thanks for the clarification; I understood something different from your
first post.

Even so, I'm not too sure what you mean. I think you are saying, in essence,
that we should open the book to the part of the table of contents that shows
the title of the target section, rather than opening the book directly to
that target section. The section title in the TOC is a link to the target,
but this is still an indirection.

Here are possible Customize destinations for this:

1. Open to the *Customize Browser* buffer.  I think you're proposing this.

2. Open to the *Customize Group* buffer (say *Customize Group:
convenience*).

3. Open to the *Customize Option: visit-on-startup* buffer.

For either #1 or #2, it would be important to put the cursor on the target
option and highlight that option, or else users will be easily disoriented.
It would not be enough, for instance, to just put the cursor on the option.
The user is asking for a particular tree branch, not for the forest. For #1,
the highlighting says "This is the way"; for #2, it says "You are here".

I agree that it is good, in general, to introduce users to the customize
browser. But where do you draw the line with your suggestion? Whenever the
user asks to customize a single option, should we just open the browser to a
browser display that shows that option or its group somewhere on it (and
highlight the target)? That would help introduce users to the browser, but
it would be an unnecessary inconvenience that would quickly have users
asking for a direct route.

I think we should go all the way, and get the user to the final destination
immediately: the customize entry for the target option. That would mean #2
(with highlighting of the option) or #3. I prefer #3, as it is the simplest
and least confusing for users. However, it provides the least customize
context, admittedly.

If your concern is a general one that, when a user is in a customize buffer
for a single option, or even for its group, s?he is not made aware of the
existence of the customize browser, then that is a separate issue, one that
is not specific to the startup display or to its option, `visit-on-startup'.

That concern is best dealt with by improving the final customize buffer, so
that the browser is pointed out with a link. In *Customize Option* and
*Customize Group*, instead of having just a list of links to the parent
groups, we could add a link to the *Customize Browser* too. This link would
take you to the browser, with the cursor on the current option or group and
with that option or group highlighted, to aid orientation. The link should
be near the links to the parent groups.

I think that would be a better way to introduce users to the browser than to
kick them into it when they ask to customize a single option. I do agree
that the customize browser needs more visibility - currently, it is visible
only (1) in the doc and (2) on the Options menu.

Re: Scratch buffer annoyance

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

>> >>> How about adding a link at the end: [Customize Startup Screen]?
>> >>
>> >>> That way, you get the splash screen with the links, by
>> >>> default, and one of the links lets you set your startup
>> >>> preference. No need to hunt for a way to customize the
>> >>> startup screen.
>> >>
>> >> A good idea!
>> >
>> > We should use the startup screen group for that with the same
>> > interface as Emacs/Options/Browse Customization groups.  In that
>> > manner, people get kicked into using the customize browser right from
>> > the start.
>>
>> To clarify: the link [Customize Startup Screen] should enter the
>> customize browser in the right customization group.
>
> Thanks for the clarification; I understood something different from your
> first post.
>
> Even so, I'm not too sure what you mean.

`Raised' text indicates buttons; type RET or click mouse-1
on a button to invoke its action.
Invoke [+] to expand a group, and [-] to collapse an expanded group.
Invoke the [Group], [Face], and [Option] buttons below to edit that
item in another window.

[-]-\ Group Emacs
   [+]-- Group Editing
   [+]-- Group External
   [+]-- Group Convenience
   [+]-- Group Programming
   [+]-- Group Applications
   [-]-\ Group Development
    | [+]-- Group Processes
    | [+]-- Group Lisp
    | [+]-- Group Docs
    | [+]-- Group Extensions
    | [-]-\ Group Internal
    |  | [-]-\ Group Initialization
    |  |  |  |--- Option Inhibit Splash Screen
    |  |  |  |--- Option Inhibit Startup Echo Area Message
    |  |  |  |--- Option Inhibit Default Init
    |  |  |  |--- Option Inhibit Startup Buffer Menu
    |  |  |  |--- Option Initial Major Mode
    |  |  |  |--- Option Site Run File
    |  |  |  |--- Option Initial Scratch Message
    |  |  | [+]-- Group Fancy Splash Screen
    |  |  |--- Option Default Major Mode
    |  | [+]-- Group Storage Allocation
    |  | [+]-- Group Limits
    |  | [+]-- Group Columns
    | [+]-- Group Maintenance
    | [+]-- Group Debug
   [+]-- Group Environment
   [+]-- Group Data
   [+]-- Group Files
   [+]-- Group Wp
   [+]-- Group Faces
   [+]-- Group Hypermedia
   [+]-- Group Help
   [+]-- Group Multimedia
   [+]-- Group Local
   [+]-- Group PostScript

Cursor on the "Option Inhibit Splash Screen".  Anyway, whose idea of a
cruel joke was the hierarchy
"Emacs/Development/Internal/Initialization"?  I browsed for 15 minutes
before giving up and looking directly in the dialog for the variable
(the name of which I remembered) and then stepped upwards through the
parent groups.

I mean, Emacs/Development/Internal/Initialization?!?
EMACS/DEVELOPMENT/INTERNAL/INITIALIZATION?!?

For the splash screen?

For now, I withdraw my proposal.  It would be _far_ too embarrassing
to show off _that_.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Scratch buffer annoyance

[Richard Stallman]

    I mean, Emacs/Development/Internal/Initialization?!?
    EMACS/DEVELOPMENT/INTERNAL/INITIALIZATION?!?

Instead of gagging, would you like to propose another location in the
structure?

Re: Scratch buffer annoyance

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     I mean, Emacs/Development/Internal/Initialization?!?
>     EMACS/DEVELOPMENT/INTERNAL/INITIALIZATION?!?
>
> Instead of gagging, would you like to propose another location in the
> structure?

Both Emacs/Convenience/Startup and Emacs/Environment/Startup (one can
specify multiple parent groups if I remember correctly).  But actually
not just the Startup but the whole Development/Internal customization
group is a complete misnomer since it has nothing to do with
development.  It might better be moved to Emacs/General Setup (does
not exist yet).  "General Setup" might also be a better name for parts
or all of the current Emacs/Environment group.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Scratch buffer annoyance

[Richard Stallman]

    Both Emacs/Convenience/Startup and Emacs/Environment/Startup (one can
    specify multiple parent groups if I remember correctly).

Semantically this does not fit in Convenience, but it does fit in
Environment.  Would you please move it?

      But actually
    not just the Startup but the whole Development/Internal customization
    group is a complete misnomer since it has nothing to do with
    development.

Even worse, those various things don't really have anything to do with
each other.  Most of them should be individually moved elsewhere.

Would you like to do that?

      It might better be moved to Emacs/General Setup (does
    not exist yet).

Maybe so.  Could you propose what the meaning of that group
would be?

Re: Scratch buffer annoyance

[Richard Stallman]

    1. Open to the *Customize Browser* buffer.  I think you're proposing this.

    2. Open to the *Customize Group* buffer (say *Customize Group:
    convenience*).

    3. Open to the *Customize Option: visit-on-startup* buffer.

#3 sounds too specific.  Yes, it would enable someone to turn
off the splash screen, but it wouldn't show that there are other
possibilities.

I think #2 is best.  It avoids unnecessary indirection while showing
more than just one option.

    Whenever the
    user asks to customize a single option, should we just open the browser to a
    browser display that shows that option or its group somewhere on it

That's a different issue.  When the user specifically asks to customize
one option, we should provide that option.  But here the user
would be asking to "customize the startup screen".  That is NOT
a request for one option.

RE: Scratch buffer annoyance

[Drew Adams]

>     1. Open to the *Customize Browser* buffer.  I think you're
>        proposing this.
>
>     2. Open to the *Customize Group* buffer (say *Customize Group:
>     convenience*).
>
>     3. Open to the *Customize Option: visit-on-startup* buffer.
>
> #3 sounds too specific.  Yes, it would enable someone to turn
> off the splash screen, but it wouldn't show that there are other
> possibilities.
>
> I think #2 is best.  It avoids unnecessary indirection while showing
> more than just one option.
>
>     Whenever the user asks to customize a single option, should
>     we just open the browser to a browser display that shows
>     that option or its group somewhere on it
>
> That's a different issue.  When the user specifically asks to customize
> one option, we should provide that option.  But here the user
> would be asking to "customize the startup screen".  That is NOT
> a request for one option.

It was at the time of the message you replied to - the single option was
`visit-on-startup'. However, since then, the discussion moved on.

My last proposal was that the link [Customize Startup Display] lead to
`customize-group' for a customize group `startup-display'. That buffer,
`*Customize Group: startup-display*' would show everything for the startup
display:

>   `visit-on-startup' [Hide Value] [Value Menu]
>   What to show/visit on startup.
>
>   `fancy-splash-screen' group: Go to Group
>   Fancy splash screen when Emacs starts.

With this approach, #2 above becomes the same thing: go to the customize
group, which would be `startup-display'.

Startup display deserves its own group because (1) most of the stuff in
group `initialization' has nothing to do with the startup display, and (2)
`visit-on-startup' is about the startup display, but it is not about the
`fancy-splash-screen'. This new goldilocks group is just right for
everything about the startup display. It doesn't include everything about
initialization, and it includes more than just the splash screen.

Re: Scratch buffer annoyance

[Richard Stallman]

    My last proposal was that the link [Customize Startup Display] lead to
    `customize-group' for a customize group `startup-display'. That buffer,
    `*Customize Group: startup-display*' would show everything for the startup
    display:

Sounds right to me.

Re: Scratch buffer annoyance

[Juri Linkov]

> 	>> [Visit home directory]
> 	>> [Open new file]
> 	>> [Open buffer for notes you don't want to save]
> 	>> [Emacs Tutorial]
> 	>> [Emacs FAQ]
> 	>> [Read the Emacs Manual]
>
> 	> I like that!
>
>     I would like this as well...
>
> Would someone please try implementing this?  They we can see
> what it is like.

Below is an implementation that add links for the most common tasks to the
splash screen.  This requires some related modifications: the startup
screen should be static because when the user want to clink on a link, it
shouldn't disappear just before clicking on it when it happens to be at
the same time as to show the next splash screen.  This would be annoying.
Such flashing screens are more appropriate for the About screen called
from the Help menu (later more visual effects could be added to the About
screen such as a scrolling list of Emacs authors, etc.)

Another necessary change is to allow point movements commands in the
startup splash screen to be able to move point to the link and type RET to
activate it.  Currently, any key causes the splash screen to exit, and this
key is applied to the underlying buffer.  This is very dangerous because
settings in .emacs, site-start.el or the command line could create such
a configuration that typing a key on a buffer under the splash buffer
(so the user can't see this buffer at the moment of typing because the splash
screen covers it), after typing a key on the splash screen this key gets
delegated to the underlying buffer and may cause harm in it.

OTOH, the About screen goes to another extreme, and doesn't provide a key
to exit the About screen at all.

The following patch adds a keymap common to the startup splash screen and
the About screen with keys `q' and SPC to quit from them.  It also
reverses the logic of the argument `hide-on-input' and renames it to
`static'.  As a result, the startup screen is static and contains links
to the most common tasks, and the About screen switches repeatedly between
two splash screens.  `q' and SPC quit both screens.

This patch doesn't contain more necessary changes because including them
in one patch would create a mess.  A separate patch later will add more
links to the startup screen and to normal-splash-screen, revert changes to
save *scratch* buffer, and add a new option `visit-on-startup'.

Index: lisp/startup.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/startup.el,v
retrieving revision 1.440
diff -c -r1.440 startup.el
*** lisp/startup.el	3 Jul 2007 02:54:42 -0000	1.440
--- lisp/startup.el	21 Jul 2007 18:02:14 -0000
***************
*** 1168,1174 ****
  	 :face variable-pitch
  	 ".
  
! Emacs Guided Tour\t\tSee http://www.gnu.org/software/emacs/tour/
  
  "
  	 :face (variable-pitch :weight bold)
--- 1168,1182 ----
  	 :face variable-pitch
  	 ".
  
! Emacs Guided Tour\t\tSee "
! 	 :face '(link variable-pitch)
! 	 (lambda ()
! 	   (propertize "http://www.gnu.org/software/emacs/tour/"
! 		       'keymap fancy-splash-link-keymap
! 		       'link "http://www.gnu.org/software/emacs/tour/"
! 		       'help-echo "mouse-2: browse this URL"))
! 	 :face variable-pitch
! 	 "
  
  "
  	 :face (variable-pitch :weight bold)
***************
*** 1216,1228 ****
  		 (file :tag "File")))
  
  
  ;; These are temporary storage areas for the splash screen display.
  
  (defvar fancy-current-text nil)
  (defvar fancy-splash-help-echo nil)
  (defvar fancy-splash-stop-time nil)
  (defvar fancy-splash-outer-buffer nil)
- (defvar fancy-splash-last-input-event nil)
  
  (defun fancy-splash-insert (&rest args)
    "Insert text into the current buffer, with faces.
--- 1224,1253 ----
  		 (file :tag "File")))
  
  
+ (defvar fancy-splash-keymap
+   (let ((map (make-sparse-keymap)))
+     (define-key map " " 'fancy-splash-quit)
+     (define-key map "q" 'fancy-splash-quit)
+     map)
+   "Keymap for splash screen buffer.")
+ 
+ (defvar fancy-splash-link-keymap
+   (let ((map (make-sparse-keymap)))
+     (set-keymap-parent map fancy-splash-keymap)
+     (define-key map "\C-m" 'fancy-splash-link-at-point)
+     (define-key map [mouse-2] 'fancy-splash-link-at-click)
+     (define-key map [down-mouse-2] 'ignore)
+     (define-key map [up-mouse-2] 'ignore)
+     (define-key map [follow-link] 'mouse-face)
+     map)
+   "Keymap for links in splash screen buffer.")
+ 
  ;; These are temporary storage areas for the splash screen display.
  
  (defvar fancy-current-text nil)
  (defvar fancy-splash-help-echo nil)
  (defvar fancy-splash-stop-time nil)
  (defvar fancy-splash-outer-buffer nil)
  
  (defun fancy-splash-insert (&rest args)
    "Insert text into the current buffer, with faces.
***************
*** 1297,1309 ****
       :face 'variable-pitch
       "Type "
       :face 'default
!      "Control-l"
       :face 'variable-pitch
!      " to begin editing"
!      (if (equal (buffer-name fancy-splash-outer-buffer)
! 		"*scratch*")
! 	 ".\n"
!        " your file.\n"))))
  
  (defun fancy-splash-tail ()
    "Insert the tail part of the splash screen into the current buffer."
--- 1322,1383 ----
       :face 'variable-pitch
       "Type "
       :face 'default
!      "`q'"
!      :face 'variable-pitch
!      " to quit from this screen.\n"))
!   (when (not fancy-splash-outer-buffer)
!     (fancy-splash-insert
!      ;; Insert links to the most common tasks.
!      ;; Create new file
!      :face '(link variable-pitch)
!      (lambda ()
!        (propertize "Create New File"
! 		   'keymap fancy-splash-link-keymap
! 		   'link 'find-file
! 		   'help-echo "mouse-2: create new file"))
!      :face 'default "\t\t"
       :face 'variable-pitch
!      "Visit new file.\n"
! 
!      ;; Visit home directory.
!      :face '(link variable-pitch)
!      (lambda ()
!        (propertize "Visit Home Directory"
! 		   'keymap fancy-splash-link-keymap
! 		   'link (lambda ()
! 			   (interactive)
! 			   (dired "~"))
! 		   'help-echo "mouse-2: visit home directory"))
!      :face 'default "\t"
!      :face 'variable-pitch
!      "Visit home directory.\n"
! 
!      ;; Visit scratch buffer.
!      :face '(link variable-pitch)
!      (lambda ()
!        (propertize "Visit *scratch* Buffer"
! 		   'keymap fancy-splash-link-keymap
! 		   'link (lambda ()
! 			   (interactive)
! 			   (switch-to-buffer (get-buffer-create "*scratch*")))
! 		   'help-echo "mouse-2: visit scratch buffer"))
!      :face 'default "\t"
!      :face 'variable-pitch
!      "Visit buffer for notes you don't want to save, and for Lisp evaluation.\n"
! 
!      ;; Customize this screen.
!      :face '(link variable-pitch)
!      (lambda ()
!        (propertize "Customize Startup Screen"
! 		   'keymap fancy-splash-link-keymap
! 		   'link (lambda ()
! 			   (interactive)
! 			   (customize-variable 'inhibit-splash-screen))
! 		   'help-echo "mouse-2: customize this screen"))
!      :face 'default "\t"
!      :face 'variable-pitch
!      "Use customization to disable this splash screen.\n"
!      "\n")))
  
  (defun fancy-splash-tail ()
    "Insert the tail part of the splash screen into the current buffer."
***************
*** 1343,1349 ****
      (throw 'stop-splashing nil))
    (unless fancy-current-text
      (setq fancy-current-text fancy-splash-text))
!   (let ((text (car fancy-current-text)))
      (set-buffer buffer)
      (erase-buffer)
      (if pure-space-overflow
--- 1417,1424 ----
      (throw 'stop-splashing nil))
    (unless fancy-current-text
      (setq fancy-current-text fancy-splash-text))
!   (let ((text (car fancy-current-text))
! 	(inhibit-read-only t))
      (set-buffer buffer)
      (erase-buffer)
      (if pure-space-overflow
***************
*** 1360,1432 ****
      (force-mode-line-update)
      (setq fancy-current-text (cdr fancy-current-text))))
  
! 
! (defun fancy-splash-default-action ()
!   "Stop displaying the splash screen buffer.
! This is an internal function used to turn off the splash screen after
! the user caused an input event by hitting a key or clicking with the
! mouse."
!   (interactive)
!   (if (and (memq 'down (event-modifiers last-command-event))
! 	   (eq (posn-window (event-start last-command-event))
! 	       (selected-window)))
!       ;; This is a mouse-down event in the spash screen window.
!       ;; Ignore it and consume the corresponding mouse-up event.
!       (read-event)
!     (push last-command-event unread-command-events))
!   (throw 'exit nil))
! 
! (defun fancy-splash-special-event-action ()
!   "Save the last event and stop displaying the splash screen buffer.
! This is an internal function used to turn off the splash screen after
! the user caused an input event that is bound in `special-event-map'"
    (interactive)
!   (setq fancy-splash-last-input-event last-input-event)
!   (throw 'exit nil))
  
  
! (defun fancy-splash-screens (&optional hide-on-input)
    "Display fancy splash screens when Emacs starts."
!   (if hide-on-input
        (let ((old-hourglass display-hourglass)
  	    (fancy-splash-outer-buffer (current-buffer))
  	    splash-buffer
- 	    (old-minor-mode-map-alist minor-mode-map-alist)
- 	    (old-emulation-mode-map-alists emulation-mode-map-alists)
- 	    (old-special-event-map special-event-map)
  	    (frame (fancy-splash-frame))
  	    timer)
  	(save-selected-window
  	  (select-frame frame)
! 	  (switch-to-buffer " GNU Emacs")
  	  (make-local-variable 'cursor-type)
  	  (setq splash-buffer (current-buffer))
  	  (catch 'stop-splashing
  	    (unwind-protect
! 		(let ((map (make-sparse-keymap))
! 		      (cursor-type nil))
! 		  (use-local-map map)
! 		  (define-key map [switch-frame] 'ignore)
! 		  (define-key map [t] 'fancy-splash-default-action)
! 		  (define-key map [mouse-movement] 'ignore)
! 		  (define-key map [mode-line t] 'ignore)
! 		  ;; Temporarily bind special events to
! 		  ;; fancy-splash-special-event-action so as to stop
! 		  ;; displaying splash screens with such events.
! 		  ;; Otherwise, drag-n-drop into splash screens may
! 		  ;; leave us in recursive editing with invisible
! 		  ;; cursors for a while.
! 		  (setq special-event-map (make-sparse-keymap))
! 		  (map-keymap
! 		   (lambda (key def)
! 		     (define-key special-event-map (vector key)
! 		       (if (eq def 'ignore)
! 			   'ignore
! 			 'fancy-splash-special-event-action)))
! 		   old-special-event-map)
  		  (setq display-hourglass nil
- 			minor-mode-map-alist nil
- 			emulation-mode-map-alists nil
  			buffer-undo-list t
  			mode-line-format (propertize "---- %b %-"
  						     'face 'mode-line-buffer-id)
--- 1435,1479 ----
      (force-mode-line-update)
      (setq fancy-current-text (cdr fancy-current-text))))
  
! (defun fancy-splash-quit ()
!   "Stop displaying the splash screen buffer."
    (interactive)
!   (if fancy-splash-outer-buffer
!       (throw 'exit nil)
!     (kill-buffer splash-buffer)))
  
+ (defun fancy-splash-link-at-point ()
+   "Go to the link at point."
+   (interactive)
+   (let ((link (get-text-property (point) 'link)))
+     (when link
+       (cond ((stringp link) (browse-url link))
+ 	    ((commandp link) (command-execute link))
+ 	    ((functionp link) (funcall link))))))
+ 
+ (defun fancy-splash-link-at-click (click)
+   "Follow a link where you click."
+   (interactive "e")
+   (mouse-set-point click)
+   (fancy-splash-link-at-point))
  
! (defun fancy-splash-screens (&optional static)
    "Display fancy splash screens when Emacs starts."
!   (if (not static)
        (let ((old-hourglass display-hourglass)
  	    (fancy-splash-outer-buffer (current-buffer))
  	    splash-buffer
  	    (frame (fancy-splash-frame))
  	    timer)
  	(save-selected-window
  	  (select-frame frame)
! 	  (switch-to-buffer " About GNU Emacs")
  	  (make-local-variable 'cursor-type)
  	  (setq splash-buffer (current-buffer))
  	  (catch 'stop-splashing
  	    (unwind-protect
! 		(let ((cursor-type nil))
  		  (setq display-hourglass nil
  			buffer-undo-list t
  			mode-line-format (propertize "---- %b %-"
  						     'face 'mode-line-buffer-id)
***************
*** 1435,1459 ****
  			timer (run-with-timer 0 fancy-splash-delay
  					      #'fancy-splash-screens-1
  					      splash-buffer))
  		  (message "%s" (startup-echo-area-message))
  		  (recursive-edit))
  	      (cancel-timer timer)
! 	      (setq display-hourglass old-hourglass
! 		    minor-mode-map-alist old-minor-mode-map-alist
! 		    emulation-mode-map-alists old-emulation-mode-map-alists
! 		    special-event-map old-special-event-map)
! 	      (kill-buffer splash-buffer)
! 	      (when fancy-splash-last-input-event
! 		(setq last-input-event fancy-splash-last-input-event
! 		      fancy-splash-last-input-event nil)
! 		(command-execute (lookup-key special-event-map
! 					     (vector last-input-event))
! 				 nil (vector last-input-event) t))))))
!     ;; If hide-on-input is nil, don't hide the buffer on input.
      (if (or (window-minibuffer-p)
  	    (window-dedicated-p (selected-window)))
  	(pop-to-buffer (current-buffer))
!       (switch-to-buffer "*About GNU Emacs*"))
      (setq buffer-read-only nil)
      (erase-buffer)
      (if pure-space-overflow
--- 1482,1499 ----
  			timer (run-with-timer 0 fancy-splash-delay
  					      #'fancy-splash-screens-1
  					      splash-buffer))
+ 		  (use-local-map fancy-splash-keymap)
  		  (message "%s" (startup-echo-area-message))
+ 		  (setq buffer-read-only t)
  		  (recursive-edit))
  	      (cancel-timer timer)
! 	      (setq display-hourglass old-hourglass)
! 	      (kill-buffer splash-buffer)))))
!     ;; If static is nil, don't hide the buffer on input.
      (if (or (window-minibuffer-p)
  	    (window-dedicated-p (selected-window)))
  	(pop-to-buffer (current-buffer))
!       (switch-to-buffer " GNU Emacs"))
      (setq buffer-read-only nil)
      (erase-buffer)
      (if pure-space-overflow
***************
*** 1469,1478 ****
--- 1509,1520 ----
        (delete-region (point) (point-max))
        (insert "\n")
        (fancy-splash-tail)
+       (use-local-map fancy-splash-keymap)
        (set-buffer-modified-p nil)
        (setq buffer-read-only t)
        (if (and view-read-only (not view-mode))
  	  (view-mode-enter nil 'kill-buffer))
+       (setq splash-buffer (current-buffer))
        (goto-char (point-min)))))
  
  (defun fancy-splash-frame ()
***************
*** 1507,1521 ****
  	  (> frame-height (+ image-height 19)))))))
  
  
! (defun normal-splash-screen (&optional hide-on-input)
    "Display splash screen when Emacs starts."
    (let ((prev-buffer (current-buffer)))
      (unwind-protect
! 	(with-current-buffer (get-buffer-create "GNU Emacs")
  	  (setq buffer-read-only nil)
  	  (erase-buffer)
  	  (set (make-local-variable 'tab-width) 8)
! 	  (if hide-on-input
  	      (set (make-local-variable 'mode-line-format)
  		   (propertize "---- %b %-" 'face 'mode-line-buffer-id)))
  
--- 1549,1563 ----
  	  (> frame-height (+ image-height 19)))))))
  
  
! (defun normal-splash-screen (&optional static)
    "Display splash screen when Emacs starts."
    (let ((prev-buffer (current-buffer)))
      (unwind-protect
! 	(with-current-buffer (get-buffer-create " About GNU Emacs")
  	  (setq buffer-read-only nil)
  	  (erase-buffer)
  	  (set (make-local-variable 'tab-width) 8)
! 	  (if (not static)
  	      (set (make-local-variable 'mode-line-format)
  		   (propertize "---- %b %-" 'face 'mode-line-buffer-id)))
  
***************
*** 1533,1545 ****
                 ", one component of the GNU/Linux operating system.\n"
               ", a part of the GNU operating system.\n"))
  
! 	  (if hide-on-input
  	      (insert (substitute-command-keys
  		       (concat
! 			"\nType \\[recenter] to begin editing"
! 			(if (equal (buffer-name prev-buffer) "*scratch*")
! 			    ".\n"
! 			  " your file.\n")))))
  
            (if (display-mouse-p)
                ;; The user can use the mouse to activate menus
--- 1575,1584 ----
                 ", one component of the GNU/Linux operating system.\n"
               ", a part of the GNU operating system.\n"))
  
! 	  (if (not static)
  	      (insert (substitute-command-keys
  		       (concat
! 			"\nType \\[recenter] to quit from this screen.\n"))))
  
            (if (display-mouse-p)
                ;; The user can use the mouse to activate menus
***************
*** 1657,1666 ****
  	  (if (and view-read-only (not view-mode))
  	      (view-mode-enter nil 'kill-buffer))
            (goto-char (point-min))
!           (if hide-on-input
                (if (or (window-minibuffer-p)
                        (window-dedicated-p (selected-window)))
!                   ;; If hide-on-input is nil, creating a new frame will
                    ;; generate enough events that the subsequent `sit-for'
                    ;; will immediately return anyway.
                    nil ;; (pop-to-buffer (current-buffer))
--- 1696,1705 ----
  	  (if (and view-read-only (not view-mode))
  	      (view-mode-enter nil 'kill-buffer))
            (goto-char (point-min))
!           (if (not static)
                (if (or (window-minibuffer-p)
                        (window-dedicated-p (selected-window)))
!                   ;; If static is nil, creating a new frame will
                    ;; generate enough events that the subsequent `sit-for'
                    ;; will immediately return anyway.
                    nil ;; (pop-to-buffer (current-buffer))
***************
*** 1672,1681 ****
              ;; In case the window is dedicated or something.
              (error (pop-to-buffer (current-buffer))))))
        ;; Unwind ... ensure splash buffer is killed
!       (if hide-on-input
! 	  (kill-buffer "GNU Emacs")
! 	(switch-to-buffer "GNU Emacs")
! 	(rename-buffer "*About GNU Emacs*" t)))))
  
  
  (defun startup-echo-area-message ()
--- 1711,1720 ----
              ;; In case the window is dedicated or something.
              (error (pop-to-buffer (current-buffer))))))
        ;; Unwind ... ensure splash buffer is killed
!       (if (not static)
! 	  (kill-buffer " About GNU Emacs")
! 	(switch-to-buffer " About GNU Emacs")
! 	(rename-buffer " GNU Emacs" t)))))
  
  
  (defun startup-echo-area-message ()
***************
*** 1691,1706 ****
      (message "%s" (startup-echo-area-message))))
  
  
! (defun display-splash-screen (&optional hide-on-input)
    "Display splash screen according to display.
  Fancy splash screens are used on graphic displays,
  normal otherwise.
  With a prefix argument, any user input hides the splash screen."
    (interactive "P")
    (if (use-fancy-splash-screens-p)
!       (fancy-splash-screens hide-on-input)
!     (normal-splash-screen hide-on-input)))
  
  
  (defun command-line-1 (command-line-args-left)
    (or noninteractive (input-pending-p) init-file-had-error
--- 1730,1746 ----
      (message "%s" (startup-echo-area-message))))
  
  
! (defun display-splash-screen (&optional static)
    "Display splash screen according to display.
  Fancy splash screens are used on graphic displays,
  normal otherwise.
  With a prefix argument, any user input hides the splash screen."
    (interactive "P")
    (if (use-fancy-splash-screens-p)
!       (fancy-splash-screens static)
!     (normal-splash-screen static)))
  
+ (defalias 'about-emacs 'display-splash-screen)
  
  (defun command-line-1 (command-line-args-left)
    (or noninteractive (input-pending-p) init-file-had-error

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

      This requires some related modifications: the startup
    screen should be static because when the user want to clink on a link, it
    shouldn't disappear just before clicking on it when it happens to be at
    the same time as to show the next splash screen.  This would be annoying.

I agree.  However, part of the reason why there are two fancy splash
screens is to present more information than will fit comfortably in
one.  If we don't use the current solution (switching between two
splash screens), we need another solution.

    Another necessary change is to allow point movements commands in the
    startup splash screen to be able to move point to the link and type RET to
    activate it.  Currently, any key causes the splash screen to exit, and this
    key is applied to the underlying buffer.

Obviously part of this change is that that won't happen any more.

    The following patch adds a keymap common to the startup splash screen and
    the About screen with keys `q' and SPC to quit from them.

I don't understand -- what does it mean to "quit" from the splash
screen?

    This patch doesn't contain more necessary changes because including them
    in one patch would create a mess.  A separate patch later will add more
    links to the startup screen and to normal-splash-screen, revert changes to
    save *scratch* buffer, and add a new option `visit-on-startup'.

In this one case, I think we want to see all the patches put together.
The reason is that I am not ready, now, to decide to take this route.
I might choose it once I see it in its mature form.

In other words, it is needful to develop the mature form and present
the combined patch.

Re: Scratch buffer annoyance

[Juri Linkov]

>       This requires some related modifications: the startup
>     screen should be static because when the user want to clink on a link, it
>     shouldn't disappear just before clicking on it when it happens to be at
>     the same time as to show the next splash screen.  This would be annoying.
>
> I agree.  However, part of the reason why there are two fancy splash
> screens is to present more information than will fit comfortably in
> one.  If we don't use the current solution (switching between two
> splash screens), we need another solution.

With the patch it displays both screens on one.  The second screen was just
4 additional lines, so information fits perfectly on one screen.

>     Another necessary change is to allow point movements commands in the
>     startup splash screen to be able to move point to the link and type RET to
>     activate it.  Currently, any key causes the splash screen to exit, and this
>     key is applied to the underlying buffer.
>
> Obviously part of this change is that that won't happen any more.

OK, so this is a good change.

>     The following patch adds a keymap common to the startup splash screen and
>     the About screen with keys `q' and SPC to quit from them.
>
> I don't understand -- what does it mean to "quit" from the splash
> screen?

"quit" means to kill the buffer with the splash screen.

>     This patch doesn't contain more necessary changes because including them
>     in one patch would create a mess.  A separate patch later will add more
>     links to the startup screen and to normal-splash-screen, revert changes to
>     save *scratch* buffer, and add a new option `visit-on-startup'.
>
> In this one case, I think we want to see all the patches put together.
> The reason is that I am not ready, now, to decide to take this route.
> I might choose it once I see it in its mature form.
>
> In other words, it is needful to develop the mature form and present
> the combined patch.

I'll present the combined patch after an agreement on a new
customizable option.  Is it OK to add `visit-on-startup'?
Should it obsolete `inhibit-splash-screen'?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

    With the patch it displays both screens on one.  The second screen was just
    4 additional lines, so information fits perfectly on one screen.

That is good.

    > I don't understand -- what does it mean to "quit" from the splash
    > screen?

    "quit" means to kill the buffer with the splash screen.

It seems a bit strange to speak of "quitting" in this context.

    I'll present the combined patch after an agreement on a new
    customizable option.  Is it OK to add `visit-on-startup'?

Please do!

    Should it obsolete `inhibit-splash-screen'?

No, I don't think so.

Re: Scratch buffer annoyance

[Juri Linkov]

>     I'll present the combined patch after an agreement on a new
>     customizable option.  Is it OK to add `visit-on-startup'?
>
> Please do!

In the following patch the name of the new option is `initial-buffer'.
I think it better fits to the existing option names in the same group
`initialization'.  Depending on the non-nil value of the new option
`initial-buffer' either *scratch* buffer is displayed on startup, or
a directory/file is visited.  The parent group of `initialization' was
changed from `internal' to `environment' as was suggested.  The recent
change that sets buffer-offer-save in *scratch* and enables auto-save was
reverted.

New links on the startup splash screen are the following:

Visit New File
Visit Home Directory
Visit *scratch* Buffer
Customize Startup Screen
Exit This Screen

All the rest changes are the same as I already described earlier.

Index: lisp/startup.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/startup.el,v
retrieving revision 1.442
diff -c -r1.442 startup.el
*** lisp/startup.el	24 Jul 2007 04:48:03 -0000	1.442
--- lisp/startup.el	25 Jul 2007 00:11:57 -0000
***************
*** 38,44 ****
  
  (defgroup initialization nil
    "Emacs start-up procedure."
!   :group 'internal)
  
  (defcustom inhibit-splash-screen nil
    "Non-nil inhibits the startup screen.
--- 38,54 ----
  
  (defgroup initialization nil
    "Emacs start-up procedure."
!   :group 'environment)
! 
! (defcustom initial-buffer nil
!   "Buffer to show after starting Emacs."
!   :type '(choice
!           (directory :tag "Directory"        :value "~/")
!           (file      :tag "File"             :value "~/new.txt")
!           (const     :tag "*scratch* buffer" :value "*scratch*")
!           (const     :tag "Splash screen"    nil))
!   :version "23.1"
!   :group 'initialization)
  
  (defcustom inhibit-splash-screen nil
    "Non-nil inhibits the startup screen.
***************
*** 1055,1064 ****
    (if (get-buffer "*scratch*")
        (with-current-buffer "*scratch*"
  	(if (eq major-mode 'fundamental-mode)
! 	    (funcall initial-major-mode))
! 	;; Don't lose text that users type in *scratch*.
! 	(setq buffer-offer-save t)
! 	(auto-save-mode 1)))
  
    ;; Load library for our terminal type.
    ;; User init file can set term-file-prefix to nil to prevent this.
--- 1065,1071 ----
    (if (get-buffer "*scratch*")
        (with-current-buffer "*scratch*"
  	(if (eq major-mode 'fundamental-mode)
! 	    (funcall initial-major-mode))))
  
    ;; Load library for our terminal type.
    ;; User init file can set term-file-prefix to nil to prevent this.
***************
*** 1168,1174 ****
  	 :face variable-pitch
  	 ".
  
! Emacs Guided Tour\t\tSee http://www.gnu.org/software/emacs/tour/
  
  "
  	 :face (variable-pitch :weight bold)
--- 1175,1189 ----
  	 :face variable-pitch
  	 ".
  
! Emacs Guided Tour\t\tSee "
! 	 :face '(link variable-pitch)
! 	 (lambda ()
! 	   (propertize "http://www.gnu.org/software/emacs/tour/"
! 		       'keymap fancy-splash-link-keymap
! 		       'link "http://www.gnu.org/software/emacs/tour/"
! 		       'help-echo "mouse-2: browse this URL"))
! 	 :face variable-pitch
! 	 "
  
  "
  	 :face (variable-pitch :weight bold)
***************
*** 1216,1228 ****
  		 (file :tag "File")))
  
  
  ;; These are temporary storage areas for the splash screen display.
  
  (defvar fancy-current-text nil)
  (defvar fancy-splash-help-echo nil)
  (defvar fancy-splash-stop-time nil)
  (defvar fancy-splash-outer-buffer nil)
- (defvar fancy-splash-last-input-event nil)
  
  (defun fancy-splash-insert (&rest args)
    "Insert text into the current buffer, with faces.
--- 1231,1260 ----
  		 (file :tag "File")))
  
  
+ (defvar fancy-splash-keymap
+   (let ((map (make-sparse-keymap)))
+     (define-key map " " 'fancy-splash-quit)
+     (define-key map "q" 'fancy-splash-quit)
+     map)
+   "Keymap for splash screen buffer.")
+ 
+ (defvar fancy-splash-link-keymap
+   (let ((map (make-sparse-keymap)))
+     (set-keymap-parent map fancy-splash-keymap)
+     (define-key map "\C-m" 'fancy-splash-link-at-point)
+     (define-key map [mouse-2] 'fancy-splash-link-at-click)
+     (define-key map [down-mouse-2] 'ignore)
+     (define-key map [up-mouse-2] 'ignore)
+     (define-key map [follow-link] 'mouse-face)
+     map)
+   "Keymap for links in splash screen buffer.")
+ 
  ;; These are temporary storage areas for the splash screen display.
  
  (defvar fancy-current-text nil)
  (defvar fancy-splash-help-echo nil)
  (defvar fancy-splash-stop-time nil)
  (defvar fancy-splash-outer-buffer nil)
  
  (defun fancy-splash-insert (&rest args)
    "Insert text into the current buffer, with faces.
***************
*** 1297,1309 ****
       :face 'variable-pitch
       "Type "
       :face 'default
!      "Control-l"
       :face 'variable-pitch
!      " to begin editing"
!      (if (equal (buffer-name fancy-splash-outer-buffer)
! 		"*scratch*")
! 	 ".\n"
!        " your file.\n"))))
  
  (defun fancy-splash-tail ()
    "Insert the tail part of the splash screen into the current buffer."
--- 1329,1395 ----
       :face 'variable-pitch
       "Type "
       :face 'default
!      "`q'"
       :face 'variable-pitch
!      " to quit from this screen.\n"))
!   (when (not fancy-splash-outer-buffer)
!     (fancy-splash-insert
!      ;; Insert links to the most common tasks.
! 
!      ;; Create new file
!      :face '(link variable-pitch)
!      (lambda ()
!        (propertize "Visit New File"
! 		   'keymap fancy-splash-link-keymap
! 		   'link 'find-file
! 		   'help-echo "mouse-2: visit or create a new file"))
!      :face 'default "\n"
! 
!      ;; Visit home directory.
!      :face '(link variable-pitch)
!      (lambda ()
!        (propertize "Visit Home Directory"
! 		   'keymap fancy-splash-link-keymap
! 		   'link (lambda ()
! 			   (interactive)
! 			   (find-file "~/"))
! 		   'help-echo "mouse-2: visit home directory"))
!      :face 'default "\n"
! 
!      ;; Visit scratch buffer.
!      :face '(link variable-pitch)
!      (lambda ()
!        (propertize "Visit *scratch* Buffer"
! 		   'keymap fancy-splash-link-keymap
! 		   'link (lambda ()
! 			   (interactive)
! 			   (switch-to-buffer (get-buffer-create "*scratch*")))
! 		   'help-echo "mouse-2: visit buffer for notes you don't want to save, and for Lisp evaluation"))
!      :face 'default "\n"
! 
!      ;; Customize this screen.
!      :face '(link variable-pitch)
!      (lambda ()
!        (propertize "Customize Startup Screen"
! 		   'keymap fancy-splash-link-keymap
! 		   'link (lambda ()
! 			   (interactive)
! 			   (customize-group 'initialization))
! 		   'help-echo "mouse-2: customize this screen"))
!      :face 'default "\n"
! 
!      ;; Exit this screen.
!      :face '(link variable-pitch)
!      (lambda ()
!        (propertize "Exit This Screen"
! 		   'keymap fancy-splash-link-keymap
! 		   'link (lambda ()
! 			   (interactive)
! 			   (kill-buffer splash-buffer))
! 		   'help-echo "mouse-2: exit this screen"))
!      :face 'default "\n"
! 
!      "\n")))
  
  (defun fancy-splash-tail ()
    "Insert the tail part of the splash screen into the current buffer."
***************
*** 1343,1349 ****
      (throw 'stop-splashing nil))
    (unless fancy-current-text
      (setq fancy-current-text fancy-splash-text))
!   (let ((text (car fancy-current-text)))
      (set-buffer buffer)
      (erase-buffer)
      (if pure-space-overflow
--- 1429,1436 ----
      (throw 'stop-splashing nil))
    (unless fancy-current-text
      (setq fancy-current-text fancy-splash-text))
!   (let ((text (car fancy-current-text))
! 	(inhibit-read-only t))
      (set-buffer buffer)
      (erase-buffer)
      (if pure-space-overflow
***************
*** 1360,1432 ****
      (force-mode-line-update)
      (setq fancy-current-text (cdr fancy-current-text))))
  
! 
! (defun fancy-splash-default-action ()
!   "Stop displaying the splash screen buffer.
! This is an internal function used to turn off the splash screen after
! the user caused an input event by hitting a key or clicking with the
! mouse."
!   (interactive)
!   (if (and (memq 'down (event-modifiers last-command-event))
! 	   (eq (posn-window (event-start last-command-event))
! 	       (selected-window)))
!       ;; This is a mouse-down event in the spash screen window.
!       ;; Ignore it and consume the corresponding mouse-up event.
!       (read-event)
!     (push last-command-event unread-command-events))
!   (throw 'exit nil))
! 
! (defun fancy-splash-special-event-action ()
!   "Save the last event and stop displaying the splash screen buffer.
! This is an internal function used to turn off the splash screen after
! the user caused an input event that is bound in `special-event-map'"
    (interactive)
!   (setq fancy-splash-last-input-event last-input-event)
!   (throw 'exit nil))
  
  
! (defun fancy-splash-screens (&optional hide-on-input)
    "Display fancy splash screens when Emacs starts."
!   (if hide-on-input
        (let ((old-hourglass display-hourglass)
  	    (fancy-splash-outer-buffer (current-buffer))
  	    splash-buffer
- 	    (old-minor-mode-map-alist minor-mode-map-alist)
- 	    (old-emulation-mode-map-alists emulation-mode-map-alists)
- 	    (old-special-event-map special-event-map)
  	    (frame (fancy-splash-frame))
  	    timer)
  	(save-selected-window
  	  (select-frame frame)
! 	  (switch-to-buffer " GNU Emacs")
  	  (make-local-variable 'cursor-type)
  	  (setq splash-buffer (current-buffer))
  	  (catch 'stop-splashing
  	    (unwind-protect
! 		(let ((map (make-sparse-keymap))
! 		      (cursor-type nil))
! 		  (use-local-map map)
! 		  (define-key map [switch-frame] 'ignore)
! 		  (define-key map [t] 'fancy-splash-default-action)
! 		  (define-key map [mouse-movement] 'ignore)
! 		  (define-key map [mode-line t] 'ignore)
! 		  ;; Temporarily bind special events to
! 		  ;; fancy-splash-special-event-action so as to stop
! 		  ;; displaying splash screens with such events.
! 		  ;; Otherwise, drag-n-drop into splash screens may
! 		  ;; leave us in recursive editing with invisible
! 		  ;; cursors for a while.
! 		  (setq special-event-map (make-sparse-keymap))
! 		  (map-keymap
! 		   (lambda (key def)
! 		     (define-key special-event-map (vector key)
! 		       (if (eq def 'ignore)
! 			   'ignore
! 			 'fancy-splash-special-event-action)))
! 		   old-special-event-map)
  		  (setq display-hourglass nil
- 			minor-mode-map-alist nil
- 			emulation-mode-map-alists nil
  			buffer-undo-list t
  			mode-line-format (propertize "---- %b %-"
  						     'face 'mode-line-buffer-id)
--- 1447,1491 ----
      (force-mode-line-update)
      (setq fancy-current-text (cdr fancy-current-text))))
  
! (defun fancy-splash-quit ()
!   "Stop displaying the splash screen buffer."
    (interactive)
!   (if fancy-splash-outer-buffer
!       (throw 'exit nil)
!     (kill-buffer splash-buffer)))
  
+ (defun fancy-splash-link-at-point ()
+   "Go to the link at point."
+   (interactive)
+   (let ((link (get-text-property (point) 'link)))
+     (when link
+       (cond ((stringp link) (browse-url link))
+ 	    ((commandp link) (command-execute link))
+ 	    ((functionp link) (funcall link))))))
+ 
+ (defun fancy-splash-link-at-click (click)
+   "Follow a link where you click."
+   (interactive "e")
+   (mouse-set-point click)
+   (fancy-splash-link-at-point))
  
! (defun fancy-splash-screens (&optional static)
    "Display fancy splash screens when Emacs starts."
!   (if (not static)
        (let ((old-hourglass display-hourglass)
  	    (fancy-splash-outer-buffer (current-buffer))
  	    splash-buffer
  	    (frame (fancy-splash-frame))
  	    timer)
  	(save-selected-window
  	  (select-frame frame)
! 	  (switch-to-buffer " About GNU Emacs")
  	  (make-local-variable 'cursor-type)
  	  (setq splash-buffer (current-buffer))
  	  (catch 'stop-splashing
  	    (unwind-protect
! 		(let ((cursor-type nil))
  		  (setq display-hourglass nil
  			buffer-undo-list t
  			mode-line-format (propertize "---- %b %-"
  						     'face 'mode-line-buffer-id)
***************
*** 1435,1459 ****
  			timer (run-with-timer 0 fancy-splash-delay
  					      #'fancy-splash-screens-1
  					      splash-buffer))
  		  (message "%s" (startup-echo-area-message))
  		  (recursive-edit))
  	      (cancel-timer timer)
! 	      (setq display-hourglass old-hourglass
! 		    minor-mode-map-alist old-minor-mode-map-alist
! 		    emulation-mode-map-alists old-emulation-mode-map-alists
! 		    special-event-map old-special-event-map)
! 	      (kill-buffer splash-buffer)
! 	      (when fancy-splash-last-input-event
! 		(setq last-input-event fancy-splash-last-input-event
! 		      fancy-splash-last-input-event nil)
! 		(command-execute (lookup-key special-event-map
! 					     (vector last-input-event))
! 				 nil (vector last-input-event) t))))))
!     ;; If hide-on-input is nil, don't hide the buffer on input.
      (if (or (window-minibuffer-p)
  	    (window-dedicated-p (selected-window)))
  	(pop-to-buffer (current-buffer))
!       (switch-to-buffer "*About GNU Emacs*"))
      (setq buffer-read-only nil)
      (erase-buffer)
      (if pure-space-overflow
--- 1494,1511 ----
  			timer (run-with-timer 0 fancy-splash-delay
  					      #'fancy-splash-screens-1
  					      splash-buffer))
+ 		  (use-local-map fancy-splash-keymap)
  		  (message "%s" (startup-echo-area-message))
+ 		  (setq buffer-read-only t)
  		  (recursive-edit))
  	      (cancel-timer timer)
! 	      (setq display-hourglass old-hourglass)
! 	      (kill-buffer splash-buffer)))))
!     ;; If static is nil, don't hide the buffer on input.
      (if (or (window-minibuffer-p)
  	    (window-dedicated-p (selected-window)))
  	(pop-to-buffer (current-buffer))
!       (switch-to-buffer " GNU Emacs"))
      (setq buffer-read-only nil)
      (erase-buffer)
      (if pure-space-overflow
***************
*** 1469,1478 ****
--- 1521,1532 ----
        (delete-region (point) (point-max))
        (insert "\n")
        (fancy-splash-tail)
+       (use-local-map fancy-splash-keymap)
        (set-buffer-modified-p nil)
        (setq buffer-read-only t)
        (if (and view-read-only (not view-mode))
  	  (view-mode-enter nil 'kill-buffer))
+       (setq splash-buffer (current-buffer))
        (goto-char (point-min)))))
  
  (defun fancy-splash-frame ()
***************
*** 1507,1521 ****
  	  (> frame-height (+ image-height 19)))))))
  
  
! (defun normal-splash-screen (&optional hide-on-input)
    "Display splash screen when Emacs starts."
    (let ((prev-buffer (current-buffer)))
      (unwind-protect
! 	(with-current-buffer (get-buffer-create "GNU Emacs")
  	  (setq buffer-read-only nil)
  	  (erase-buffer)
  	  (set (make-local-variable 'tab-width) 8)
! 	  (if hide-on-input
  	      (set (make-local-variable 'mode-line-format)
  		   (propertize "---- %b %-" 'face 'mode-line-buffer-id)))
  
--- 1561,1575 ----
  	  (> frame-height (+ image-height 19)))))))
  
  
! (defun normal-splash-screen (&optional static)
    "Display splash screen when Emacs starts."
    (let ((prev-buffer (current-buffer)))
      (unwind-protect
! 	(with-current-buffer (get-buffer-create " About GNU Emacs")
  	  (setq buffer-read-only nil)
  	  (erase-buffer)
  	  (set (make-local-variable 'tab-width) 8)
! 	  (if (not static)
  	      (set (make-local-variable 'mode-line-format)
  		   (propertize "---- %b %-" 'face 'mode-line-buffer-id)))
  
***************
*** 1533,1545 ****
                 ", one component of the GNU/Linux operating system.\n"
               ", a part of the GNU operating system.\n"))
  
! 	  (if hide-on-input
  	      (insert (substitute-command-keys
  		       (concat
! 			"\nType \\[recenter] to begin editing"
! 			(if (equal (buffer-name prev-buffer) "*scratch*")
! 			    ".\n"
! 			  " your file.\n")))))
  
            (if (display-mouse-p)
                ;; The user can use the mouse to activate menus
--- 1587,1596 ----
                 ", one component of the GNU/Linux operating system.\n"
               ", a part of the GNU operating system.\n"))
  
! 	  (if (not static)
  	      (insert (substitute-command-keys
  		       (concat
! 			"\nType \\[recenter] to quit from this screen.\n"))))
  
            (if (display-mouse-p)
                ;; The user can use the mouse to activate menus
***************
*** 1655,1664 ****
  	  (if (and view-read-only (not view-mode))
  	      (view-mode-enter nil 'kill-buffer))
            (goto-char (point-min))
!           (if hide-on-input
                (if (or (window-minibuffer-p)
                        (window-dedicated-p (selected-window)))
!                   ;; If hide-on-input is nil, creating a new frame will
                    ;; generate enough events that the subsequent `sit-for'
                    ;; will immediately return anyway.
                    nil ;; (pop-to-buffer (current-buffer))
--- 1706,1715 ----
  	  (if (and view-read-only (not view-mode))
  	      (view-mode-enter nil 'kill-buffer))
            (goto-char (point-min))
!           (if (not static)
                (if (or (window-minibuffer-p)
                        (window-dedicated-p (selected-window)))
!                   ;; If static is nil, creating a new frame will
                    ;; generate enough events that the subsequent `sit-for'
                    ;; will immediately return anyway.
                    nil ;; (pop-to-buffer (current-buffer))
***************
*** 1670,1679 ****
              ;; In case the window is dedicated or something.
              (error (pop-to-buffer (current-buffer))))))
        ;; Unwind ... ensure splash buffer is killed
!       (if hide-on-input
! 	  (kill-buffer "GNU Emacs")
! 	(switch-to-buffer "GNU Emacs")
! 	(rename-buffer "*About GNU Emacs*" t)))))
  
  
  (defun startup-echo-area-message ()
--- 1721,1730 ----
              ;; In case the window is dedicated or something.
              (error (pop-to-buffer (current-buffer))))))
        ;; Unwind ... ensure splash buffer is killed
!       (if (not static)
! 	  (kill-buffer " About GNU Emacs")
! 	(switch-to-buffer " About GNU Emacs")
! 	(rename-buffer " GNU Emacs" t)))))
  
  
  (defun startup-echo-area-message ()
***************
*** 1689,1704 ****
      (message "%s" (startup-echo-area-message))))
  
  
! (defun display-splash-screen (&optional hide-on-input)
    "Display splash screen according to display.
  Fancy splash screens are used on graphic displays,
  normal otherwise.
  With a prefix argument, any user input hides the splash screen."
    (interactive "P")
    (if (use-fancy-splash-screens-p)
!       (fancy-splash-screens hide-on-input)
!     (normal-splash-screen hide-on-input)))
  
  
  (defun command-line-1 (command-line-args-left)
    (or noninteractive (input-pending-p) init-file-had-error
--- 1740,1756 ----
      (message "%s" (startup-echo-area-message))))
  
  
! (defun display-splash-screen (&optional static)
    "Display splash screen according to display.
  Fancy splash screens are used on graphic displays,
  normal otherwise.
  With a prefix argument, any user input hides the splash screen."
    (interactive "P")
    (if (use-fancy-splash-screens-p)
!       (fancy-splash-screens static)
!     (normal-splash-screen static)))
  
+ (defalias 'about-emacs 'display-splash-screen)
  
  (defun command-line-1 (command-line-args-left)
    (or noninteractive (input-pending-p) init-file-had-error
***************
*** 1958,1965 ****
--- 2010,2025 ----
             (or (get-buffer-window first-file-buffer)
                 (list-buffers)))))
  
+   (when initial-buffer
+     (cond ((and (equal "*scratch*" initial-buffer)
+ 		(get-buffer "*scratch*"))
+ 	   (switch-to-buffer "*scratch*"))
+ 	  ((file-exists-p initial-buffer)
+ 	   (find-file initial-buffer))))
+ 
    ;; Maybe display a startup screen.
    (unless (or inhibit-startup-message
+ 	      initial-buffer
  	      noninteractive
  	      emacs-quick-startup)
      ;; Display a startup screen, after some preparations.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

> In the following patch the name of the new option is `initial-buffer'.
> I think it better fits to the existing option names in the same group
> `initialization'.

> Index: lisp/startup.el
              ^^^^^^^^^^

>   (defgroup initialization nil
>     "Emacs start-up procedure."
             ^^^^^^^^
> !   :group 'internal)
>   
>   (defcustom inhibit-splash-screen nil
>     "Non-nil inhibits the startup screen.
                            ^^^^^^^

>   (defgroup initialization nil
>     "Emacs start-up procedure."
             ^^^^^^^^

> ! (defcustom initial-buffer nil
> !   "Buffer to show after starting Emacs."
                            ^^^^^^^^

>   (defcustom inhibit-splash-screen nil
>     "Non-nil inhibits the startup screen.
                            ^^^^^^^

>     ;; Maybe display a startup screen.
                         ^^^^^^^

>       ;; Display a startup screen, after some preparations.
                     ^^^^^^^

Something is wrong here: DOC strings and comments very consistently
talk of "startup screen", yet the variable and group names themselves
draw from some irregular use of "initial", "initialization" and
"splash".

If all the explanations find "startup" the most understandable term to
use, there is no sense in being more creative when naming the
variables and groups.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Scratch buffer annoyance

[Juri Linkov]

>> Index: lisp/startup.el
>>             ^^^^^^^^^^
>>   (defgroup initialization nil
>>     "Emacs start-up procedure."
>>            ^^^^^^^^
>> !   :group 'internal)
>>   (defcustom inhibit-splash-screen nil
>>     "Non-nil inhibits the startup screen.
>>                            ^^^^^^^
>>   (defgroup initialization nil
>>     "Emacs start-up procedure."
>>            ^^^^^^^^
>> ! (defcustom initial-buffer nil
>> !   "Buffer to show after starting Emacs."
>>                           ^^^^^^^^
>>   (defcustom inhibit-splash-screen nil
>>     "Non-nil inhibits the startup screen.
>>                           ^^^^^^^
>>     ;; Maybe display a startup screen.
>>                        ^^^^^^^
>>       ;; Display a startup screen, after some preparations.
>>                    ^^^^^^^
>
> Something is wrong here: DOC strings and comments very consistently
> talk of "startup screen", yet the variable and group names themselves
> draw from some irregular use of "initial", "initialization" and
> "splash".

I think these names could be unified under the same name later after
achieving an agreement on the best one.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Juri Linkov]

Is it OK to install the patch I submitted three days ago?

>> Please do!
>
> In the following patch the name of the new option is `initial-buffer'.
> I think it better fits to the existing option names in the same group
> `initialization'.  Depending on the non-nil value of the new option
> `initial-buffer' either *scratch* buffer is displayed on startup, or
> a directory/file is visited.  The parent group of `initialization' was
> changed from `internal' to `environment' as was suggested.  The recent
> change that sets buffer-offer-save in *scratch* and enables auto-save was
> reverted.
>
> New links on the startup splash screen are the following:
>
> Visit New File
> Visit Home Directory
> Visit *scratch* Buffer
> Customize Startup Screen
> Exit This Screen
>
> All the rest changes are the same as I already described earlier.
>
> Index: lisp/startup.el
> ===================================================================
> RCS file: /sources/emacs/emacs/lisp/startup.el,v
> retrieving revision 1.442
> diff -c -r1.442 startup.el
> *** lisp/startup.el	24 Jul 2007 04:48:03 -0000	1.442
> --- lisp/startup.el	25 Jul 2007 00:11:57 -0000
> ***************
> *** 38,44 ****
>   
>   (defgroup initialization nil
>     "Emacs start-up procedure."
> !   :group 'internal)
>   
>   (defcustom inhibit-splash-screen nil
>     "Non-nil inhibits the startup screen.
> --- 38,54 ----
>   
>   (defgroup initialization nil
>     "Emacs start-up procedure."
> !   :group 'environment)
> ! 
> ! (defcustom initial-buffer nil
> !   "Buffer to show after starting Emacs."
> !   :type '(choice
> !           (directory :tag "Directory"        :value "~/")
> !           (file      :tag "File"             :value "~/new.txt")
> !           (const     :tag "*scratch* buffer" :value "*scratch*")
> !           (const     :tag "Splash screen"    nil))
> !   :version "23.1"
> !   :group 'initialization)
>   
>   (defcustom inhibit-splash-screen nil
>     "Non-nil inhibits the startup screen.
> ***************
> *** 1055,1064 ****
>     (if (get-buffer "*scratch*")
>         (with-current-buffer "*scratch*"
>   	(if (eq major-mode 'fundamental-mode)
> ! 	    (funcall initial-major-mode))
> ! 	;; Don't lose text that users type in *scratch*.
> ! 	(setq buffer-offer-save t)
> ! 	(auto-save-mode 1)))
>   
>     ;; Load library for our terminal type.
>     ;; User init file can set term-file-prefix to nil to prevent this.
> --- 1065,1071 ----
>     (if (get-buffer "*scratch*")
>         (with-current-buffer "*scratch*"
>   	(if (eq major-mode 'fundamental-mode)
> ! 	    (funcall initial-major-mode))))
>   
>     ;; Load library for our terminal type.
>     ;; User init file can set term-file-prefix to nil to prevent this.
> ***************
> *** 1168,1174 ****
>   	 :face variable-pitch
>   	 ".
>   
> ! Emacs Guided Tour\t\tSee http://www.gnu.org/software/emacs/tour/
>   
>   "
>   	 :face (variable-pitch :weight bold)
> --- 1175,1189 ----
>   	 :face variable-pitch
>   	 ".
>   
> ! Emacs Guided Tour\t\tSee "
> ! 	 :face '(link variable-pitch)
> ! 	 (lambda ()
> ! 	   (propertize "http://www.gnu.org/software/emacs/tour/"
> ! 		       'keymap fancy-splash-link-keymap
> ! 		       'link "http://www.gnu.org/software/emacs/tour/"
> ! 		       'help-echo "mouse-2: browse this URL"))
> ! 	 :face variable-pitch
> ! 	 "
>   
>   "
>   	 :face (variable-pitch :weight bold)
> ***************
> *** 1216,1228 ****
>   		 (file :tag "File")))
>   
>   
>   ;; These are temporary storage areas for the splash screen display.
>   
>   (defvar fancy-current-text nil)
>   (defvar fancy-splash-help-echo nil)
>   (defvar fancy-splash-stop-time nil)
>   (defvar fancy-splash-outer-buffer nil)
> - (defvar fancy-splash-last-input-event nil)
>   
>   (defun fancy-splash-insert (&rest args)
>     "Insert text into the current buffer, with faces.
> --- 1231,1260 ----
>   		 (file :tag "File")))
>   
>   
> + (defvar fancy-splash-keymap
> +   (let ((map (make-sparse-keymap)))
> +     (define-key map " " 'fancy-splash-quit)
> +     (define-key map "q" 'fancy-splash-quit)
> +     map)
> +   "Keymap for splash screen buffer.")
> + 
> + (defvar fancy-splash-link-keymap
> +   (let ((map (make-sparse-keymap)))
> +     (set-keymap-parent map fancy-splash-keymap)
> +     (define-key map "\C-m" 'fancy-splash-link-at-point)
> +     (define-key map [mouse-2] 'fancy-splash-link-at-click)
> +     (define-key map [down-mouse-2] 'ignore)
> +     (define-key map [up-mouse-2] 'ignore)
> +     (define-key map [follow-link] 'mouse-face)
> +     map)
> +   "Keymap for links in splash screen buffer.")
> + 
>   ;; These are temporary storage areas for the splash screen display.
>   
>   (defvar fancy-current-text nil)
>   (defvar fancy-splash-help-echo nil)
>   (defvar fancy-splash-stop-time nil)
>   (defvar fancy-splash-outer-buffer nil)
>   
>   (defun fancy-splash-insert (&rest args)
>     "Insert text into the current buffer, with faces.
> ***************
> *** 1297,1309 ****
>        :face 'variable-pitch
>        "Type "
>        :face 'default
> !      "Control-l"
>        :face 'variable-pitch
> !      " to begin editing"
> !      (if (equal (buffer-name fancy-splash-outer-buffer)
> ! 		"*scratch*")
> ! 	 ".\n"
> !        " your file.\n"))))
>   
>   (defun fancy-splash-tail ()
>     "Insert the tail part of the splash screen into the current buffer."
> --- 1329,1395 ----
>        :face 'variable-pitch
>        "Type "
>        :face 'default
> !      "`q'"
>        :face 'variable-pitch
> !      " to quit from this screen.\n"))
> !   (when (not fancy-splash-outer-buffer)
> !     (fancy-splash-insert
> !      ;; Insert links to the most common tasks.
> ! 
> !      ;; Create new file
> !      :face '(link variable-pitch)
> !      (lambda ()
> !        (propertize "Visit New File"
> ! 		   'keymap fancy-splash-link-keymap
> ! 		   'link 'find-file
> ! 		   'help-echo "mouse-2: visit or create a new file"))
> !      :face 'default "\n"
> ! 
> !      ;; Visit home directory.
> !      :face '(link variable-pitch)
> !      (lambda ()
> !        (propertize "Visit Home Directory"
> ! 		   'keymap fancy-splash-link-keymap
> ! 		   'link (lambda ()
> ! 			   (interactive)
> ! 			   (find-file "~/"))
> ! 		   'help-echo "mouse-2: visit home directory"))
> !      :face 'default "\n"
> ! 
> !      ;; Visit scratch buffer.
> !      :face '(link variable-pitch)
> !      (lambda ()
> !        (propertize "Visit *scratch* Buffer"
> ! 		   'keymap fancy-splash-link-keymap
> ! 		   'link (lambda ()
> ! 			   (interactive)
> ! 			   (switch-to-buffer (get-buffer-create "*scratch*")))
> ! 		   'help-echo "mouse-2: visit buffer for notes you don't want to save, and for Lisp evaluation"))
> !      :face 'default "\n"
> ! 
> !      ;; Customize this screen.
> !      :face '(link variable-pitch)
> !      (lambda ()
> !        (propertize "Customize Startup Screen"
> ! 		   'keymap fancy-splash-link-keymap
> ! 		   'link (lambda ()
> ! 			   (interactive)
> ! 			   (customize-group 'initialization))
> ! 		   'help-echo "mouse-2: customize this screen"))
> !      :face 'default "\n"
> ! 
> !      ;; Exit this screen.
> !      :face '(link variable-pitch)
> !      (lambda ()
> !        (propertize "Exit This Screen"
> ! 		   'keymap fancy-splash-link-keymap
> ! 		   'link (lambda ()
> ! 			   (interactive)
> ! 			   (kill-buffer splash-buffer))
> ! 		   'help-echo "mouse-2: exit this screen"))
> !      :face 'default "\n"
> ! 
> !      "\n")))
>   
>   (defun fancy-splash-tail ()
>     "Insert the tail part of the splash screen into the current buffer."
> ***************
> *** 1343,1349 ****
>       (throw 'stop-splashing nil))
>     (unless fancy-current-text
>       (setq fancy-current-text fancy-splash-text))
> !   (let ((text (car fancy-current-text)))
>       (set-buffer buffer)
>       (erase-buffer)
>       (if pure-space-overflow
> --- 1429,1436 ----
>       (throw 'stop-splashing nil))
>     (unless fancy-current-text
>       (setq fancy-current-text fancy-splash-text))
> !   (let ((text (car fancy-current-text))
> ! 	(inhibit-read-only t))
>       (set-buffer buffer)
>       (erase-buffer)
>       (if pure-space-overflow
> ***************
> *** 1360,1432 ****
>       (force-mode-line-update)
>       (setq fancy-current-text (cdr fancy-current-text))))
>   
> ! 
> ! (defun fancy-splash-default-action ()
> !   "Stop displaying the splash screen buffer.
> ! This is an internal function used to turn off the splash screen after
> ! the user caused an input event by hitting a key or clicking with the
> ! mouse."
> !   (interactive)
> !   (if (and (memq 'down (event-modifiers last-command-event))
> ! 	   (eq (posn-window (event-start last-command-event))
> ! 	       (selected-window)))
> !       ;; This is a mouse-down event in the spash screen window.
> !       ;; Ignore it and consume the corresponding mouse-up event.
> !       (read-event)
> !     (push last-command-event unread-command-events))
> !   (throw 'exit nil))
> ! 
> ! (defun fancy-splash-special-event-action ()
> !   "Save the last event and stop displaying the splash screen buffer.
> ! This is an internal function used to turn off the splash screen after
> ! the user caused an input event that is bound in `special-event-map'"
>     (interactive)
> !   (setq fancy-splash-last-input-event last-input-event)
> !   (throw 'exit nil))
>   
>   
> ! (defun fancy-splash-screens (&optional hide-on-input)
>     "Display fancy splash screens when Emacs starts."
> !   (if hide-on-input
>         (let ((old-hourglass display-hourglass)
>   	    (fancy-splash-outer-buffer (current-buffer))
>   	    splash-buffer
> - 	    (old-minor-mode-map-alist minor-mode-map-alist)
> - 	    (old-emulation-mode-map-alists emulation-mode-map-alists)
> - 	    (old-special-event-map special-event-map)
>   	    (frame (fancy-splash-frame))
>   	    timer)
>   	(save-selected-window
>   	  (select-frame frame)
> ! 	  (switch-to-buffer " GNU Emacs")
>   	  (make-local-variable 'cursor-type)
>   	  (setq splash-buffer (current-buffer))
>   	  (catch 'stop-splashing
>   	    (unwind-protect
> ! 		(let ((map (make-sparse-keymap))
> ! 		      (cursor-type nil))
> ! 		  (use-local-map map)
> ! 		  (define-key map [switch-frame] 'ignore)
> ! 		  (define-key map [t] 'fancy-splash-default-action)
> ! 		  (define-key map [mouse-movement] 'ignore)
> ! 		  (define-key map [mode-line t] 'ignore)
> ! 		  ;; Temporarily bind special events to
> ! 		  ;; fancy-splash-special-event-action so as to stop
> ! 		  ;; displaying splash screens with such events.
> ! 		  ;; Otherwise, drag-n-drop into splash screens may
> ! 		  ;; leave us in recursive editing with invisible
> ! 		  ;; cursors for a while.
> ! 		  (setq special-event-map (make-sparse-keymap))
> ! 		  (map-keymap
> ! 		   (lambda (key def)
> ! 		     (define-key special-event-map (vector key)
> ! 		       (if (eq def 'ignore)
> ! 			   'ignore
> ! 			 'fancy-splash-special-event-action)))
> ! 		   old-special-event-map)
>   		  (setq display-hourglass nil
> - 			minor-mode-map-alist nil
> - 			emulation-mode-map-alists nil
>   			buffer-undo-list t
>   			mode-line-format (propertize "---- %b %-"
>   						     'face 'mode-line-buffer-id)
> --- 1447,1491 ----
>       (force-mode-line-update)
>       (setq fancy-current-text (cdr fancy-current-text))))
>   
> ! (defun fancy-splash-quit ()
> !   "Stop displaying the splash screen buffer."
>     (interactive)
> !   (if fancy-splash-outer-buffer
> !       (throw 'exit nil)
> !     (kill-buffer splash-buffer)))
>   
> + (defun fancy-splash-link-at-point ()
> +   "Go to the link at point."
> +   (interactive)
> +   (let ((link (get-text-property (point) 'link)))
> +     (when link
> +       (cond ((stringp link) (browse-url link))
> + 	    ((commandp link) (command-execute link))
> + 	    ((functionp link) (funcall link))))))
> + 
> + (defun fancy-splash-link-at-click (click)
> +   "Follow a link where you click."
> +   (interactive "e")
> +   (mouse-set-point click)
> +   (fancy-splash-link-at-point))
>   
> ! (defun fancy-splash-screens (&optional static)
>     "Display fancy splash screens when Emacs starts."
> !   (if (not static)
>         (let ((old-hourglass display-hourglass)
>   	    (fancy-splash-outer-buffer (current-buffer))
>   	    splash-buffer
>   	    (frame (fancy-splash-frame))
>   	    timer)
>   	(save-selected-window
>   	  (select-frame frame)
> ! 	  (switch-to-buffer " About GNU Emacs")
>   	  (make-local-variable 'cursor-type)
>   	  (setq splash-buffer (current-buffer))
>   	  (catch 'stop-splashing
>   	    (unwind-protect
> ! 		(let ((cursor-type nil))
>   		  (setq display-hourglass nil
>   			buffer-undo-list t
>   			mode-line-format (propertize "---- %b %-"
>   						     'face 'mode-line-buffer-id)
> ***************
> *** 1435,1459 ****
>   			timer (run-with-timer 0 fancy-splash-delay
>   					      #'fancy-splash-screens-1
>   					      splash-buffer))
>   		  (message "%s" (startup-echo-area-message))
>   		  (recursive-edit))
>   	      (cancel-timer timer)
> ! 	      (setq display-hourglass old-hourglass
> ! 		    minor-mode-map-alist old-minor-mode-map-alist
> ! 		    emulation-mode-map-alists old-emulation-mode-map-alists
> ! 		    special-event-map old-special-event-map)
> ! 	      (kill-buffer splash-buffer)
> ! 	      (when fancy-splash-last-input-event
> ! 		(setq last-input-event fancy-splash-last-input-event
> ! 		      fancy-splash-last-input-event nil)
> ! 		(command-execute (lookup-key special-event-map
> ! 					     (vector last-input-event))
> ! 				 nil (vector last-input-event) t))))))
> !     ;; If hide-on-input is nil, don't hide the buffer on input.
>       (if (or (window-minibuffer-p)
>   	    (window-dedicated-p (selected-window)))
>   	(pop-to-buffer (current-buffer))
> !       (switch-to-buffer "*About GNU Emacs*"))
>       (setq buffer-read-only nil)
>       (erase-buffer)
>       (if pure-space-overflow
> --- 1494,1511 ----
>   			timer (run-with-timer 0 fancy-splash-delay
>   					      #'fancy-splash-screens-1
>   					      splash-buffer))
> + 		  (use-local-map fancy-splash-keymap)
>   		  (message "%s" (startup-echo-area-message))
> + 		  (setq buffer-read-only t)
>   		  (recursive-edit))
>   	      (cancel-timer timer)
> ! 	      (setq display-hourglass old-hourglass)
> ! 	      (kill-buffer splash-buffer)))))
> !     ;; If static is nil, don't hide the buffer on input.
>       (if (or (window-minibuffer-p)
>   	    (window-dedicated-p (selected-window)))
>   	(pop-to-buffer (current-buffer))
> !       (switch-to-buffer " GNU Emacs"))
>       (setq buffer-read-only nil)
>       (erase-buffer)
>       (if pure-space-overflow
> ***************
> *** 1469,1478 ****
> --- 1521,1532 ----
>         (delete-region (point) (point-max))
>         (insert "\n")
>         (fancy-splash-tail)
> +       (use-local-map fancy-splash-keymap)
>         (set-buffer-modified-p nil)
>         (setq buffer-read-only t)
>         (if (and view-read-only (not view-mode))
>   	  (view-mode-enter nil 'kill-buffer))
> +       (setq splash-buffer (current-buffer))
>         (goto-char (point-min)))))
>   
>   (defun fancy-splash-frame ()
> ***************
> *** 1507,1521 ****
>   	  (> frame-height (+ image-height 19)))))))
>   
>   
> ! (defun normal-splash-screen (&optional hide-on-input)
>     "Display splash screen when Emacs starts."
>     (let ((prev-buffer (current-buffer)))
>       (unwind-protect
> ! 	(with-current-buffer (get-buffer-create "GNU Emacs")
>   	  (setq buffer-read-only nil)
>   	  (erase-buffer)
>   	  (set (make-local-variable 'tab-width) 8)
> ! 	  (if hide-on-input
>   	      (set (make-local-variable 'mode-line-format)
>   		   (propertize "---- %b %-" 'face 'mode-line-buffer-id)))
>   
> --- 1561,1575 ----
>   	  (> frame-height (+ image-height 19)))))))
>   
>   
> ! (defun normal-splash-screen (&optional static)
>     "Display splash screen when Emacs starts."
>     (let ((prev-buffer (current-buffer)))
>       (unwind-protect
> ! 	(with-current-buffer (get-buffer-create " About GNU Emacs")
>   	  (setq buffer-read-only nil)
>   	  (erase-buffer)
>   	  (set (make-local-variable 'tab-width) 8)
> ! 	  (if (not static)
>   	      (set (make-local-variable 'mode-line-format)
>   		   (propertize "---- %b %-" 'face 'mode-line-buffer-id)))
>   
> ***************
> *** 1533,1545 ****
>                  ", one component of the GNU/Linux operating system.\n"
>                ", a part of the GNU operating system.\n"))
>   
> ! 	  (if hide-on-input
>   	      (insert (substitute-command-keys
>   		       (concat
> ! 			"\nType \\[recenter] to begin editing"
> ! 			(if (equal (buffer-name prev-buffer) "*scratch*")
> ! 			    ".\n"
> ! 			  " your file.\n")))))
>   
>             (if (display-mouse-p)
>                 ;; The user can use the mouse to activate menus
> --- 1587,1596 ----
>                  ", one component of the GNU/Linux operating system.\n"
>                ", a part of the GNU operating system.\n"))
>   
> ! 	  (if (not static)
>   	      (insert (substitute-command-keys
>   		       (concat
> ! 			"\nType \\[recenter] to quit from this screen.\n"))))
>   
>             (if (display-mouse-p)
>                 ;; The user can use the mouse to activate menus
> ***************
> *** 1655,1664 ****
>   	  (if (and view-read-only (not view-mode))
>   	      (view-mode-enter nil 'kill-buffer))
>             (goto-char (point-min))
> !           (if hide-on-input
>                 (if (or (window-minibuffer-p)
>                         (window-dedicated-p (selected-window)))
> !                   ;; If hide-on-input is nil, creating a new frame will
>                     ;; generate enough events that the subsequent `sit-for'
>                     ;; will immediately return anyway.
>                     nil ;; (pop-to-buffer (current-buffer))
> --- 1706,1715 ----
>   	  (if (and view-read-only (not view-mode))
>   	      (view-mode-enter nil 'kill-buffer))
>             (goto-char (point-min))
> !           (if (not static)
>                 (if (or (window-minibuffer-p)
>                         (window-dedicated-p (selected-window)))
> !                   ;; If static is nil, creating a new frame will
>                     ;; generate enough events that the subsequent `sit-for'
>                     ;; will immediately return anyway.
>                     nil ;; (pop-to-buffer (current-buffer))
> ***************
> *** 1670,1679 ****
>               ;; In case the window is dedicated or something.
>               (error (pop-to-buffer (current-buffer))))))
>         ;; Unwind ... ensure splash buffer is killed
> !       (if hide-on-input
> ! 	  (kill-buffer "GNU Emacs")
> ! 	(switch-to-buffer "GNU Emacs")
> ! 	(rename-buffer "*About GNU Emacs*" t)))))
>   
>   
>   (defun startup-echo-area-message ()
> --- 1721,1730 ----
>               ;; In case the window is dedicated or something.
>               (error (pop-to-buffer (current-buffer))))))
>         ;; Unwind ... ensure splash buffer is killed
> !       (if (not static)
> ! 	  (kill-buffer " About GNU Emacs")
> ! 	(switch-to-buffer " About GNU Emacs")
> ! 	(rename-buffer " GNU Emacs" t)))))
>   
>   
>   (defun startup-echo-area-message ()
> ***************
> *** 1689,1704 ****
>       (message "%s" (startup-echo-area-message))))
>   
>   
> ! (defun display-splash-screen (&optional hide-on-input)
>     "Display splash screen according to display.
>   Fancy splash screens are used on graphic displays,
>   normal otherwise.
>   With a prefix argument, any user input hides the splash screen."
>     (interactive "P")
>     (if (use-fancy-splash-screens-p)
> !       (fancy-splash-screens hide-on-input)
> !     (normal-splash-screen hide-on-input)))
>   
>   
>   (defun command-line-1 (command-line-args-left)
>     (or noninteractive (input-pending-p) init-file-had-error
> --- 1740,1756 ----
>       (message "%s" (startup-echo-area-message))))
>   
>   
> ! (defun display-splash-screen (&optional static)
>     "Display splash screen according to display.
>   Fancy splash screens are used on graphic displays,
>   normal otherwise.
>   With a prefix argument, any user input hides the splash screen."
>     (interactive "P")
>     (if (use-fancy-splash-screens-p)
> !       (fancy-splash-screens static)
> !     (normal-splash-screen static)))
>   
> + (defalias 'about-emacs 'display-splash-screen)
>   
>   (defun command-line-1 (command-line-args-left)
>     (or noninteractive (input-pending-p) init-file-had-error
> ***************
> *** 1958,1965 ****
> --- 2010,2025 ----
>              (or (get-buffer-window first-file-buffer)
>                  (list-buffers)))))
>   
> +   (when initial-buffer
> +     (cond ((and (equal "*scratch*" initial-buffer)
> + 		(get-buffer "*scratch*"))
> + 	   (switch-to-buffer "*scratch*"))
> + 	  ((file-exists-p initial-buffer)
> + 	   (find-file initial-buffer))))
> + 
>     ;; Maybe display a startup screen.
>     (unless (or inhibit-startup-message
> + 	      initial-buffer
>   	      noninteractive
>   	      emacs-quick-startup)
>       ;; Display a startup screen, after some preparations.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

    > ! (defcustom initial-buffer nil
    > !   "Buffer to show after starting Emacs."
    > !   :type '(choice
    > !           (directory :tag "Directory"        :value "~/")
    > !           (file      :tag "File"             :value "~/new.txt")
    > !           (const     :tag "*scratch* buffer" :value "*scratch*")
    > !           (const     :tag "Splash screen"    nil))

That variable name is misleading because the value is not a buffer.
Please change the variable name to one that fits the meaning.

Aside from that, it seems plausible, but I'd like people
to try it and report on it before it is installed.

Re: Scratch buffer annoyance

[Juri Linkov]

>     > ! (defcustom initial-buffer nil
>     > !   "Buffer to show after starting Emacs."
>     > !   :type '(choice
>     > !           (directory :tag "Directory"        :value "~/")
>     > !           (file      :tag "File"             :value "~/new.txt")
>     > !           (const     :tag "*scratch* buffer" :value "*scratch*")
>     > !           (const     :tag "Splash screen"    nil))
>
> That variable name is misleading because the value is not a buffer.
> Please change the variable name to one that fits the meaning.

The name `initial-buffer' means what the current buffer the user gets
after startup: a buffer with the home directory, a buffer with some
specified file, the *scratch* buffer, or the buffer with startup screen.

I don't see a better name.  Maybe, `initial-display-buffer' or
`initial-current-buffer'?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>>     > ! (defcustom initial-buffer nil
>>     > !   "Buffer to show after starting Emacs."
>>     > !   :type '(choice
>>     > !           (directory :tag "Directory"        :value "~/")
>>     > !           (file      :tag "File"             :value "~/new.txt")
>>     > !           (const     :tag "*scratch* buffer" :value "*scratch*")
>>     > !           (const     :tag "Splash screen"    nil))
>>
>> That variable name is misleading because the value is not a buffer.
>> Please change the variable name to one that fits the meaning.
>
> The name `initial-buffer' means what the current buffer the user gets
> after startup: a buffer with the home directory, a buffer with some
> specified file, the *scratch* buffer, or the buffer with startup screen.
>
> I don't see a better name.  Maybe, `initial-display-buffer' or
> `initial-current-buffer'?

initial-visit maybe?  Actually, "*scratch*" is a value with a
different logic, so one should perhaps explain what makes it special.
I could not guess, for example, what "*Messages*" would do here.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: Scratch buffer annoyance

[Drew Adams]

> >>     > ! (defcustom initial-buffer nil
> >>
> >> That variable name is misleading because the value is not a buffer.
> >> Please change the variable name to one that fits the meaning.
> >
> > The name `initial-buffer' means what the current buffer the user gets
> > after startup: a buffer with the home directory, a buffer with some
> > specified file, the *scratch* buffer, or the buffer with startup screen.
> >
> > I don't see a better name.  Maybe, `initial-display-buffer' or
> > `initial-current-buffer'?
>
> initial-visit maybe?


1. `visit-on-startup' (the original proposal).

Or `show-on-startup' if you don't like "visit". As David pointed out,
"startup" is clear and is consistently used to describe the startup stuff in
doc strings. If you reject "startup" and insist on "initial", then
`visit-initially' or `show-initially'.


2. Many newbies won't even know at this point what a buffer is. "*scratch*"
won't mean much to them either, but calling it a "Lisp buffer" or, better, a
"scratch Lisp buffer" will give them an idea what it is.


3. And the verbs "create", "visit", and "read" are not needed. It's obvious
what you do with each of these: new file, directory, scratch buffer,
tutorial, FAQ, manual.

So, as I suggested earlier, keep it simple:

>  [New File]
>  [Directory]
>  [Scratch Lisp Buffer]
>  [Tutorial]
>  [FAQ]
>  [Manual]
>  [Customize Startup Display]

Re: Scratch buffer annoyance

[Richard Stallman]

    The name `initial-buffer' means what the current buffer the user gets
    after startup: a buffer with the home directory, a buffer with some
    specified file, the *scratch* buffer, or the buffer with startup screen.

    I don't see a better name.  Maybe, `initial-display-buffer' or
    `initial-current-buffer'?

Those names are no better.  The problem is in the word "buffer".  The
value is never a buffer.

    >>     > !           (const     :tag "*scratch* buffer" :value "*scratch*")
    >>     > !           (const     :tag "Splash screen"    nil))
    >>
    >> That variable name is misleading because the value is not a buffer.
    >> Please change the variable name to one that fits the meaning.
    >
    > The name `initial-buffer' means what the current buffer the user gets
    > after startup: a buffer with the home directory, a buffer with some
    > specified file, the *scratch* buffer, or the buffer with startup screen.
    >
    > I don't see a better name.  Maybe, `initial-display-buffer' or
    > `initial-current-buffer'?

    initial-visit maybe?  Actually, "*scratch*" is a value with a
    different logic, so one should perhaps explain what makes it special.
    I could not guess, for example, what "*Messages*" would do here.

It should treat all strings alike -- as file names.
The value that means "scratch buffer" should not be a string.

Here's an idea: if the value is a non-nil symbol, create a buffer called
`*scratch*' and put it in that mode.  Thus, the value that stands
for the current scratch buffer would be `lisp-interaction-mode'.

Re: Scratch buffer annoyance

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
>> That variable name is misleading because the value is not a buffer.
>> Please change the variable name to one that fits the meaning.
>
> I don't see a better name.  Maybe, `initial-display-buffer' or
> `initial-current-buffer'?

`initial-buffer-name'

-Miles

-- 
80% of success is just showing up.  --Woody Allen

Re: Scratch buffer annoyance

[Stefan Monnier]

>>> That variable name is misleading because the value is not a buffer.
>>> Please change the variable name to one that fits the meaning.
>> 
>> I don't see a better name.  Maybe, `initial-display-buffer' or
>> `initial-current-buffer'?

> `initial-buffer-name'

Since it's not a name, that's probably not the best choice either.
How 'bout initial-buffer-content?  initial-buffer-target?
initial-buffer-specification?


        Stefan

Re: Scratch buffer annoyance

[David Kastrup]

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

>>>> That variable name is misleading because the value is not a buffer.
>>>> Please change the variable name to one that fits the meaning.
>>> 
>>> I don't see a better name.  Maybe, `initial-display-buffer' or
>>> `initial-current-buffer'?
>
>> `initial-buffer-name'
>
> Since it's not a name, that's probably not the best choice either.
> How 'bout initial-buffer-content?  initial-buffer-target?
> initial-buffer-specification?

startup-item

-- 
David Kastrup

Re: Scratch buffer annoyance

[Richard Stallman]

    > Since it's not a name, that's probably not the best choice either.
    > How 'bout initial-buffer-content?  initial-buffer-target?
    > initial-buffer-specification?

    startup-item

"Item" doesn't say much.   `initial-buffer-contents'
or `startup-buffer-contents' seem to be the best ideas so far.

(It should be "contents", not "content".)

Re: Scratch buffer annoyance

[Miles Bader]

-- 
`The suburb is an obsolete and contradictory form of human settlement'

Re: Scratch buffer annoyance

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> I don't see a better name.  Maybe, `initial-display-buffer' or
>>> `initial-current-buffer'?
>
>> `initial-buffer-name'
>
> Since it's not a name, that's probably not the best choice either.
> How 'bout initial-buffer-content?  initial-buffer-target?
> initial-buffer-specification?

Oh, whoops... :-)

Yeah, then I agree, `initial-buffer-contents' seems best.

-Miles

-- 
`Life is a boundless sea of bitterness'

RE: Scratch buffer annoyance

[Drew Adams]

> >>> That variable name is misleading because the value is not a buffer.
> >>> Please change the variable name to one that fits the meaning.
> >>
> >> I don't see a better name.  Maybe, `initial-display-buffer' or
> >> `initial-current-buffer'?
>
> > `initial-buffer-name'
>
> Since it's not a name, that's probably not the best choice either.
> How 'bout initial-buffer-content?  initial-buffer-target?
> initial-buffer-specification?

This is the craziest thread. Much ado about nothing.

Everyone seems to be tip-toeing around using a string that names a buffer as
a possible value. Why? Having a :tag that describes the value as `Buffer' is
not a problem - it is just a tag. Customize controls the type, enforcing a
string value.

It will be obvious to users that the value is a buffer name, not a buffer.
If there is any doubt, then the doc string is the place to point that out.
If a user can provide a file name, then why not a buffer name? I don't get
it.

Something like this is what we should use (change the option name, if you
must):

(defcustom visit-on-startup nil
  "What Emacs visits when it starts up.
A non-nil value is a string naming a directory, file, or buffer to visit.
If nil, then the splash screen is displayed."
  :type '(choice
          (directory :tag "Directory"      :value "~/")
          (file      :tag "File"           :value "~/new.txt")
          (string    :tag "Buffer"         :value "*scratch*")
          (const     :tag "Splash Screen"  nil))
  :group 'startup-display)

The value is a string or nil. If you choose `Buffer', then you can enter any
string (without completion). If the string names a buffer that exists at
startup, such as *scratch* or *Messages*, then that buffer is visited (in
the proper mode). If the string names a nonexistent buffer, then that buffer
is created and visited.

What am I missing? Why is this thread so Byzantine?

Re: Scratch buffer annoyance

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

> (defcustom visit-on-startup nil
>   "What Emacs visits when it starts up.
> A non-nil value is a string naming a directory, file, or buffer to visit.
> If nil, then the splash screen is displayed."
>   :type '(choice
>           (directory :tag "Directory"      :value "~/")
>           (file      :tag "File"           :value "~/new.txt")
>           (string    :tag "Buffer"         :value "*scratch*")
>           (const     :tag "Splash Screen"  nil))
>   :group 'startup-display)
>
> The value is a string or nil. If you choose `Buffer', then you can enter any
> string (without completion). If the string names a buffer that exists at
> startup, such as *scratch* or *Messages*, then that buffer is visited (in
> the proper mode). If the string names a nonexistent buffer, then that buffer
> is created and visited.

You mean: then that _file_ is visited.  It does not make sense to
visit a buffer.

> What am I missing? Why is this thread so Byzantine?

What does "exist at startup" mean?  At the time the splash screen
might get displayed, .emacs is already processed, and any number of
buffers might be loaded already (including a whole desktop).  Those
numbers in general _don't_ have a buffer name corresponding to an
actual complete file name (there certainly won't be a buffer named ~/
even if ~/ is already visited at the time the splash screen might get
displayed).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: Scratch buffer annoyance

[Drew Adams]

> > (defcustom visit-on-startup nil
> >   "What Emacs visits when it starts up.
> > A non-nil value is a string naming a directory, file, or buffer
> to visit.
> > If nil, then the splash screen is displayed."
> >   :type '(choice
> >           (directory :tag "Directory"      :value "~/")
> >           (file      :tag "File"           :value "~/new.txt")
> >           (string    :tag "Buffer"         :value "*scratch*")
> >           (const     :tag "Splash Screen"  nil))
> >   :group 'startup-display)
> >
> > The value is a string or nil. If you choose `Buffer', then you
> > can enter any string (without completion). If the string names a
> > buffer that exists at startup, such as *scratch* or *Messages*,
> > then that buffer is visited (in the proper mode). If the string
> > names a nonexistent buffer, then that buffer is created and
> > visited.
>
> You mean: then that _file_ is visited.  It does not make sense to
> visit a buffer.

Oh, if you insist. I think we could use "visit" loosely here, to get the
point across, but if you want to be pedantic about it, then we shouldn't say
"visit" the splash screen either. So change it to speak of "visiting" a file
or directory, "displaying and selecting" a buffer, and "displaying" the
splash screen. Or whatever terminology is PC.

Call the option "what-to-do-at-startup" if you like ("And tomorrow morning,
we shall have what to do after firing. But today, today we have naming of
parts.").

> What does "exist at startup" mean?  At the time the splash screen
> might get displayed, .emacs is already processed, and any number of
> buffers might be loaded already (including a whole desktop).

And?

If the string value of the option names a file or directory, then visit it.
If not, and if the value names one of those numerous buffers "loaded
already" (do we "load" buffers, BTW?), then display and select it. If not,
and the value is a string, create, display, and select a buffer with that
name.

> Those numbers in general _don't_ have a buffer name corresponding to an
> actual complete file name (there certainly won't be a buffer named ~/
> even if ~/ is already visited at the time the splash screen might get
> displayed).

And?

If the string value is "~/", then visit the home directory.

If the string names an existing buffer, then display and select it; if not,
create, display, and select a buffer with that name. Why would such a buffer
need to "have a buffer name corresponding to an actual complete file name"?

I still don't get the point or the difficulty here.

Re: Scratch buffer annoyance

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

>> > (defcustom visit-on-startup nil
>> >   "What Emacs visits when it starts up.
>> > A non-nil value is a string naming a directory, file, or buffer
>> to visit.
>> > If nil, then the splash screen is displayed."
>> >   :type '(choice
>> >           (directory :tag "Directory"      :value "~/")
>> >           (file      :tag "File"           :value "~/new.txt")
>> >           (string    :tag "Buffer"         :value "*scratch*")
>> >           (const     :tag "Splash Screen"  nil))
>> >   :group 'startup-display)
>> >
>> > The value is a string or nil. If you choose `Buffer', then you
>> > can enter any string (without completion). If the string names a
>> > buffer that exists at startup, such as *scratch* or *Messages*,
>> > then that buffer is visited (in the proper mode). If the string
>> > names a nonexistent buffer, then that buffer is created and
>> > visited.
>>
>> You mean: then that _file_ is visited.  It does not make sense to
>> visit a buffer.
>
> Oh, if you insist. I think we could use "visit" loosely here, to get the
> point across, but if you want to be pedantic about it, then we shouldn't say
> "visit" the splash screen either. So change it to speak of "visiting" a file
> or directory, "displaying and selecting" a buffer, and "displaying" the
> splash screen. Or whatever terminology is PC.
>
> Call the option "what-to-do-at-startup" if you like ("And tomorrow morning,
> we shall have what to do after firing. But today, today we have naming of
> parts.").
>
>> What does "exist at startup" mean?  At the time the splash screen
>> might get displayed, .emacs is already processed, and any number of
>> buffers might be loaded already (including a whole desktop).
>
> And?
>
> If the string value of the option names a file or directory, then
> visit it.

You mean, if the name is "*scratch*" and in the current directory
at the time the desktop finished loading, there exists a file named
"*scratch*", this should be visited?

And if the current directory at the time of the startup happens to be
"/dak@fencepost.gnu.org:/home/g/gnudist" because there was the last
file loaded, then it should go through a remote connection and check
for the existence of "*scratch*" there?

> If not, and if the value names one of those numerous buffers "loaded
> already" (do we "load" buffers, BTW?),

No.  Files are visited by loading them into buffers.

> then display and select it. If not, and the value is a string,
> create, display, and select a buffer with that name.
>
>> Those numbers in general _don't_ have a buffer name corresponding to an
>> actual complete file name (there certainly won't be a buffer named ~/
>> even if ~/ is already visited at the time the splash screen might get
>> displayed).
>
> And?
>
> If the string value is "~/", then visit the home directory.

You have provided no coherent logic that would have this effect
without a lot of drawbacks.

> If the string names an existing buffer, then display and select it;
> if not, create, display, and select a buffer with that name. Why
> would such a buffer need to "have a buffer name corresponding to an
> actual complete file name"?

Because visiting a random file depending on just where we are at
startup is not useful behavior.

> I still don't get the point or the difficulty here.

On that point I agree.

-- 
David Kastrup

RE: Scratch buffer annoyance

[Drew Adams]

> > If the string value of the option names a file or directory, then
> > visit it.
>
> You mean, if the name is "*scratch*" and in the current directory
> at the time the desktop finished loading, there exists a file named
> "*scratch*", this should be visited?

So require the file and directory names to be absolute names.

> And if the current directory at the time of the startup happens to be
> "/dak@fencepost.gnu.org:/home/g/gnudist" because there was the last
> file loaded, then it should go through a remote connection and check
> for the existence of "*scratch*" there?

Require an absolute file name.

[Or tell users that they take a chance if they use a relative name.]

> > > ...any number of buffers might be loaded already...
> >
> > If not, and if the value names one of those numerous buffers "loaded
> > already" (do we "load" buffers, BTW?),
>
> No.  Files are visited by loading them into buffers.

See how easy it is to use terms loosely? I said "visit" a buffer; you said
"load" a buffer. Let us both do penance ;-).

> > then display and select it. If not, and the value is a string,
> > create, display, and select a buffer with that name.
> >
> >> Those numbers in general _don't_ have a buffer name corresponding to an
> >> actual complete file name (there certainly won't be a buffer named ~/
> >> even if ~/ is already visited at the time the splash screen might get
> >> displayed).
> >
> > And? If the string value is "~/", then visit the home directory.
>
> You have provided no coherent logic that would have this effect
> without a lot of drawbacks.

Don't know what that means. What is the problem with interpreting "~/" as an
absolute directory name (after expansion of `~')? Please elaborate on "a lot
of drawbacks".

> > If the string names an existing buffer, then display and select it;
> > if not, create, display, and select a buffer with that name. Why
> > would such a buffer need to "have a buffer name corresponding to an
> > actual complete file name"?
>
> Because visiting a random file depending on just where we are at
> startup is not useful behavior.

It's not random if its address is provided by the user as the option value.

Re: Scratch buffer annoyance

[Jason Rumney]

Drew Adams wrote:

> (defcustom visit-on-startup nil
>   "What Emacs visits when it starts up.
> A non-nil value is a string naming a directory, file, or buffer to visit.
> If nil, then the splash screen is displayed."
>   :type '(choice
>           (directory :tag "Directory"      :value "~/")
>           (file      :tag "File"           :value "~/new.txt")
>           (string    :tag "Buffer"         :value "*scratch*")
>           (const     :tag "Splash Screen"  nil))
>   :group 'startup-display)
>
> The value is a string or nil. If you choose `Buffer', then you can enter any
> string (without completion). If the string names a buffer that exists at
> startup, such as *scratch* or *Messages*, then that buffer is visited (in
> the proper mode). If the string names a nonexistent buffer, then that buffer
> is created and visited.
>
> What am I missing? Why is this thread so Byzantine?
>   

You are making a distinction in the UI between buffer and file. But the
distinction is thrown away immediately because buffer, file and
directory all map to strings.

RE: Scratch buffer annoyance

[Drew Adams]

> > What am I missing? Why is this thread so Byzantine?
>
> You are making a distinction in the UI between buffer and file. But the
> distinction is thrown away immediately because buffer, file and
> directory all map to strings.

If Customize can determine whether a string is a proper file or directory
name (types `file' and `directory'), then Emacs can tell whether a string is
a file or directory name.

If you're worried about interpreting relative file names in the wrong
default directory, as David is, then require an absolute file name as the
value. [Or warn users that if they use a relative name then the behavior
depends on the current directory.]

So, if the string is an absolute file or directory name, then visit the file
or directory; if not, interpret the string as a buffer name.

If there is a problem (e.g. error) visiting that file or directory, then
punt in some reasonable way - e.g. show the splash screen and an error
message.

We could also require that the file to visit exist, but I don't think that
is even necessary. There might be other details to work out, but, honestly,
this just doesn't seem that complex. We ought to be able to get something
reasonable up and running before 2010. Of course, then there's the name of
the option to worry about...

Re: Scratch buffer annoyance

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

> If Customize can determine whether a string is a proper file or directory
> name (types `file' and `directory'),

It doesn't.  The difference is only in the UI, but otherwise matches any
string.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: Scratch buffer annoyance

[Drew Adams]

> > If Customize can determine whether a string is a proper file or
> > directory name (types `file' and `directory'),
>
> It doesn't.  The difference is only in the UI, but otherwise matches any
> string.

I see; I wasn't aware of that. Why is that?

Then shouldn't the doc (e.g. Elisp manual) be corrected to explain that
strong statements such as "The value must be a directory name" don't mean
what they say, that they mean only that you can use completion to insert an
existing directory name? They apparently mean nothing about the value
itself. If there is really no requirement that "the value _must_ be a
directory name", then why say that?

Wrt requiring an absolute name for a file or directory: We already do that
elsewhere - note the doc string here:

(defcustom auto-insert-directory "~/insert/"
  "*Directory from which auto-inserted files are taken.
The value must be an absolute directory name..."
  :type 'directory :group 'auto-insert)

Presumably, it is the code that uses `auto-insert-directory' that ensures
that the value is in fact an absolute directory name. The same could be done
for `visit-on-startup': check its value at startup time, to see if it is
`file-name-absolute-p', and use a buffer if it is not. And document this
behavior in the doc string.

Going beyond control at startup time, couldn't we use, instead of `file' and
`directory' for :type, a suitable `restricted-sexp' expression, to ensure
that the saved value is in fact a string that satisfies
`file-name-absolute-p'? I'm no expert on custom types, but what about
something like this - its seems to work OK:

:type '(restricted-sexp :match-alternatives
        ((lambda (x) (and (stringp x) (file-name-absolute-p x)))))

Anyway, this doesn't sound like an unsurmountable problem, however we
approach it. We should be able to let a user specify an absolute file or
directory name or a buffer name.

Re: Scratch buffer annoyance

[Stefan Monnier]

> Wrt requiring an absolute name for a file or directory: We already do that
> elsewhere - note the doc string here:

My favorite choice would be "." and I don't mean "a buffer called .".


        Stefan

RE: Scratch buffer annoyance

[Drew Adams]

> > Wrt requiring an absolute name for a file or directory: We
> > already do that elsewhere - note the doc string here:
>
> My favorite choice would be "." and I don't mean "a buffer called .".

I see. Do you think we should have an additional choice that is a sexp to
eval at startup? (In your case, it could be (find-file ".").)

That should cover anyone's personal needs, and it could be ignored by most
users, including newbies. The doc string could even say something to the
effect that that choice is for "advanced" use, warn about potential gotchas,
and so on.

Re: Scratch buffer annoyance

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
>> That variable name is misleading because the value is not a buffer.
>> Please change the variable name to one that fits the meaning.
>
> I don't see a better name.  Maybe, `initial-display-buffer' or
> `initial-current-buffer'?

`initial-buffer-name'

-Miles

-- 
Come now, if we were really planning to harm you, would we be waiting here,
 beside the path, in the very darkest part of the forest?

Re: Scratch buffer annoyance

[Stefan Monnier]

>> > ! (defcustom initial-buffer nil
>> > !   "Buffer to show after starting Emacs."
>> > !   :type '(choice
>> > !           (directory :tag "Directory"        :value "~/")
>> > !           (file      :tag "File"             :value "~/new.txt")
>> > !           (const     :tag "*scratch* buffer" :value "*scratch*")
>> > !           (const     :tag "Splash screen"    nil))

We need to add ".".


        Stefan

Re: Scratch buffer annoyance

[Andreas Schwab]

Juri Linkov <juri@jurta.org> writes:

>>     > ! (defcustom initial-buffer nil
>>     > !   "Buffer to show after starting Emacs."
>>     > !   :type '(choice
>>     > !           (directory :tag "Directory"        :value "~/")
>>     > !           (file      :tag "File"             :value "~/new.txt")
>>     > !           (const     :tag "*scratch* buffer" :value "*scratch*")
>>     > !           (const     :tag "Splash screen"    nil))

"*scratch*" should be represented differently, since it is used as a
buffer name instead of a file name.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Scratch buffer annoyance

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> Juri Linkov <juri@jurta.org> writes:
>
>>>     > ! (defcustom initial-buffer nil
>>>     > !   "Buffer to show after starting Emacs."
>>>     > !   :type '(choice
>>>     > !           (directory :tag "Directory"        :value "~/")
>>>     > !           (file      :tag "File"             :value "~/new.txt")
>>>     > !           (const     :tag "*scratch* buffer" :value "*scratch*")
>>>     > !           (const     :tag "Splash screen"    nil))
>
> "*scratch*" should be represented differently, since it is used as a
> buffer name instead of a file name.

I found Richard's proposal to use 'lisp-interaction-mode here
appealing.  However, this leaves open what initial-major-mode should
do.

Maybe we should have
initial-visitor just evaluated.  Then one can set it to (find-file
"~/") or (display-splash-screen) or (switch-to-buffer "*scratch*").

-- 
David Kastrup

Re: Scratch buffer annoyance

[Juri Linkov]

> Maybe we should have
> initial-visitor just evaluated.  Then one can set it to (find-file
> "~/") or (display-splash-screen) or (switch-to-buffer "*scratch*").

Yes, then it would be easier to customize and precisely distinguish
different meanings of string values:

(defcustom startup-function nil
  "Function to call after starting Emacs."
  :type '(choice
          (const :tag "Splash screen" nil)
          (list :tag "Directory"
		(const :value dired)
		(directory :tag "Directory name" :value "~/"))
          (list :tag "File"
		(const :value find-file)
		(file :tag "File name" :value "~/new.txt"))
          (list :tag "Buffer"
		(const :value switch-to-buffer)
		(string :tag "Buffer name" :value "*scratch*")))
  :version "23.1"
  :group 'initialization)

And to eval one of the predefined non-nil funcalls:

(dired "~/")
(find-file "~/new.txt")
(switch-to-buffer "*scratch*")

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Scratch buffer annoyance

[Drew Adams]

> > Maybe we should have
> > initial-visitor just evaluated.  Then one can set it to (find-file
> > "~/") or (display-splash-screen) or (switch-to-buffer "*scratch*").
>
> Yes, then it would be easier to customize and precisely distinguish
> different meanings of string values:
>
> (defcustom startup-function nil
>   "Function to call after starting Emacs."
>   :type '(choice
>           (const :tag "Splash screen" nil)
>           (list :tag "Directory"
> 		(const :value dired)
> 		(directory :tag "Directory name" :value "~/"))
>           (list :tag "File"
> 		(const :value find-file)
> 		(file :tag "File name" :value "~/new.txt"))
>           (list :tag "Buffer"
> 		(const :value switch-to-buffer)
> 		(string :tag "Buffer name" :value "*scratch*")))
>   :version "23.1"
>   :group 'initialization)
>
> And to eval one of the predefined non-nil funcalls:
>
> (dired "~/")
> (find-file "~/new.txt")
> (switch-to-buffer "*scratch*")

I wouldn't strongly argue against having a value that is evaled, but I don't
really see that as needed. And users, especially newbies, might get into
more trouble if we do that.

I don't think it would be "easier to customize" - I think the opposite. A
user would need to provide both the destination string and the action
function to apply to it. That could be confusing - for little or no gain
(for the user).

Why not just make sure that the value is a literal string of the right kind,
and provide only for `dired', `find-file', and `switch-to-buffer' as the
actions? Is there a real need to go beyond that to evaluation and arbitrary
actions?

If there is a _user_ need (benefit) for an evaled expression, then let's
hear it, but if this proposal is just because we seem to be having
difficulty finding a good way to implement file, directory, and buffer
values, then that's wrong. Let's not burden the user if we can avoid it.

Re: Scratch buffer annoyance

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

> I wouldn't strongly argue

You argue against anything not designed by yourself until everybody is
exhausted, so the strength is irrelevant.

> against having a value that is evaled, but I don't really see that
> as needed. And users, especially newbies, might get into more
> trouble if we do that.

Newbies are to use customize, and thus can't get into trouble.

> I don't think it would be "easier to customize" - I think the
> opposite.  A user would need to provide both the destination string
> and the action function to apply to it.  That could be confusing -
> for little or no gain (for the user).
>
> Why not just make sure that the value is a literal string of the
> right kind,

Drew, get a grip.  A string is of kind string, period.  There is no
"right" or "wrong" kind.  That is precisely the problem.

> and provide only for `dired', `find-file', and `switch-to-buffer' as
> the actions?

Well, have you actually taken a look at the code?  That is exactly
what the customization type provided.

> Is there a real need to go beyond that to evaluation and arbitrary
> actions?
>
> If there is a _user_ need (benefit) for an evaled expression, then
> let's hear it, but if this proposal is just because we seem to be
> having difficulty finding a good way to implement file, directory,
> and buffer values, then that's wrong. Let's not burden the user if
> we can avoid it.

There is no burden whatsoever for the user involved.  He gets the
right customization choices, and nothing else.  A fuzzy "Please try
figuring out what I mean by it" string of "the right kind" where the
user has no chance to figure out what action will result (since not
even Emacs has a chance to figure out without trying) is _not_ _at_
_all_ helpful for the user.

So please stop pretending that there are no valid objections and you
already have addressed them by handwaving.

It is likely possible to use a funcall here instead of an eval, but
the customized forms will be quite the same, and there are no savings
of confusion involved.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: Scratch buffer annoyance

[Drew Adams]

> You argue against anything not designed by yourself
> until everybody is exhausted

Please drop the personal attacks, David.

I was trying to help this interminable thread come to a conclusion, but you
can have it back. Carry on.

Re: Scratch buffer annoyance

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

>> You argue against anything not designed by yourself
>> until everybody is exhausted
>
> Please drop the personal attacks, David.

Why the plural tense?  This was the first remark in this thread where
you (not for the first time) simply ignore others' explanations and
keep restating your initial not-thought-through proposal time and
again.

> I was trying to help this interminable thread come to a conclusion,

But wearing the others out is not going to address the underlying
technical _facts_ of their objections.  It is not a matter of opinion
that a string does not carry "file", "buffer", "whatever" markers
associated with it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Scratch buffer annoyance

[Davis Herring]

> But wearing the others out is not going to address the underlying
> technical _facts_ of their objections.  It is not a matter of opinion
> that a string does not carry "file", "buffer", "whatever" markers
> associated with it.

Why do you think we have text properties?  We can even propertize
different parts of the string differently.  So we can have "namename" with
(file t) on the first four characters and (buffer t) on the others to name
both the file and the buffer into which it goes.  Stefan (who wants ".")
can mark that as (directory t absolute nil) which takes care of the
where-emacs-is-run-or-not problem, and if the string is exactly "eval",
then its property list is evalled and we can do whatever else is needed. 
Add a 'mode property, and a 'vars property which is a list of buffer-local
bindings to set (to support buffer-offer-save for persistent *scratch*)...
I bet with this one string-valued variable we could do away with .emacs
altogether!

Davis

PS - What little of this idea isn't sheer madness is of course the same as
what's already proposed: (tag . str) where tag reflects the user's choice
of action: t for a buffer or 'file (or 'url, or...), with support for ~ in
filenames to make absolute names easy to type.

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Scratch buffer annoyance

[David Kastrup]

"Davis Herring" <herring@lanl.gov> writes:

>> But wearing the others out is not going to address the underlying
>> technical _facts_ of their objections.  It is not a matter of opinion
>> that a string does not carry "file", "buffer", "whatever" markers
>> associated with it.
>
> Why do you think we have text properties?  We can even propertize
> different parts of the string differently.  So we can have
> "namename" with (file t) on the first four characters and (buffer t)
> on the others to name both the file and the buffer into which it
> goes.  Stefan (who wants ".")  can mark that as (directory t
> absolute nil) which takes care of the where-emacs-is-run-or-not
> problem, and if the string is exactly "eval", then its property list
> is evalled and we can do whatever else is needed.

It is good to see a solution that is not confusing to beginners.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Scratch buffer annoyance

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
>> Why do you think we have text properties?
>
> It is good to see a solution that is not confusing to beginners.

I'm not sure which one you think is confusing to beginners, but I think
the text property solution would be far more confusing.

I mean really, something like (buffer "foo") or (file "~/bar")
seems pretty clear, even if you don't know what lisp is.

Text properties, on the other hand are _invisible_, and having strings
whose meaning differs based on invisible properties doesn't seems like a
very good interface at all for beginners... (or experts for that matter)

-Miles

-- 
We live, as we dream -- alone....

Re: Scratch buffer annoyance

[Davis Herring]

Davis: Why do you think we have text properties? ...
David: It is good to see a solution that is not confusing to beginners.

Miles:
> I'm not sure which one you think is confusing to beginners, but I think
> the text property solution would be far more confusing.
>
> I mean really, something like (buffer "foo") or (file "~/bar")
> seems pretty clear, even if you don't know what lisp is.
>
> Text properties, on the other hand are _invisible_, and having strings
> whose meaning differs based on invisible properties doesn't seems like a
> very good interface at all for beginners... (or experts for that matter)

In case I wasn't obvious enough, I was joking.  And from the shortness of
his reply, I am sure that David was joking too.  Text properties are more
than inappropriate here because they are attached to the characters and
not to the string: three different substrings could all be marked, say,
'buffer!

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Scratch buffer annoyance

[Miles Bader]

On 8/2/07, Davis Herring <herring@lanl.gov> wrote:
> In case I wasn't obvious enough, I was joking.  And from the shortness of
> his reply, I am sure that David was joking too.

D'oh!  :-/

-miles

-- 
Do not taunt Happy Fun Ball.

Re: Scratch buffer annoyance

[Richard Stallman]

I recommend defining the value this way:

A string is a file name to visit.

A symbol that's a command is an initial major mode for *scratch*.

nil means keep the splash screen.

It does what we want and it is clear.

Re: Scratch buffer annoyance

[Juri Linkov]

> I recommend defining the value this way:
>
> A string is a file name to visit.

Then there is no distinction between file and directory names, but maybe
this is not needed provided that this string is always used as an argument
of `find-file'.

> A symbol that's a command is an initial major mode for *scratch*.

There is already a user option `initial-major-mode' that defines
an initial major mode for *scratch*.  Using two user options
for the same setting would be confusing.

> nil means keep the splash screen.
>
> It does what we want and it is clear.

Neither a string or a major mode makes it clear what the value is used for.
And I don't know what a variable name would be suitable for this option.

If an idea of setting this option to a function call like
(switch-to-buffer "*scratch*") is not acceptable (maybe this fits
better to adding such a funcall to a hook variable), then what is wrong
with using self-explanatory values like (buffer "foo") or (file "~/bar")?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

    > A string is a file name to visit.

    Then there is no distinction between file and directory names, but maybe
    this is not needed provided that this string is always used as an argument
    of `find-file'.

Exactly.

    > A symbol that's a command is an initial major mode for *scratch*.

    There is already a user option `initial-major-mode' that defines
    an initial major mode for *scratch*.  Using two user options
    for the same setting would be confusing.

We could alias this variable to `initial-major-mode', or we
could say that t means use a *scratch* buffer.

    > It does what we want and it is clear.

    Neither a string or a major mode makes it clear what the value is used for.

So what?  That's what the doc string is for.

    And I don't know what a variable name would be suitable for this option.

`initial-buffer-contents' seems good.

    If an idea of setting this option to a function call like
    (switch-to-buffer "*scratch*") is not acceptable (maybe this fits
    better to adding such a funcall to a hook variable), then what is wrong
    with using self-explanatory values like (buffer "foo") or (file "~/bar")?

This complexity is unnecessary.

Re: Scratch buffer annoyance

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > A string is a file name to visit.
>
>     Then there is no distinction between file and directory names, but maybe
>     this is not needed provided that this string is always used as an argument
>     of `find-file'.
>
> Exactly.
>
>     > A symbol that's a command is an initial major mode for *scratch*.
>
>     There is already a user option `initial-major-mode' that defines
>     an initial major mode for *scratch*.  Using two user options
>     for the same setting would be confusing.
>
> We could alias this variable to `initial-major-mode', or we
> could say that t means use a *scratch* buffer.

Then it would not be possible to specify a mode for *scratch* unless
one also makes *scratch* the startup screen.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Scratch buffer annoyance

[Richard Stallman]

    Then it would not be possible to specify a mode for *scratch* unless
    one also makes *scratch* the startup screen.

As I understand it, part of the idea of this change is that
there won't BE a *scratch* buffer if you don't request it
in `initial-buffer-contents'.

Re: Scratch buffer annoyance

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Then it would not be possible to specify a mode for *scratch* unless
>     one also makes *scratch* the startup screen.
>
> As I understand it, part of the idea of this change is that
> there won't BE a *scratch* buffer if you don't request it
> in `initial-buffer-contents'.

Certainly not at startup.  But I use a Lisp mode *scratch* buffer
regularly in the normal work.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Scratch buffer annoyance

[Richard Stallman]

    > As I understand it, part of the idea of this change is that
    > there won't BE a *scratch* buffer if you don't request it
    > in `initial-buffer-contents'.

    Certainly not at startup.  But I use a Lisp mode *scratch* buffer
    regularly in the normal work.

It is totally straightforward to set that up in .emacs, so I don't
think we need to set it up in this option.

Re: Scratch buffer annoyance

[Juri Linkov]

>     Then it would not be possible to specify a mode for *scratch* unless
>     one also makes *scratch* the startup screen.
>
> As I understand it, part of the idea of this change is that
> there won't BE a *scratch* buffer if you don't request it
> in `initial-buffer-contents'.

It is very useful to create a *scratch* buffer at startup, even if it is
not displayed immediately.

But there is no need to replace `initial-major-mode' with using your idea
that t of a new option means display a *scratch* buffer created in mode
specified by `initial-major-mode'.

The only problem remains I think that the name `initial-buffer-contents'
is worse than simply `initial-buffer'.  It gives a false impression that
that some contents gets insterted into some fixed initial buffer.

Perhaps, a better name is `initial-display'?  This has clear semantics:
display the startup screen initially, display a *scratch* buffer, display the
home directory...

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

    > As I understand it, part of the idea of this change is that
    > there won't BE a *scratch* buffer if you don't request it
    > in `initial-buffer-contents'.

    It is very useful to create a *scratch* buffer at startup, even if it is
    not displayed immediately.

Why do you find it particularly useful?  I want to try to gauge
how many users would find it desirable.  Would they be so many
that it would be unacceptable to recommend they use this recipe
to set it up?

  (with-current-buffer (get-buffer-create "*scratch*")
    (lisp-interaction-mode))


    The only problem remains I think that the name `initial-buffer-contents'
    is worse than simply `initial-buffer'.

Sorry, I disagree.

					    It gives a false impression that
    that some contents gets insterted into some fixed initial buffer.

It doesn't seem like a big flaw to me, but I agree it is a small flaw.

    Perhaps, a better name is `initial-display'?

That seems a little less clear than `initial-buffer-contents'.
However, perhaps `initial-buffer-setup' is better.

Re: Scratch buffer annoyance

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > As I understand it, part of the idea of this change is that
>     > there won't BE a *scratch* buffer if you don't request it
>     > in `initial-buffer-contents'.
>
>     It is very useful to create a *scratch* buffer at startup, even if it is
>     not displayed immediately.
>
> Why do you find it particularly useful?  I want to try to gauge
> how many users would find it desirable.  Would they be so many
> that it would be unacceptable to recommend they use this recipe
> to set it up?
>
>   (with-current-buffer (get-buffer-create "*scratch*")
>     (lisp-interaction-mode))

Personally, my workflow happens to make me delete the scratch buffer
occasionally, and revisit it later.  So I want to be able to have it,
when it gets recreated, to be in lisp-interaction-mode.

In fact, people thought this so desirable that we have

    * Changes in Emacs 21.2

    [...]

    ** When the *scratch* buffer is recreated, its mode is set from
    initial-major-mode, which normally is lisp-interaction-mode,
    instead of using default-major-mode.

I would like to retain the ability to do this, though I agree that
"initial-major-mode" is a completely misleading name for it under the
new startup design and should become a deprecated alias (do we have
that?) for something more fitting.

-- 
David Kastrup

Re: Scratch buffer annoyance

[Richard Stallman]

    In fact, people thought this so desirable that we have

	* Changes in Emacs 21.2

	[...]

	** When the *scratch* buffer is recreated, its mode is set from
	initial-major-mode, which normally is lisp-interaction-mode,
	instead of using default-major-mode.

    I would like to retain the ability to do this, though I agree that
    "initial-major-mode" is a completely misleading name for it under the
    new startup design and should become a deprecated alias (do we have
    that?) for something more fitting.

We could have something like auto-mode-alist
for buffer names.

Re: Scratch buffer annoyance

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     In fact, people thought this so desirable that we have
>
> 	* Changes in Emacs 21.2
>
> 	[...]
>
> 	** When the *scratch* buffer is recreated, its mode is set from
> 	initial-major-mode, which normally is lisp-interaction-mode,
> 	instead of using default-major-mode.
>
>     I would like to retain the ability to do this, though I agree that
>     "initial-major-mode" is a completely misleading name for it under the
>     new startup design and should become a deprecated alias (do we have
>     that?) for something more fitting.
>
> We could have something like auto-mode-alist
> for buffer names.

That was my first thought, too, and I looked for something like that
in vain.

auto-mode-buffer-alist or something.

We could even misuse auto-mode-alist as a last-resort fallback here:
buffer names corresponding to already checked file names won't match,
anyway, and the buffer names not associated with files usually start
with "*" or " *", and it is very unlikely we'll ever need to match a
file name like that.

And, after all, it is called auto-mode-alist and not
auto-filename-mode-alist.

-- 
David Kastrup

Re: Scratch buffer annoyance

[Richard Stallman]

    That was my first thought, too, and I looked for something like that
    in vain.

    auto-mode-buffer-alist or something.

buffer-auto-mode-alist seems clearer.
Would you like to implement it?

Re: Scratch buffer annoyance

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     That was my first thought, too, and I looked for something like that
>     in vain.
>
>     auto-mode-buffer-alist or something.
>
> buffer-auto-mode-alist seems clearer.
> Would you like to implement it?

On second thought, I think that it can be wrapped into
auto-mode-alist.  If someone does C-x b unnamed.c RET, chances are
that he won't find it strange to see the buffer in C mode rather than
fundamental mode.  And the only buffers that are not file-related tend
to start with *.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Scratch buffer annoyance

[Richard Stallman]

    On second thought, I think that it can be wrapped into
    auto-mode-alist.  If someone does C-x b unnamed.c RET, chances are
    that he won't find it strange to see the buffer in C mode rather than
    fundamental mode.  And the only buffers that are not file-related tend
    to start with *.

You might be right, but the change seems too radical to me.
I would rather introduce a new buffer-auto-mode-alist
just to avoid the incompatible change.

Re: Scratch buffer annoyance

[Juri Linkov]

>     On second thought, I think that it can be wrapped into
>     auto-mode-alist.  If someone does C-x b unnamed.c RET, chances are
>     that he won't find it strange to see the buffer in C mode rather than
>     fundamental mode.  And the only buffers that are not file-related tend
>     to start with *.
>
> You might be right, but the change seems too radical to me.
> I would rather introduce a new buffer-auto-mode-alist
> just to avoid the incompatible change.

Whose definition could be just

(defvar buffer-auto-mode-alist
  (append
    '(("\\`\*scratch\*\\'" . lisp-interaction-mode))
    auto-mode-alist))

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Andreas Schwab]

Juri Linkov <juri@jurta.org> writes:

> Whose definition could be just
>
> (defvar buffer-auto-mode-alist
>   (append
>     '(("\\`\*scratch\*\\'" . lisp-interaction-mode))
>     auto-mode-alist))

That is suboptimal, since a change to auto-mode-alist would not be
reflected in this value.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Scratch buffer annoyance

[Richard Stallman]

    Whose definition could be just

    (defvar buffer-auto-mode-alist
      (append
	'(("\\`\*scratch\*\\'" . lisp-interaction-mode))
	auto-mode-alist))

A user could set it that way, but I don't want to include the value of
auto-mode-alist in the default value.  I would rather keep buffer names
and file names separate and have separate features to act on them.

buffer-auto-mode-alist (was: Scratch buffer annoyance)

[Juri Linkov]

>     (defvar buffer-auto-mode-alist
>       (append
> 	'(("\\`\*scratch\*\\'" . lisp-interaction-mode))
> 	auto-mode-alist))
>
> A user could set it that way, but I don't want to include the value of
> auto-mode-alist in the default value.  I would rather keep buffer names
> and file names separate and have separate features to act on them.

I think the best way to implement this feature is to add a new hook
`after-create-buffer-hook' containing a function that sets buffer
mode according to `buffer-auto-mode-alist'.  This hook could be called
from `get-buffer-create'.

This hook will also help to remove defadvice for `create-file-buffer'
in uniquify.el when a uniquify renaming function will be appended
after buffer-auto-mode-alist renaming function in this hook.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: buffer-auto-mode-alist (was: Scratch buffer annoyance)

[Richard Stallman]

    I think the best way to implement this feature is to add a new hook
    `after-create-buffer-hook' containing a function that sets buffer
    mode according to `buffer-auto-mode-alist'.  This hook could be called
    from `get-buffer-create'.

I would rather put the code directly into `get-buffer-create' and
avoid using a hook to run it.  When a feature is standardly on, it
is cleaner not to do it using a hook.

    This hook will also help to remove defadvice for `create-file-buffer'
    in uniquify.el when a uniquify renaming function will be appended
    after buffer-auto-mode-alist renaming function in this hook.

That might be a good reason this hook.  But we do not want to depend
on the order of hook functions.  So we should handle
`buffer-auto-mode-alist' explicitly before running the hook.

Re: Scratch buffer annoyance

[Juri Linkov]

>     It is very useful to create a *scratch* buffer at startup, even if it is
>     not displayed immediately.
>
> Why do you find it particularly useful?

Emacs without a *scratch* buffer is not Emacs :-)

>     Perhaps, a better name is `initial-display'?
>
> That seems a little less clear than `initial-buffer-contents'.
> However, perhaps `initial-buffer-setup' is better.

With a new naming scheme David proposed this name could be
`setup-initial-buffer'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>>     It is very useful to create a *scratch* buffer at startup, even if it is
>>     not displayed immediately.
>>
>> Why do you find it particularly useful?
>
> Emacs without a *scratch* buffer is not Emacs :-)
>
>>     Perhaps, a better name is `initial-display'?
>>
>> That seems a little less clear than `initial-buffer-contents'.
>> However, perhaps `initial-buffer-setup' is better.
>
> With a new naming scheme David proposed this name could be
> `setup-initial-buffer'.

Don't put schemes into my mouth.  I seem to remember that my
proposition boiled down to `startup-*', where the details about * were
still fuzzy, so feel free to start expanding form there.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Scratch buffer annoyance

[Juri Linkov]

>> With a new naming scheme David proposed this name could be
>> `setup-initial-buffer'.
>
> Don't put schemes into my mouth.  I seem to remember that my
> proposition boiled down to `startup-*', where the details about * were
> still fuzzy, so feel free to start expanding form there.

Sorry, I meant `startup-', not `setup-'.  I am already too entangled in
this naming mess.  So let's name this new option with all proposed words
`startup-initial-buffer-visit-contents-display-setup'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>>> With a new naming scheme David proposed this name could be
>>> `setup-initial-buffer'.
>>
>> Don't put schemes into my mouth.  I seem to remember that my
>> proposition boiled down to `startup-*', where the details about * were
>> still fuzzy, so feel free to start expanding form there.
>
> Sorry, I meant `startup-', not `setup-'.  I am already too entangled in
> this naming mess.  So let's name this new option with all proposed words
> `startup-initial-buffer-visit-contents-display-setup'.

I thing that should be the customization group name.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Scratch buffer annoyance

[Richard Stallman]

    Sorry, I meant `startup-', not `setup-'.  I am already too entangled in
    this naming mess.  So let's name this new option with all proposed words
    `startup-initial-buffer-visit-contents-display-setup'.

That's good for the humor file.  For actually implementing this,
how about `startup-buffer-choice' or `initial-buffer-choice'?

Re: Scratch buffer annoyance

[Juri Linkov]

>     Sorry, I meant `startup-', not `setup-'.  I am already too entangled in
>     this naming mess.  So let's name this new option with all proposed words
>     `startup-initial-buffer-visit-contents-display-setup'.
>
> That's good for the humor file.  For actually implementing this,
> how about `startup-buffer-choice' or `initial-buffer-choice'?

Many user options provide a choice of different value types, but none have a
`-choice' suffix.  So I see no better names than `startup-buffer' or
`initial-buffer'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Johan Bockgård]

Juri Linkov <juri@jurta.org> writes:

>> That's good for the humor file. For actually implementing this, how
>> about `startup-buffer-choice' or `initial-buffer-choice'?
>
> Many user options provide a choice of different value types, but none
> have a `-choice' suffix. So I see no better names than
> `startup-buffer' or `initial-buffer'.

How about something like `startup-buffer-style' (or -type, etc)?

-- 
Johan Bockgård

Re: Scratch buffer annoyance

[Richard Stallman]

    Many user options provide a choice of different value types, but none have a
    `-choice' suffix.  So I see no better names than `startup-buffer' or
    `initial-buffer'.

Those names are not good because the value is not a buffer.
`startup-buffer-choice' is better, because at least it doesn't
imply the value is a buffer.

However, I can also suggest `startup-buffer-initialization'.

`startup-buffer-style', recently suggested, is also better than
just `startup-buffer'.

Re: Scratch buffer annoyance

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Many user options provide a choice of different value types, but none have a
>     `-choice' suffix.  So I see no better names than `startup-buffer' or
>     `initial-buffer'.
>
> Those names are not good because the value is not a buffer.
> `startup-buffer-choice' is better, because at least it doesn't
> imply the value is a buffer.
>
> However, I can also suggest `startup-buffer-initialization'.
>
> `startup-buffer-style', recently suggested, is also better than
> just `startup-buffer'.

I like startup-buffer-style.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Scratch buffer annoyance

[Richard Stallman]

    I like startup-buffer-style.

Ok, let's use that.  Would someone please install the change?

Re: Scratch buffer annoyance

[Juri Linkov]

> Would someone please install the change?

Done.  I added the variable `initial-buffer-choice' because other names
are less appropriate.  If someone wants to change the prefix `initial-',
please also change prefixes of related variables `initial-major-mode' and
`initial-scratch-message'.

To create links in the startup screen, I modified the previous patch
to use the function `insert-button' from button.el to allow navigation
between links and better processing of their actions.  I hope there are
no problems with this because this function is auto-loaded.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Glenn Morris]

Juri Linkov wrote:

> To create links in the startup screen, I modified the previous patch
> to use the function `insert-button' from button.el to allow
> navigation between links and better processing of their actions. I
> hope there are no problems with this because this function is
> auto-loaded.

It looks like a very nice feature. Some quick comments:

1. This is about the non-fancy splash screen only. In the initial
   splash screen (the one that appears after emacs starts), the links
   work. But if I later on choose Help->About Emacs, the links don't
   work; I guess since any action makes the splash screen disappear.

2. In the fancy splash screen, the text continues to cycle when the
   mouse is over a link. This means that one can have the mouse over
   the "Tutorial" link, but before one can press it the text cycles so
   that "Exit Emacs" is under the cursor. Ouch. Is there a way to
   disable the text cycling while the mouse is over a link?

Re: Scratch buffer annoyance

[Juri Linkov]

> It looks like a very nice feature. Some quick comments:
>
> 1. This is about the non-fancy splash screen only. In the initial
>    splash screen (the one that appears after emacs starts), the links
>    work. But if I later on choose Help->About Emacs, the links don't
>    work; I guess since any action makes the splash screen disappear.

Hmm, links work in `fancy-splash-screens' (started from Help->About Emacs),
but don't work in `normal-splash-screen'.  I think we should make this
screen more persistent, so only special keys (`q' and `SPC') make it
disappear.

> 2. In the fancy splash screen, the text continues to cycle when the
>    mouse is over a link. This means that one can have the mouse over
>    the "Tutorial" link, but before one can press it the text cycles so
>    that "Exit Emacs" is under the cursor. Ouch. Is there a way to
>    disable the text cycling while the mouse is over a link?

The automatic text cycling is too annoying in all regards: even if the
user doesn't finish reading one screen, it jumps to another.  I think
we should replace this with tabs where clicking on them switches to
another screen.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

    > 2. In the fancy splash screen, the text continues to cycle when the
    >    mouse is over a link. This means that one can have the mouse over
    >    the "Tutorial" link, but before one can press it the text cycles so
    >    that "Exit Emacs" is under the cursor. Ouch. Is there a way to
    >    disable the text cycling while the mouse is over a link?

    The automatic text cycling is too annoying in all regards: even if the
    user doesn't finish reading one screen, it jumps to another.

It will come back to the first screen, and most of the two screens are
identical.

This isn't perfect, but I don't know of a better option.

								  I think
    we should replace this with tabs where clicking on them switches to
    another screen.

No way!  Hardly anyone will see the second screen
if you have to explicitly ask for it.

I would be glad to find a better way, but I don't want to change
to something worse.

Re: Scratch buffer annoyance

[Juri Linkov]

>     The automatic text cycling is too annoying in all regards: even if the
>     user doesn't finish reading one screen, it jumps to another.
>
> It will come back to the first screen, and most of the two screens are
> identical.
>
> This isn't perfect, but I don't know of a better option.

The startup screen already contains information from two screens
combined into one screen.  We could do the same for the About screen.
Is the only reason for flashing screens to make them more attractive?

> 								  I think
>     we should replace this with tabs where clicking on them switches to
>     another screen.
>
> No way!  Hardly anyone will see the second screen
> if you have to explicitly ask for it.
>
> I would be glad to find a better way, but I don't want to change
> to something worse.

If we really need second screen, we could place less important information
to the second screen, and add guidelines on the first screen how to see
the second screen.  Then there are more chances that users don't miss
important information.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

    The startup screen already contains information from two screens
    combined into one screen.  We could do the same for the About screen.
    Is the only reason for flashing screens to make them more attractive?

The main motive was to display a quantity of information that was
hard to fit in one screen without its being "too much to absorb".

It can also be too much to display on a terminal.

For instance, after the recent changes, the default normal tty startup
text doesn't fit in a 24-line screen.  That is a real problem.

How shall we make it fit on a 24-line screen?

Re: Scratch buffer annoyance

[Juri Linkov]

> For instance, after the recent changes, the default normal tty startup
> text doesn't fit in a 24-line screen.  That is a real problem.
>
> How shall we make it fit on a 24-line screen?

I changed this screen to fit on 24 lines: moved "Browse manuals" to the
same line as "Emacs manual", and squeezed Useful tasks into two lines.

Also I renamed the buffer " About GNU Emacs" to "*About GNU Emacs*", and
" GNU Emacs" to "*GNU Emacs*", because otherwise it defeats the purpose of
all recent changes which was to make the *scratch* buffer less accessible.
Before renaming when the user selects a link on the startup screen (for
instance, to read the manual), and after reading exits from Info, then
the *scratch* buffer becomes the current buffer!  That's because the
leading space in the startup buffer name hides this buffer after exiting
from Info.  Now after renaming to "*GNU Emacs*", the user returns to the
startup screen after exiting from Info, and can continue reading more
information from the startup screen and can select another link.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

Thanks for the changes.

Re: Scratch buffer annoyance

[Glenn Morris]

Richard Stallman wrote:

> No way!  Hardly anyone will see the second screen
> if you have to explicitly ask for it.
>
> I would be glad to find a better way, but I don't want to change
> to something worse.

Get rid of the image. Or, display the image once only for ~ two
seconds on its own, then switch to a static splash screen with just
text. It would still be fancy in terms of fonts and colours.

Re: Scratch buffer annoyance

[Juri Linkov]

>> I would be glad to find a better way, but I don't want to change
>> to something worse.
>
> Get rid of the image. Or, display the image once only for ~ two
> seconds on its own, then switch to a static splash screen with just
> text. It would still be fancy in terms of fonts and colours.

This image is too nice to get rid of it :-)

And there is also a link to http://www.gnu.org/ on this image.  I propose
to change this link to http://www.gnu.org/software/emacs/.  In this case,
we could remove the link to http://www.gnu.org/software/emacs/tour/ from
the startup screen, because the first link on the Emacs home page is the
link to Emacs Guided Tour, so everyone visiting http://www.gnu.org/software/emacs/
will see the link to Emacs Guided Tour.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

    And there is also a link to http://www.gnu.org/ on this image.  I propose
    to change this link to http://www.gnu.org/software/emacs/.

I don't think that represents a clear link.
I think most people won't think of clicking on it.

      In this case,
    we could remove the link to http://www.gnu.org/software/emacs/tour/ from
    the startup screen, because the first link on the Emacs home page is the
    link to Emacs Guided Tour,

If we need to get rid of something, maybe that has to be it.
But perhaps it is better to go back to the two alternating screens.

Re: Scratch buffer annoyance

[Juri Linkov]

>       In this case,
>     we could remove the link to http://www.gnu.org/software/emacs/tour/ from
>     the startup screen, because the first link on the Emacs home page is the
>     link to Emacs Guided Tour,
>
> If we need to get rid of something, maybe that has to be it.
>
> But perhaps it is better to go back to the two alternating screens.

Two alternating screens still exist on the About page (accessible from the
"Help->About Emacs" menu item).

Perhaps we should put different information on the Startup page and on the
About page.  The former should be concise and contain the most necessary
information while the latter should contain more additional information
displayed on several screens.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

    Two alternating screens still exist on the About page (accessible from the
    "Help->About Emacs" menu item).

    Perhaps we should put different information on the Startup page and on the
    About page.  The former should be concise and contain the most necessary
    information while the latter should contain more additional information
    displayed on several screens.

Is there a reason for the About Emacs menu item to give usage help?
If so, I think it should be IDENTICAL to the startup buffer.

If not, then we could delete the help from About Emacs and focus on
history, developer and license information.

Re: Scratch buffer annoyance

[Juri Linkov]

> Is there a reason for the About Emacs menu item to give usage help?

No reason really.  All programs I know don't put usage help on the
About screen.  Usage help is available from other Help menu items.

> If so, I think it should be IDENTICAL to the startup buffer.
>
> If not, then we could delete the help from About Emacs and focus on
> history, developer and license information.

I agree.  Most programs have About screens with information like
program version, its short description, license (on a separate page),
credits (usually displayed as a scrolling list like in the movies),
history, and so on.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Mathias Dahl]

> > If not, then we could delete the help from About Emacs and focus on
> > history, developer and license information.
>
> I agree.  Most programs have About screens with information like
> program version, its short description, license (on a separate page),
> credits (usually displayed as a scrolling list like in the movies),
> history, and so on.

I agree with this as well.

Re: Scratch buffer annoyance

[Richard Stallman]

    > If not, then we could delete the help from About Emacs and focus on
    > history, developer and license information.

    I agree.  Most programs have About screens with information like
    program version, its short description, license (on a separate page),
    credits (usually displayed as a scrolling list like in the movies),
    history, and so on.

Would you please implement that?

Re: Scratch buffer annoyance

[Juri Linkov]

>     > If not, then we could delete the help from About Emacs and focus on
>     > history, developer and license information.
>
>     I agree.  Most programs have About screens with information like
>     program version, its short description, license (on a separate page),
>     credits (usually displayed as a scrolling list like in the movies),
>     history, and so on.
>
> Would you please implement that?

I think it would be nice to implement About pages as an Info file.

At the top level it could have links to the pages with the description,
license, credits, history ...

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

    I think it would be nice to implement About pages as an Info file.

I don't like that idea.  It isn't necessary, and the Info file might
be missing.

Re: Scratch buffer annoyance

[Juri Linkov]

>     I think it would be nice to implement About pages as an Info file.
>
> I don't like that idea.  It isn't necessary, and the Info file might
> be missing.

I don't understand why the Info file might be missing.  Like all other
Info files it will exist in the `info' directory.  And saying that
it isn't necessary, do you mean that most of this information already
exist in the Emacs manual?  In this case I agree.

If not using an Info file and not using automatically alternating screens,
I see no better UI than clicking on tabs to switch between screens.
This is how many programs display information on the About page.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Thien-Thi Nguyen]

() Juri Linkov <juri@jurta.org>
() Sat, 25 Aug 2007 17:28:44 +0300

   Like all other Info files it will exist in the `info' directory.

sometimes info files get stuck far away, in a place w/ a scary name.
that situation sucks, for sure, but people manage to do strange things.

thi

Re: Scratch buffer annoyance

[Stefan Monnier]

>> I don't like that idea.  It isn't necessary, and the Info file might
>> be missing.

> I don't understand why the Info file might be missing.  Like all other

It's hard to understand but Debian puts the doc in a separate package in the
non-free section because the GFDL is generally not considered as Free
according to Debian's definition.


        Stefan

Re: Scratch buffer annoyance

[David Kastrup]

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

>>> I don't like that idea.  It isn't necessary, and the Info file might
>>> be missing.
>
>> I don't understand why the Info file might be missing.  Like all other
>
> It's hard to understand but Debian puts the doc in a separate
> package in the non-free section because the GFDL is generally not
> considered as Free according to Debian's definition.

I should think it Debian's rather than our job to deal with the
ensuing breakage.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Scratch buffer annoyance

[Stefan Monnier]

>>>> I don't like that idea.  It isn't necessary, and the Info file might
>>>> be missing.
>> 
>>> I don't understand why the Info file might be missing.  Like all other
>> 
>> It's hard to understand but Debian puts the doc in a separate
>> package in the non-free section because the GFDL is generally not
>> considered as Free according to Debian's definition.

> I should think it Debian's rather than our job to deal with the
> ensuing breakage.

I'd tend to agree,


        Stefan

Re: Scratch buffer annoyance

[Stephen J. Turnbull]

David Kastrup writes:

 > I should think it Debian's rather than our job to deal with the
 > ensuing breakage.

I didn't know that either Debian or Emacs paid their developers.

Seriously, do whatever results in the least effort and acrimony in the
long run.  There are at least four options:

1. Spend time fielding the FAQs and explaining to the users that
Debian is at fault in hopes that they will complain and get Debian to
do something;

2. Save the users' time and bitch at Debian directly;

3. Do nothing; and

4. Make it harder for Debian to screw up this way.

My preference would be 4, in the form of GPLing the docs, but I guess
my self-interest is showing there! ;-)

Re: Scratch buffer annoyance

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> David Kastrup writes:
>
>  > I should think it Debian's rather than our job to deal with the
>  > ensuing breakage.
>
> I didn't know that either Debian or Emacs paid their developers.
>
> Seriously, do whatever results in the least effort and acrimony in the
> long run.  There are at least four options:
>
> 1. Spend time fielding the FAQs and explaining to the users that
> Debian is at fault in hopes that they will complain and get Debian to
> do something;
>
> 2. Save the users' time and bitch at Debian directly;
>
> 3. Do nothing; and
>
> 4. Make it harder for Debian to screw up this way.
>
> My preference would be 4, in the form of GPLing the docs, but I
> guess my self-interest is showing there! ;-)

GPLing the docs would mean that people could, for example, "adapt" the
GNU Manifesto to what they consider changing circumstances.  Or omit
it altogether in a print publication.  Which is a concern not just in
countries like China: "Open Source" has as one of its goals not to
frighten people away by talking about freedom and similar things.

I have just taken a look at the XEmacs manual.  It retains the
manifesto, but actually the license (the pre-GFDL-one) requires this
section to stay unmodified.  Would it be in there still if not
required by the license?

As a note aside, it is sort of amusing that the XEmacs documentation
is classified as "free" by Debian in spite of indelible, inviolate
sections, while Emacs documentation is "non-free" because of them.

I guess the GFDL by any other name smells sweeter.

Personally, I'd rather prefer at least a dual licensing of the manual
under the GPL, to make it possible for third parties to exchange
documentation between DOC strings and the manual.  However, this would
require then that they relicense the resulting manual under GPL only,
since moving DOC strings from GPLed material into something licensed
as GFDL would not be allowed.

As long as the GFDL has different aims to serve as the GPL, I don't
see that there is an easy way out.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Scratch buffer annoyance

[Richard Stallman]

    I don't understand why the Info file might be missing.  Like all other
    Info files it will exist in the `info' directory.

All sorts of things can go wrong.  Take my word for it,
this increases unreliability.  Without an important reason,
it is not worth the risk.

My decision is no.

Re: Scratch buffer annoyance

[Juri Linkov]

>     I don't understand why the Info file might be missing.  Like all other
>     Info files it will exist in the `info' directory.
>
> All sorts of things can go wrong.  Take my word for it,
> this increases unreliability.  Without an important reason,
> it is not worth the risk.

Then please also comment of the second part of my previous message:

  If not using an Info file and not using automatically alternating screens,
  I see no better UI than clicking on tabs to switch between screens.
  This is how many programs display information on the About page.

Is this acceptable?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Juri Linkov]

>       If not using an Info file and not using automatically alternating screens,
>       I see no better UI than clicking on tabs to switch between screens.
>       This is how many programs display information on the About page.
>
>     Is this acceptable?
>
> The problem it is solving is obsolete.  We already decided to remove
> the help commands from About, thus shortening it and reducing it to
> one screen.

As many programs usually contain 4 pages on the About screen: "Authors",
"Licence", "Report Bug" and "How to Contribute", Emacs could do the same
even without using Info files (which are not always available).

There are 4 files in the root directory of the Emacs tree that exactly
correspond to these 4 pages: AUTHORS, COPYING, BUGS and CONTRIBUTE.

On the About screen we could add 4 links to these files clicking on which
will open the file in another window (using `find-file-other-window').

Unfortunately, it seems that these files don't always get into Emacs
distributions.  At least, I can't find them on Debian.  Maybe this
is because these files are not in the etc directory.  What about
moving/copying them to etc where they can be found by `data-directory'?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

    As many programs usually contain 4 pages on the About screen: "Authors",
    "Licence", "Report Bug" and "How to Contribute", Emacs could do the same
    even without using Info files (which are not always available).

I don't mind having those four, but our current About display
has other things in it too, and I don't want to just discard them.

    There are 4 files in the root directory of the Emacs tree that exactly
    correspond to these 4 pages: AUTHORS, COPYING, BUGS and CONTRIBUTE.

I am not sure that all 4 of those are the right way to handle these
4 commands.

Re: Scratch buffer annoyance

[Juri Linkov]

>     As many programs usually contain 4 pages on the About screen: "Authors",
>     "Licence", "Report Bug" and "How to Contribute", Emacs could do the same
>     even without using Info files (which are not always available).
>
> I don't mind having those four, but our current About display
> has other things in it too, and I don't want to just discard them.

In the previous message you said:

    We already decided to remove the help commands from About, thus
    shortening it and reducing it to one screen.

I agree that the Help commands are useless on the About screen (that are
useful only for the Startup screen).  So after removing them we'll have
more free space for other information.

>     There are 4 files in the root directory of the Emacs tree that exactly
>     correspond to these 4 pages: AUTHORS, COPYING, BUGS and CONTRIBUTE.
>
> I am not sure that all 4 of those are the right way to handle these
> 4 commands.

All these files contain information that most programs usually put on the
About screen.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

	We already decided to remove the help commands from About, thus
	shortening it and reducing it to one screen.

    I agree that the Help commands are useless on the About screen (that are
    useful only for the Startup screen).  So after removing them we'll have
    more free space for other information.

Would you like to implement the change that we previously agreed on?
(I thought it had been implemented at the time.)

Re: Scratch buffer annoyance

[Juri Linkov]

> 	We already decided to remove the help commands from About, thus
> 	shortening it and reducing it to one screen.
>
>     I agree that the Help commands are useless on the About screen (that are
>     useful only for the Startup screen).  So after removing them we'll have
>     more free space for other information.
>
> Would you like to implement the change that we previously agreed on?
> (I thought it had been implemented at the time.)

Done.

Now it's time to think about what to put on the About screen.
As I said before, most programs usually put a short description
of the program, how to contribute and report bugs, text of the
licence and a list of authors/contributors.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

I see you cut out almost everything from the About screen.

I just did substantial work on both the fancy and text-only
startup and about screens.  I put back PART of what was there before.

    As I said before, most programs usually put a short description
    of the program, how to contribute and report bugs, text of the
    licence and a list of authors/contributors.

Some of those things are still not included in our About screens.
Could you those that is missing?

Re: Scratch buffer annoyance

[Juri Linkov]

> I just did substantial work on both the fancy and text-only
> startup and about screens.  I put back PART of what was there before.

Please see my comments on your changes:

* fancy-startup-text:

"GNU Emacs" could be linked to "http://www.gnu.org/software/emacs/" similar
to how you linked "GNU/Linux" to "http://www.gnu.org/gnu/linux-and-gnu.html".

Unfortunately, you deleted the link to the customization of the startup
screen (but other text-only startup screens still have it).  This is
essential to make it easy for the user to disable the startup screen,
because it is useful mostly for beginners, and is annoying for other users.

Text-only startup screens are welcoming, but fancy startup screen is not:
i.e. text-only screen says "Welcome to GNU Emacs, one component ...",
but fancy startup screen simply says: "GNU Emacs is one component ..."
The fancy screen could say the same.

* normal-mouse-startup-screen:

The text-only no-mouse startup screen have a link to the *scratch* buffer,
but text-only mouse startup screen doesn't.  Is it needed?

* normal-no-mouse-startup-screen:

In two places of this screen, there are two adjacent empty lines ("\n\n\n").
This wastes space and makes the screen taller than 24 lines. Should
two empty lines be changed to one?

* fancy-about-text:

I think the About screen should not duplicate items available in the Help
menu, because usually users invoke the About screen from the main menu,
where they can see other items.  For instance, "GNU and Freedom" is
available under the menu "Help / About GNU".  "Emacs Tutorial" is available
under "Help / Emacs Tutorial".

What is still missing I think is "How to contribute" and "Contributors"
from the files CONTRIBUTE and AUTHORS.  But before making a link to these
files, perhaps they should be moved to the etc directory.

* normal-about-screen:

The text-only no-mouse about screen says:
"To follow a link, click Mouse-1 on it, or move to it and type RET."
I think we should delete text "click Mouse-1 on it".

* Help menu:

To make it easier for users to find the About menu item, we could follow
the convention that the About menu item is the last item in the Help menu.

So I propose to move two menu items

About Emacs
About GNU

to the end of the Help menu, replacing "Emacs Psychotherapist".
And to move "Emacs Psychotherapist" to be after "Send Bug Report..."
and "Emacs Known Problems", thus helping users to find it to overcome
frustrations caused by Emacs bugs and problems :-)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

    Unfortunately, you deleted the link to the customization of the startup
    screen (but other text-only startup screens still have it).

The screen was too long, so I had to delete the things that were
the least important.  I chose that as the least important.

I won't put that one back in, becuase I don't want to delete any of
the other things which are there now.

Re: Scratch buffer annoyance

[Juri Linkov]

>     Unfortunately, you deleted the link to the customization of the startup
>     screen (but other text-only startup screens still have it).
>
> The screen was too long, so I had to delete the things that were
> the least important.  I chose that as the least important.
>
> I won't put that one back in, becuase I don't want to delete any of
> the other things which are there now.

There is no need to delete other things.  Please see how the line with
added "Customize This Screen" is even shorter than its previous line:

More Manuals / Ordering The FSF sells printed copies of several manuals for Emacs

To start...   Open a File   Open Home Directory   Customize This Screen

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

    To start...   Open a File   Open Home Directory   Customize This Screen

If it fits like that, and looks clear enough, you can add it.
(There needs to be "enough" space between items.)

Re: Scratch buffer annoyance

[Richard Stallman]

    Text-only startup screens are welcoming, but fancy startup screen is not:
    i.e. text-only screen says "Welcome to GNU Emacs, one component ...",
    but fancy startup screen simply says: "GNU Emacs is one component ..."
    The fancy screen could say the same.

I don't mind that change in wording.

    * normal-mouse-startup-screen:

    The text-only no-mouse startup screen have a link to the *scratch* buffer,
    but text-only mouse startup screen doesn't.  Is it needed?

There is no room for more lines in the mouse startup screen.
I had to delete that one to make the screen short enough.

    In two places of this screen, there are two adjacent empty lines ("\n\n\n").
    This wastes space and makes the screen taller than 24 lines. Should
    two empty lines be changed to one?

Please do that.

    I think the About screen should not duplicate items available in the Help
    menu, because usually users invoke the About screen from the main menu,
    where they can see other items.  For instance, "GNU and Freedom" is
    available under the menu "Help / About GNU".  "Emacs Tutorial" is available
    under "Help / Emacs Tutorial".

These things are important _for us_, so I want them there.


How can I tell Emacs that my console has no mouse?
It does not have one.

Re: Scratch buffer annoyance

[Juri Linkov]

>     I think the About screen should not duplicate items available in the Help
>     menu, because usually users invoke the About screen from the main menu,
>     where they can see other items.  For instance, "GNU and Freedom" is
>     available under the menu "Help / About GNU".  "Emacs Tutorial" is available
>     under "Help / Emacs Tutorial".
>
> These things are important _for us_, so I want them there.

Now I see why it's important to leave "GNU and Freedom".  But I think
"Emacs Tutorial" and "Emacs Guided Tour" are not important on the About
screen.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

    Now I see why it's important to leave "GNU and Freedom".  But I think
    "Emacs Tutorial" and "Emacs Guided Tour" are not important on the About
    screen.

I think they are useful, and there is room for them, so there's no
reason to argue about it.

Re: Scratch buffer annoyance

[Richard Stallman]

    What is still missing I think is "How to contribute" and "Contributors"
    from the files CONTRIBUTE and AUTHORS.  But before making a link to these
    files, perhaps they should be moved to the etc directory.

Why do you think it is desirable to move them?
Is it for installation reasons?

Re: Scratch buffer annoyance

[Juri Linkov]

>     What is still missing I think is "How to contribute" and "Contributors"
>     from the files CONTRIBUTE and AUTHORS.  But before making a link to these
>     files, perhaps they should be moved to the etc directory.
>
> Why do you think it is desirable to move them?
> Is it for installation reasons?

Yes, it is for installation reasons, but I'm not sure if moving them
to etc is enough for them to get to installations.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Glenn Morris]

Juri Linkov wrote:

> Yes, it is for installation reasons, but I'm not sure if moving them
> to etc is enough for them to get to installations.

If they were in etc, the normal `make install' rule would install
them, without any other changes being needed.

Re: Scratch buffer annoyance

[Juri Linkov]

>> Yes, it is for installation reasons, but I'm not sure if moving them
>> to etc is enough for them to get to installations.
>
> If they were in etc, the normal `make install' rule would install
> them, without any other changes being needed.

Then perhaps we should move these files to etc.  Do you see any problem
with this?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

CONTRIBUTE seems to belong properly in etc; that's logical.

maintain.texi says that AUTHORS should be "in the source directory".
Emacs has several of those, so I guess etc is ok.

So please move the two files.

Re: Scratch buffer annoyance

[Juri Linkov]

> CONTRIBUTE seems to belong properly in etc; that's logical.
>
> maintain.texi says that AUTHORS should be "in the source directory".
> Emacs has several of those, so I guess etc is ok.
>
> So please move the two files.

Done.

I also renamed `inhibit-splash-screen' to `inhibit-startup-screen',
(with keeping an alias), because this is more correct variable name.

Also I moved Emacs version information to the beginning of the fancy
About screen, exactly as you've done already for the normal About screen.
So now fancy About screen and normal About screen have the same layout.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

Thanks for making the changes.

Re: Scratch buffer annoyance

[Richard Stallman]

    The text-only no-mouse about screen says:
    "To follow a link, click Mouse-1 on it, or move to it and type RET."
    I think we should delete text "click Mouse-1 on it".

I don't think it makes any difference.  If you can't click, it tells
you the other method.  But I don't object to making this change.
Please do it if you wish.

Re: Scratch buffer annoyance

[Juri Linkov]

>     The text-only no-mouse about screen says:
>     "To follow a link, click Mouse-1 on it, or move to it and type RET."
>     I think we should delete text "click Mouse-1 on it".
>
> I don't think it makes any difference.  If you can't click, it tells
> you the other method.  But I don't object to making this change.
> Please do it if you wish.

I think we should remove the text:

"To follow a link, click Mouse-1 on it, or move to it and type RET."

It is useless.  Most users already know how to follow a link, because
everybody uses Web browsers nowadays.  And this text wastes two valuable
lines on the About screen.

Instead of this, I propose adding a help-echo property to every link,
which says what this link does.  This is especially useful when the link
leads to some URL.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

    I think we should remove the text:

    "To follow a link, click Mouse-1 on it, or move to it and type RET."

    It is useless.  Most users already know how to follow a link, because
    everybody uses Web browsers nowadays.  And this text wastes two valuable
    lines on the About screen.

I think the About screen is not crowded.

People know how to follow a link graphically, but on a tty they might
not know how, and they might not be sure these are links.  This message
makes people certain of that.  We may as well keep it.

Re: Scratch buffer annoyance

[Richard Stallman]

    * Help menu:

    To make it easier for users to find the About menu item, we could follow
    the convention that the About menu item is the last item in the Help menu.

    So I propose to move two menu items

    About Emacs
    About GNU

    to the end of the Help menu, replacing "Emacs Psychotherapist".
    And to move "Emacs Psychotherapist" to be after "Send Bug Report..."
    and "Emacs Known Problems", thus helping users to find it to overcome
    frustrations caused by Emacs bugs and problems :-)

Ok, please do.

Re: Scratch buffer annoyance

[Mathias Dahl]

> Get rid of the image. Or, display the image once only for ~ two
> seconds on its own, then switch to a static splash screen with just
> text. It would still be fancy in terms of fonts and colours.

I agree with this. The image is nice and all but it kinda draws away
the focus from the useful information, and it consumes much screen
space. I like the way GNUS does it, displaying the image while it
loads.

Re: Scratch buffer annoyance

[Juri Linkov]

>> Get rid of the image. Or, display the image once only for ~ two
>> seconds on its own, then switch to a static splash screen with just
>> text. It would still be fancy in terms of fonts and colours.
>
> I agree with this. The image is nice and all but it kinda draws away
> the focus from the useful information, and it consumes much screen
> space.

Many popular applications have a project logo on the startup page,
and there is no problem with this.

> I like the way GNUS does it, displaying the image while it loads.

Really what GNUS displays is the splash screen - an image that appears
while a program is loading.  Emacs doesn't display the splash screen while
it is loading.  It only displays the startup page.  I'm not sure whether
it's good to display an image while Emacs is loading.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

    Really what GNUS displays is the splash screen - an image that appears
    while a program is loading.  Emacs doesn't display the splash screen while
    it is loading.  It only displays the startup page.  I'm not sure whether
    it's good to display an image while Emacs is loading.

I am not necessarily against that change.
But it wouldn't really address the issue, as I pointed out before.

Re: Scratch buffer annoyance

[Richard Stallman]

    I agree with this. The image is nice and all but it kinda draws away
    the focus from the useful information, and it consumes much screen
    space. I like the way GNUS does it, displaying the image while it
    loads.

I don't think that will actually help much.

On a graphical terminal, the limit on the text is not the screen size.
The limit is the amount that a user can really absorb, which is less
than a screen full of text.  Against this limit, the image counts as
less than a line of text.

The text in the current fancy startup screen has to be reduced.

Re: Scratch buffer annoyance

[Juri Linkov]

> The text in the current fancy startup screen has to be reduced.

As Mathias already proposed, we could remove Useful File menu items
("Exit Emacs" and "Recover Crashed Session") because both are
self-explanatory and trivial to find in the menu, and the information
about how to recover session is duplicated on the same screen.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

    As Mathias already proposed, we could remove Useful File menu items
    ("Exit Emacs" and "Recover Crashed Session") because both are
    self-explanatory and trivial to find in the menu, and the information
    about how to recover session is duplicated on the same screen.

I agree.  Everyone knows where Exit is normally found in menus,
and the other message about recovering a crashed session is enough.

Re: Scratch buffer annoyance

[Juri Linkov]

>     As Mathias already proposed, we could remove Useful File menu items
>     ("Exit Emacs" and "Recover Crashed Session") because both are
>     self-explanatory and trivial to find in the menu, and the information
>     about how to recover session is duplicated on the same screen.
>
> I agree.  Everyone knows where Exit is normally found in menus,
> and the other message about recovering a crashed session is enough.

Removed.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Glenn Morris]

Richard Stallman wrote:

> On a graphical terminal, the limit on the text is not the screen size.
> The limit is the amount that a user can really absorb, which is less
> than a screen full of text.  Against this limit, the image counts as
> less than a line of text.

I'm surprised that you think having it blink from one state to another
every 5 seconds makes it easier to absorb...

20 lines of static text are much much easier to read than an image +
10 changing lines, IMO.

Re: Scratch buffer annoyance

[Mathias Dahl]

> I'm surprised that you think having it blink from one state to another
> every 5 seconds makes it easier to absorb...

I agree. It is very irritating to have the text switched just when you
were about to finish that interesting sentence you just found. I get a
bit stressed up actually.

However, that is only how the About screen started from the Help menu
works now. What is most important is to have the initial About screen
as easily understandable as possible.

Re: Scratch buffer annoyance

[Richard Stallman]

    I'm surprised that you think having it blink from one state to another
    every 5 seconds makes it easier to absorb...

The text that changes is not that big, and I would expect people to
take it in in 5 seconds.

But maybe people whose native language is not English would have
trouble.  Is that it?

Re: Scratch buffer annoyance

[Juri Linkov]

>     I'm surprised that you think having it blink from one state to
>     another every 5 seconds makes it easier to absorb...
>
> The text that changes is not that big, and I would expect people to
> take it in in 5 seconds.
>
> But maybe people whose native language is not English would have
> trouble.  Is that it?

Yes, and it takes time not only to read the text, but also understand it
and memorize information in the new program for beginners.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

    > The text that changes is not that big, and I would expect people to
    > take it in in 5 seconds.
    >
    > But maybe people whose native language is not English would have
    > trouble.  Is that it?

    Yes, and it takes time not only to read the text, but also understand it
    and memorize information in the new program for beginners.

Well, if the text in the startup buffer is small enough,
we won't have to think about alternating screens.

Re: Scratch buffer annoyance

[Richard Stallman]

    Done.  I added the variable `initial-buffer-choice' because other names
    are less appropriate.  If someone wants to change the prefix `initial-',
    please also change prefixes of related variables `initial-major-mode' and
    `initial-scratch-message'.

Thanks for installing it, but would you please describe this in
etc/NEWS, then ack?

Every feature change should be describe in etc/NEWS
when it is installed.

Re: Scratch buffer annoyance

[Juri Linkov]

>     Done.  I added the variable `initial-buffer-choice' because other names
>     are less appropriate.  If someone wants to change the prefix `initial-',
>     please also change prefixes of related variables `initial-major-mode' and
>     `initial-scratch-message'.
>
> Thanks for installing it, but would you please describe this in
> etc/NEWS, then ack?
>
> Every feature change should be describe in etc/NEWS
> when it is installed.

I described `initial-buffer-choice' in NEWS a hour after installing the
patch in startup.el, when I realized that I forgot to describe it in NEWS.
So perhaps you missed it in this short period of time.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

    I described `initial-buffer-choice' in NEWS a hour after installing the
    patch in startup.el, when I realized that I forgot to describe it in NEWS.
    So perhaps you missed it in this short period of time.

That is probably what happened.  (I did a checkout at the time, and
verified it was not yet in NEWS.)

Re: Scratch buffer annoyance

[Juri Linkov]

> To create links in the startup screen, I modified the previous patch
> to use the function `insert-button' from button.el to allow navigation
> between links and better processing of their actions.  I hope there are
> no problems with this because this function is auto-loaded.

There is one problem with using `insert-button': after starting Emacs
it displays the message "Loading button...done" in the echo area.

There is one clumsy way to prevent this.  The comment in `command-line-1'
in startup.el says:

      ;; display-splash-screen at the end of command-line-1 calls
      ;; use-fancy-splash-screens-p. This can cause image.el to be
      ;; loaded, putting "Loading image... done" in the echo area.
      ;; This hides startup-echo-area-message. So
      ;; use-fancy-splash-screens-p is called here simply to get the
      ;; loading of image.el (if needed) out of the way before
      ;; display-startup-echo-area-message runs.

But this is unnecessary because image.el is already preloaded in the
dumped Emacs.  Can we do the same and preload button.el?  This package
is very small, and it's very likely to be loaded in a Emacs session
(there are many packages using button.el including Help mode, man, etc.)

After that, we could remove this unnecessary part of `command-line-1'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

    But this is unnecessary because image.el is already preloaded in the
    dumped Emacs.  Can we do the same and preload button.el?

Assuming we stick with using buttons in the startup screen, then
definitely.

Re: Scratch buffer annoyance

[Juri Linkov]

> Those names are not good because the value is not a buffer.
> `startup-buffer-choice' is better, because at least it doesn't
> imply the value is a buffer.
>
> However, I can also suggest `startup-buffer-initialization'.
>
> `startup-buffer-style', recently suggested, is also better than
> just `startup-buffer'.

The suffix `-style' defines variations of basically the same contents
(cf. custom-buffer-style with values `brackets' and `links').

>From all proposed names I think the least bad is `startup-buffer-choice' or
`initial-buffer-choice'.  Even though the suffix `-choice' is unnecessary,
at least it is true and exactly represents the fact that this user option
has the customization type `choice'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Stefan Monnier]

> Why do you think we have text properties?  We can even propertize
> different parts of the string differently.  So we can have "namename" with
> (file t) on the first four characters and (buffer t) on the others to name
> both the file and the buffer into which it goes.  Stefan (who wants ".")
> can mark that as (directory t absolute nil) which takes care of the
> where-emacs-is-run-or-not problem, and if the string is exactly "eval",
> then its property list is evalled and we can do whatever else is needed. 

Great idea.  This way we can even extend this to allow opening several
files/buffers at startup: we just have to concatenate the corresponding file
names and buffer names (separated by spaces, for example) and place the
corresponding `buffer' or `file' property on each part.

And it's all trivial for the beginner since it still just a string: none of
that sexp madness.


        Stefan

Re: Scratch buffer annoyance

[Richard Stallman]

    Great idea.  This way we can even extend this to allow opening several
    files/buffers at startup: we just have to concatenate the corresponding file
    names and buffer names (separated by spaces, for example) and place the
    corresponding `buffer' or `file' property on each part.

    And it's all trivial for the beginner since it still just a string: none of
    that sexp madness.

I hope you are joking, because it if taken seriously, the idea is terrible.

Re: Scratch buffer annoyance

[Alfred M. Szmidt]

   Since Emacs can do everything then the splash screen could contain
   links to the most common initial actions, e.g.:

   [Visit home directory]
   [Open new file]
   [Open buffer for notes you don't want to save]
   [Emacs Tutorial]
   [Emacs FAQ]
   [Read the Emacs Manual]
   ...

And bind C-c C-c or C-x C-q to switch to the *scratch* buffer (or
clear the current buffer, and make it writable).

Re: Scratch buffer annoyance

[Dieter Wilhelm]

Juri Linkov <juri@jurta.org> writes:

> Since Emacs can do everything then the splash screen could contain links
> to the most common initial actions, e.g.:
>
> [Visit home directory]
> [Open new file]
> [Open buffer for notes you don't want to save]
> [Emacs Tutorial]
> [Emacs FAQ]
> [Read the Emacs Manual]
> ...

This is a mighty good idea!

Thinking in beginner scenarios it might be better to change the
sequence to

 [Open new file]
 [Visit home directory]
 ...

with :point on the first entry, a dired view could overwhelm some at
first, especially from the Windows world.  And when clicking the links
with the mouse--instead of a keyboard activation--the links reacting
in the same manner as if activating the commands from the menu-bar
i.e. with pop-up dialogs etc.

And, what others pointed out, an inclusion of a link to the splash
buffer customisation.  Perfect, I have to say!

-- 
    Best wishes

    H. Dieter Wilhelm
    Darmstadt, Germany

Re: Scratch buffer annoyance

[Juri Linkov]

>> [Visit home directory]
>> [Open new file]
>> [Open buffer for notes you don't want to save]
>> [Emacs Tutorial]
>> [Emacs FAQ]
>> [Read the Emacs Manual]
>> ...
>
> This is a mighty good idea!
>
> Thinking in beginner scenarios it might be better to change the
> sequence to
>
>  [Open new file]
>  [Visit home directory]
>  ...

In the latest patch, the order is the following:

[Create New File]        Visit new file.
[Visit Home Directory]   Visit home directory.
[Visit *scratch* Buffer] Visit buffer for notes you don't want to save,
                         and for Lisp evaluation.

This seems good because [Create New File] is before [Visit *scratch* Buffer],
so when a writer starts writing a story, the first link to click will be
[Create New File], and not [Visit *scratch* Buffer], so he wouldn't lose
his masterpiece.

> with :point on the first entry, a dired view could overwhelm some at
> first, especially from the Windows world.  And when clicking the links
> with the mouse--instead of a keyboard activation--the links reacting
> in the same manner as if activating the commands from the menu-bar
> i.e. with pop-up dialogs etc.

Clicking on [Create New File] pop-ups the File Open dialog in the same way
as clicking [Visit New File] in the File menu.

> And, what others pointed out, an inclusion of a link to the splash
> buffer customisation.  Perfect, I have to say!

In the latest patch, the customization link points to the inhibit-splash-screen,
but later should be changed to customize `visit-on-startup'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Scratch buffer annoyance

[Drew Adams]

> >> splash screen could contain links to the most common initial actions:
> >>
> >> [Visit home directory]
> >> [Open new file]
> >> [Open buffer for notes you don't want to save]
> >> [Emacs Tutorial]
> >> [Emacs FAQ]
> >> [Read the Emacs Manual]
> >> ...
> >
> > it might be better to change the sequence to
> >
> >  [Open new file]
> >  [Visit home directory]
> >  ...
>
> In the latest patch, the order is the following:
>
> [Create New File]        Visit new file.
> [Visit Home Directory]   Visit home directory.
> [Visit *scratch* Buffer] Visit buffer for notes you don't want
>                          to save, and for Lisp evaluation.

1. I agree about the order: create new file first.


2. Instead of [Visit *scratch* Buffer], it should say [Visit Scratch Lisp
Buffer].


3. We should get rid of the descriptions next to the links. "Visit new file"
is wrong, anyway; "Create New File" is better on its own. "Visit home
directory" adds nothing. "Scratch" implies not automatically saving - think
of scratch pad and scratch paper.

If we must have descriptions next to the links, then use this for *scratch*:
"Visit buffer *scratch* for Lisp interaction that is not saved
automatically".


4. Instead of [Visit home directory], it should say [Visit directory]. Which
directory to visit should be customizable, with `~/' as the default value.
Add an option `splash-screen-directory-to-visit' to custom group
`fancy-splash-screen'.


5. Option `visit-on-startup' should be in a new custom group,
`startup-display'. This would be a child of group `initialization', and it
would include custom group `fancy-splash-screen' as a subgroup.
(`visit-on-startup' does not belong in group `fancy-splash-screen'.)


6. The final link of the splash screen, [Customize Startup Display], would
then send you to the customize buffer for this group, `startup-display',
which would show this:

  `visit-on-startup' [Hide Value] [Value Menu]
  What to show/visit on startup.

  `fancy-splash-screen' group: Go to Group
  Fancy splash screen when Emacs starts.


7. BTW, if we add `visit-on-startup', do we still need
`inhibit-splash-screen'? (no)


8. Here's a summary of the new custom stuff proposed:

(defgroup startup-display ()
  "Options for what is displayed when Emacs starts up."
  :version "22" :group 'initialization)

(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 'startup-display)


(defgroup fancy-splash-screen ()
  "Fancy splash screen when Emacs starts."
  :version "21.1" :group 'startup-display)

(defcustom splash-screen-directory-to-visit "~/"
  "Directory to visit when you click [Visit directory] on splash screen."
  :version "22" :group 'fancy-splash-screen)

Re: Scratch buffer annoyance

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

> 2. Instead of [Visit *scratch* Buffer], it should say [Visit Scratch Lisp
> Buffer].
>
>
> 3. We should get rid of the descriptions next to the links. "Visit new file"
> is wrong, anyway; "Create New File" is better on its own. "Visit home
> directory" adds nothing. "Scratch" implies not automatically saving - think
> of scratch pad and scratch paper.
>
> If we must have descriptions next to the links, then use this for *scratch*:
> "Visit buffer *scratch* for Lisp interaction that is not saved
> automatically".
>
>
> 4. Instead of [Visit home directory], it should say [Visit directory]. Which
> directory to visit should be customizable, with `~/' as the default value.
> Add an option `splash-screen-directory-to-visit' to custom group
> `fancy-splash-screen'.

I consider all of those proposals a change for the worse for a
beginner, and the splash screen is a tool dedicated to the beginner.
If you really must have a customizable splash screen, then it makes
sense to make the _whole_ list a single customizable list, with
several preselectable functions and parameters and texts which one can
replace.

But the default text should _not_ try to take into account that people
might want to mangle the function without having to mangle the button
inscriptions.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Scratch buffer annoyance

[Richard Stallman]

    I consider all of those proposals a change for the worse for a
    beginner, and the splash screen is a tool dedicated to the beginner.

Why do you think it is worse for the beginner?

Re: Scratch buffer annoyance

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     I consider all of those proposals a change for the worse for a
>     beginner, and the splash screen is a tool dedicated to the beginner.
>
> Why do you think it is worse for the beginner?

"all of those proposals" meant the three concrete suggestions by Drew
(which you did not also cite, and for which I explained the reason of
me not liking them): the discussed state of the proposal was quite
better without his amendments.

But it would be much better than what we have now in CVS in either
case.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Scratch buffer annoyance

[Juri Linkov]

>>     I consider all of those proposals a change for the worse for a
>>     beginner, and the splash screen is a tool dedicated to the beginner.
>>
>> Why do you think it is worse for the beginner?
>
> "all of those proposals" meant the three concrete suggestions by Drew
> (which you did not also cite, and for which I explained the reason of
> me not liking them): the discussed state of the proposal was quite
> better without his amendments.
>
> But it would be much better than what we have now in CVS in either
> case.

Then perhaps now we should install the patch that adds three links to the
splash screen, revert auto-saving *scratch* buffer, and continue this
discussion about new customization options and more links on the splash
screen.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Scratch buffer annoyance

[Richard Stallman]

    Then perhaps now we should install the patch that adds three links to the
    splash screen, revert auto-saving *scratch* buffer, and continue this
    discussion about new customization options and more links on the splash
    screen.

We are not yet ready.  I asked a few questions yesterday about details
of this feature.

When this is ready, we should install it as an option, so we can try it
out.

RE: Scratch buffer annoyance

[Drew Adams]

1. We can drop the verbs "Create", "Visit", and "Read", and we can drop
"Emacs":

 [New File]
 [Directory]
 [Scratch Lisp Buffer]
 [Tutorial]
 [FAQ]
 [Manual]

 [Customize Startup Display]


2. I don't use Emacs as a Web browser, so I don't know how feasible or how
useful this might be (e.g. current status of w3), but if it makes sense we
could also add a [URL] link, to a (customizable) URL. The default value
could be http://www.gnu.org/software/emacs.

We could then also add a URL choice to the possibilities for
`visit-on-startup'. That way, if a user used Emacs itself as a Web browser,
then s?he could choose to start Emacs on a Web page (browser home page).

Re: Scratch buffer annoyance

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

> 1. We can drop the verbs "Create", "Visit", and "Read", and we can drop
> "Emacs":
>
>  [New File]
>  [Directory]
>  [Scratch Lisp Buffer]
>  [Tutorial]
>  [FAQ]
>  [Manual]
>
>  [Customize Startup Display]

Why would we want to do that?  This is a splash screen, not a side bar.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Scratch buffer annoyance

[Richard Stallman]

    2. Wrt #2, I prefer my idea of having a user option, `visit-on-startup', to
    specify the startup behavior.

I am in favor of this option -- would someone please add it?

However, that doesn't solve the problem of making *scratch* work
conveniently.