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.
>>
>
> I flagged the problem of empty scratch buffer on Feb 13 2008 [1]. This
> means that a few hours before someone patched Emacs to reach that
> new behaviour.
>
> So, does this mean that Emacs at that time was not in pretest phase?
>
> If I remember correctly 22.1.91 has the empty scratch buffer but
> 22.1.90 not.
>
> I think that if Emacs was in pretest on Feb 13, than, since that time, one
> had to object on the new behaviour (empty scratch buffer), not only now
> that the acient behaviour has been restored.

I guess you are using desktop mode.  So disabling the startup screen
after loading the desktop helped you to discover the problem of leaving
the scratch buffer empty that also affects more use cases (running
Emacs with command line arguments and other cases that automatically
disable the startup screen).  Thank you for reporting this problem.

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