Re: On the new startup and scratch buffer

[Juri Linkov]

>>>>>> If people are interested in a change to this behavior (always add text
>>>>>> to *scratch* if initial-scratch-message isn't nil), I'll supply a patch.
>>
>> Installed on the trunk and the Emacs 22 branch.
>
> I'm not convinced that this change should go into Emacs 22.  The
> reason is a little subtle.
>
> If you check the changelogs, inhibit-startup-screen used to be called
> inhibit-startup-message, and i-s-m is now an alias for i-s-s.
>
> With this change, people who've been using Emacs for a while and have
> inhibit-startup-message bound to nil in their init file (as I did)
> will encounter unexpected behavior.  In other words, even though
> inhibit-startup-message is non-nil, there's a startup message!
>
> It's scarcely a serious issue---after all, Emacs progresses, and the
> meanings of variables change.  All the same, this kind of
> incompatibility is best introduced between major versions.

OK, let's do everything what would be the best now to avoid any kind of
incompatibility for the upcoming release, but I still don't understand
the problem.

I see there are two very similarly named user options (that adds
more confusion to this already complicated issue):

    inhibit-startup-message
    initial-scratch-message

The option inhibit-startup-message as an alias for inhibit-startup-screen
still disables the startup screen regardless of the value of
initial-scratch-message.

In 22.1, inhibit-startup-message was an alias for inhibit-splash-screen
that disables the startup screen.  So users who have inhibit-startup-message
set to non-nil in .emacs will not see the startup screen (though they will
see the initial message in the scratch buffer if not explicitly disabled it
using nil for initial-scratch-message).

The recent patch was installed after complaints from users that even when
initial-scratch-message is non-nil the scratch buffer is still empty.
This is caused by the changes that allow more command line options and
other conditions to disable the startup screen and thus to ignore the
value of initial-scratch-message.  This is bad because many users and
especially novices will miss this important text in the scratch buffer
after running Emacs with command line arguments.

We can expect more such complaints after the release if we will deliver
a version that disregards the value of initial-scratch-message after
disabling the startup screen.

Given these facts, please decide what would be the best to do now.

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