On the new startup and scratch buffer

On the new startup and scratch buffer

[Angelo Graziosi]

Today, after a bootstrap of fresh CVS, I observe that the startup buffer 
is not loaded any more and the scratch buffer is *completely* empty.


Usually the scratch buffer contains (in red) this sentence:

============================================================
;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, visit that file with C-x C-f,
;; then enter the text in that file's own buffer.
============================================================

Is this the correct behaviour?

The behaviour of the startup screen is confirmed by this

-----------------------------------------------------------------
lisp/ChangeLog
[...]
           * desktop.el (after-init-hook): Set inhibit-startup-screen to
             t after reading the desktop.
-----------------------------------------------------------------

but I cannot find any reference to the new behaviour of scratch buffer.



Cheers,
    Angelo.

Re: On the new startup and scratch buffer

[Jonathan Rockway]

* On Wed, Feb 13 2008, Angelo Graziosi wrote:
> Today, after a bootstrap of fresh CVS, I observe that the startup
> buffer is not loaded any more and the scratch buffer is *completely*
> empty.
>
>
> Usually the scratch buffer contains (in red) this sentence:
>
> ============================================================
> ;; This buffer is for notes you don't want to save, and for Lisp evaluation.
> ;; If you want to create a file, visit that file with C-x C-f,
> ;; then enter the text in that file's own buffer.
> ============================================================
>
> Is this the correct behaviour?
>
> The behaviour of the startup screen is confirmed by this
>
> -----------------------------------------------------------------
> lisp/ChangeLog
> [...]
>           * desktop.el (after-init-hook): Set inhibit-startup-screen to
>             t after reading the desktop.
> -----------------------------------------------------------------

According to the docstring on `initial-scratch-message':

   "Initial message displayed in *scratch* buffer at startup.
    If this is nil, no message will be displayed.
    If `inhibit-startup-screen' is non-nil, then no message is displayed,
    regardless of the value of this variable."

So it looks like this is expected, although annoying.  This just looks
like a side effect of having this block:

      (and initial-scratch-message
	   (get-buffer "*scratch*")
	   (with-current-buffer "*scratch*"
	     (when (zerop (buffer-size))
	       (insert initial-scratch-message)
	       (set-buffer-modified-p nil))))

On the "else" side of the (if (or ... inhibit-startup-screen ...) ...)
statement.

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.

Regards,
Jonathan Rockway

Re: On the new startup and scratch buffer

[Angelo Graziosi]

Jonathan Rockway ha scritto:
> * On Wed, Feb 13 2008, Angelo Graziosi wrote:
>> Today, after a bootstrap of fresh CVS, I observe that the startup
>> buffer is not loaded any more and the scratch buffer is *completely*
>> empty.
>>
>>
>> Usually the scratch buffer contains (in red) this sentence:
>>
>> ============================================================
>> ;; This buffer is for notes you don't want to save, and for Lisp evaluation.
>> ;; If you want to create a file, visit that file with C-x C-f,
>> ;; then enter the text in that file's own buffer.
>> ============================================================
>>
>> Is this the correct behaviour?
>>
>> The behaviour of the startup screen is confirmed by this
>>
>> -----------------------------------------------------------------
>> lisp/ChangeLog
>> [...]
>>           * desktop.el (after-init-hook): Set inhibit-startup-screen to
>>             t after reading the desktop.
>> -----------------------------------------------------------------
> 
> According to the docstring on `initial-scratch-message':
> 
>    "Initial message displayed in *scratch* buffer at startup.
>     If this is nil, no message will be displayed.
>     If `inhibit-startup-screen' is non-nil, then no message is displayed,
>     regardless of the value of this variable."
> 
> So it looks like this is expected, although annoying.  This just looks
> like a side effect of having this block:
> 
>       (and initial-scratch-message
> 	   (get-buffer "*scratch*")
> 	   (with-current-buffer "*scratch*"
> 	     (when (zerop (buffer-size))
> 	       (insert initial-scratch-message)
> 	       (set-buffer-modified-p nil))))
> 
> On the "else" side of the (if (or ... inhibit-startup-screen ...) ...)
> statement.
> 
> 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.
> 

I think it would be a good thing, so I vote for it: +1.



Thanks,
    Angelo.

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.
>
> I think it would be a good thing, so I vote for it: +1.

I agree that `inhibit-startup-screen' is irrelevant to adding the
text from `initial-scratch-message' to the *scratch* buffer.

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

Re: On the new startup and scratch buffer

[Stefan Monnier]

>>> 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.
>> 
>> I think it would be a good thing, so I vote for it: +1.

> I agree that `inhibit-startup-screen' is irrelevant to adding the
> text from `initial-scratch-message' to the *scratch* buffer.

+1


        Stefan

[patch] Re: On the new startup and scratch buffer

[Jonathan Rockway]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

>>>> 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.
>>> 
>>> I think it would be a good thing, so I vote for it: +1.
>
>> I agree that `inhibit-startup-screen' is irrelevant to adding the
>> text from `initial-scratch-message' to the *scratch* buffer.
>
> +1

Hi, the patch for this is attached.  I'm not sure if
`emacs-quick-startup' should affect insertion of the message or not (it
did before) -- this patch will always insert the message if
`initial-scratch-message' is non-nil.

Regards,
Jonathan Rockway


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: show initial-scratch-message in *scratch* even if inhibit-startup-screen is non-nil --]
[-- Type: text/x-diff, Size: 2093 bytes --]

Index: lisp/startup.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/startup.el,v
retrieving revision 1.477
diff -C 2 -r1.477 startup.el
*** lisp/startup.el	12 Feb 2008 23:41:08 -0000	1.477
--- lisp/startup.el	14 Feb 2008 04:08:15 -0000
***************
*** 57,61 ****
  (defcustom inhibit-startup-screen nil
    "Non-nil inhibits the startup screen.
- It also inhibits display of the initial message in the `*scratch*' buffer.
  
  This is for use in your personal init file (but NOT site-start.el), once
--- 57,60 ----
***************
*** 1151,1157 ****
  ")
    "Initial message displayed in *scratch* buffer at startup.
! If this is nil, no message will be displayed.
! If `inhibit-startup-screen' is non-nil, then no message is displayed,
! regardless of the value of this variable."
    :type '(choice (text :tag "Message")
  		 (const :tag "none" nil))
--- 1150,1154 ----
  ")
    "Initial message displayed in *scratch* buffer at startup.
! If this is nil, no message will be displayed."
    :type '(choice (text :tag "Message")
  		 (const :tag "none" nil))
***************
*** 2181,2184 ****
--- 2178,2189 ----
  	     (find-file initial-buffer-choice))))
  
+     ;; If *scratch* exists and is empty, insert initial-scratch-message.
+     (and initial-scratch-message
+          (get-buffer "*scratch*")
+          (with-current-buffer "*scratch*"
+            (when (zerop (buffer-size))
+              (insert initial-scratch-message)
+              (set-buffer-modified-p nil))))
+     
      (if (or inhibit-startup-screen
  	    initial-buffer-choice
***************
*** 2226,2237 ****
        ;; 	(setq menubar-bindings-done t))
  
-       ;; If *scratch* exists and is empty, insert initial-scratch-message.
-       (and initial-scratch-message
- 	   (get-buffer "*scratch*")
- 	   (with-current-buffer "*scratch*"
- 	     (when (zerop (buffer-size))
- 	       (insert initial-scratch-message)
- 	       (set-buffer-modified-p nil))))
- 
        (if (> file-count 0)
  	  (display-startup-screen t)
--- 2231,2234 ----

Re: On the new startup and scratch buffer

[Sascha Wilde]

Angelo Graziosi <angelo.graziosi@alice.it> wrote:
> Jonathan Rockway ha scritto:
[...]
>> According to the docstring on `initial-scratch-message':
>>
>>    "Initial message displayed in *scratch* buffer at startup.
>>     If this is nil, no message will be displayed.
>>     If `inhibit-startup-screen' is non-nil, then no message is displayed,
>>     regardless of the value of this variable."
>>
>> So it looks like this is expected, although annoying.  This just looks
>> like a side effect of having this block:
>>
>>       (and initial-scratch-message
>> 	   (get-buffer "*scratch*")
>> 	   (with-current-buffer "*scratch*"
>> 	     (when (zerop (buffer-size))
>> 	       (insert initial-scratch-message)
>> 	       (set-buffer-modified-p nil))))
>>
>> On the "else" side of the (if (or ... inhibit-startup-screen ...) ...)
>> statement.
>>
>> 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.
>>
>
> I think it would be a good thing, so I vote for it: +1.

AOL: +1

As initial-scratch-message is sufficient to disable the *scratch*
message in case one wants to, inhibit-startup-screen shouldn't do so.

cheers
sascha
-- 
Sascha Wilde

I've always figured UNIX is a utility to be run under emacs.
	-- Charles R. Martin

Re: On the new startup and scratch buffer

[Jonathan Rockway]

* On Thu, Feb 21 2008, Sascha Wilde wrote:
> Angelo Graziosi <angelo.graziosi@alice.it> wrote:
>> Jonathan Rockway ha scritto:
>>>
>>> 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.
>>>
>>
>> I think it would be a good thing, so I vote for it: +1.
>
> AOL: +1

I posted the patch a week or so ago, but haven't heard anything yet.
Please try it out and let me know if anything needs to be changed.

  http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01136.html

Regards,
Jonathan Rockway

Re: On the new startup and scratch buffer

[Angelo Graziosi]

Jonathan Rockway ha scritto:
> * On Thu, Feb 21 2008, Sascha Wilde wrote:
>> Angelo Graziosi <angelo.graziosi@alice.it> wrote:
>>> Jonathan Rockway ha scritto:
>>>> 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.
>>>>
>>> I think it would be a good thing, so I vote for it: +1.
>> AOL: +1
> 
> I posted the patch a week or so ago, but haven't heard anything yet.
> Please try it out and let me know if anything needs to be changed.
> 
>   http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01136.html
> 
> Regards,
> Jonathan Rockway

Sorry for the late replay.

I have applied it in the builds on Linux and Cygwin. It looks OK to me. 
Now the *Scratch* buffer appears as I always knew it.


Cheers,
    Angelo.

---
Stat rosa pristina nomine, nomina nuda tenemus.

Re: On the new startup and scratch buffer

[Juri Linkov]

>> Angelo Graziosi <angelo.graziosi@alice.it> wrote:
>>> Jonathan Rockway ha scritto:
>>>>
>>>> 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.
>>>>
>>>
>>> I think it would be a good thing, so I vote for it: +1.
>>
>> AOL: +1
>
> I posted the patch a week or so ago, but haven't heard anything yet.
> Please try it out and let me know if anything needs to be changed.

Thanks.

>   http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01136.html

Installed on the trunk and the Emacs 22 branch.

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

Re: On the new startup and scratch buffer

[Juri Linkov]

> Installed on the trunk and the Emacs 22 branch.

I also fixed a problem that when Emacs doesn't show the fancy startup screen
and uses `normal-splash-screen' instead of `fancy-startup-screen' then
it should follow the same logic that if there are a file name given on the
command line then it should display the first file in the top window and
the startup screen in another window below it.

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

Re: On the new startup and scratch buffer

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Fri, 29 Feb 2008 01:40:21 +0200
> Cc: Jonathan Rockway <jon@jrock.us>, Angelo Graziosi <angelo.graziosi@alice.it>
> 
> > Installed on the trunk and the Emacs 22 branch.
> 
> I also fixed a problem that when Emacs doesn't show the fancy startup screen
> and uses `normal-splash-screen' instead of `fancy-startup-screen' then
> it should follow the same logic that if there are a file name given on the
> command line then it should display the first file in the top window and
> the startup screen in another window below it.

Are such changes in behavior really necessary at this stage in the
pretest?

Re: On the new startup and scratch buffer

[Juri Linkov]

>> I also fixed a problem that when Emacs doesn't show the fancy startup screen
>> and uses `normal-splash-screen' instead of `fancy-startup-screen' then
>> it should follow the same logic that if there are a file name given on the
>> command line then it should display the first file in the top window and
>> the startup screen in another window below it.
>
> Are such changes in behavior really necessary at this stage in the
> pretest?

These fixes are caused by changes made earlier on the Emacs 22 branch.
They are part of fixes that are intended to implement the behavior agreed
on emacs-devel and approved several times to do on the Emacs 22 branch.
Since they fix unintentional behavior they can be named bug fixes.

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

Re: On the new startup and scratch buffer

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: emacs-devel@gnu.org,  jon@jrock.us,  angelo.graziosi@alice.it
> Date: Fri, 29 Feb 2008 23:31:42 +0200
> 
> > Are such changes in behavior really necessary at this stage in the
> > pretest?
> 
> These fixes are caused by changes made earlier on the Emacs 22 branch.
> They are part of fixes that are intended to implement the behavior agreed
> on emacs-devel and approved several times to do on the Emacs 22 branch.
> Since they fix unintentional behavior they can be named bug fixes.

We can name it whatever we want, but it won't change the facts: a
non-trivial behavior change was introduced into a pretest that was
five minutes before its last .9X version, the one that should have
been followed by a release.  If I were in Stefan's and Yidong's shoes
now, I'd probably insist on another .9X pretest.

It's too bad that the behavior ``agreed on emacs-devel and approved
several times to do on the Emacs 22 branch'' was not added to the code
enough time ago, but this sad fact does not mean such changes should
be allowed to be installed now without additional discussions, IMO.

Re: On the new startup and scratch buffer

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Fri, 29 Feb 2008 01:00:41 +0200
> Cc: Sascha Wilde <wilde@sha-bang.de>,
> 	Angelo Graziosi <angelo.graziosi@alice.it>, emacs-devel@gnu.org
> 
> >   http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01136.html
> 
> Installed on the trunk and the Emacs 22 branch.

Why?  I thought we were asked not to install anything on the release
branch that isn't a clear bugfix, without asking first.

Re: On the new startup and scratch buffer

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

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

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/

Re: On the new startup and scratch buffer

[Angelo Graziosi]

Juri Linkov ha scritto:
>>>>>>> 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.


Cheers,
    Angelo.

---
[1] http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01044.html

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/

Re: On the new startup and scratch buffer

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

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

No.  I just checked this: in 22.1, non-nil inhibit-startup-message
causes Emacs to start up with an empty scratch buffer, the same as in
Emacs 21.

For compatibility, I think your patch has to be modified so that
inhibit-startup-message is no longer an alias of
inhibit-startup-screen, and then make it do what it did in Emacs 22
(i.e, display an empty scratch buffer on startup).

In the meantime, however, please revert this change for the 22.2
release.

Re: On the new startup and scratch buffer

[Juri Linkov]

>> 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.
>>
>>     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).
>
> No.  I just checked this: in 22.1, non-nil inhibit-startup-message
> causes Emacs to start up with an empty scratch buffer, the same as in
> Emacs 21.

The problem here is in the terminology: in Emacs 21 "startup message"
meant the same thing as "splash screen" in Emacs 22 that we later
renamed to "startup screen".  In contrast, the initial text in the
scratch buffer is named "initial scratch message", not "startup message".

The fact that `inhibit-startup-message' also disabled the initial
scratch message as a side effect now created a problem that users
who need to see the initial scratch message will not get it.

> For compatibility, I think your patch has to be modified so that
> inhibit-startup-message is no longer an alias of
> inhibit-startup-screen, and then make it do what it did in Emacs 22
> (i.e, display an empty scratch buffer on startup).

Another solution is to create a new internal variable and set it in
places that automatically disable the startup screen.  This variable
will be separate from the user option `inhibit-startup-screen'.
So when the user has explicitly disabled the startup screen by setting
`inhibit-startup-screen' (or its aliases) to non-nil, then the scratch
buffer will be empty.  Otherwise, when the startup screen is automatically
disabled, the user will see the initial scratch message in the scratch buffer.

> In the meantime, however, please revert this change for the 22.2
> release.

OK, reverted.

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

Re: On the new startup and scratch buffer

[Johan Bockgård]

Juri Linkov <juri@jurta.org> writes:

> The recent patch was installed after complaints from users that even
> when initial-scratch-message is non-nil the scratch buffer is still
> empty.

I agree that `inhibit-startup-screen' should not disable the scratch
message, but I think that emacs-quick-startup (-Q) should. (After your
patch it doesn't.)

-- 
Johan Bockgård

Re: On the new startup and scratch buffer

[Stefan Monnier]

>> The recent patch was installed after complaints from users that even
>> when initial-scratch-message is non-nil the scratch buffer is still
>> empty.

> I agree that `inhibit-startup-screen' should not disable the scratch
> message, but I think that emacs-quick-startup (-Q) should. (After your
> patch it doesn't.)

I see no reason why -Q should inhibit the scratch message.
It's probably OK if it does, but it seems preferable if it doesn't.


        Stefan

Re: On the new startup and scratch buffer

[Juri Linkov]

>>> The recent patch was installed after complaints from users that even
>>> when initial-scratch-message is non-nil the scratch buffer is still
>>> empty.
>
>> I agree that `inhibit-startup-screen' should not disable the scratch
>> message, but I think that emacs-quick-startup (-Q) should. (After your
>> patch it doesn't.)
>
> I see no reason why -Q should inhibit the scratch message.
> It's probably OK if it does, but it seems preferable if it doesn't.

One reason for -Q to inhibit the scratch message is backward
compatibility: when the user sends a bug report for Emacs 22.1 that
says: "Run emacs -Q and in the scratch buffer do this and that..."
then the result may be different depending on the initial text in
the scratch buffer.

OTOH, users include the version number in bug reports anyway, and
using the same version to reproduce the reported bug will give the
same result.  So I see no more reasons to inhibit the scratch message
for -Q.

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

Re: On the new startup and scratch buffer

[Juri Linkov]

>> The recent patch was installed after complaints from users that even
>> when initial-scratch-message is non-nil the scratch buffer is still
>> empty.
>
> I agree that `inhibit-startup-screen' should not disable the scratch
> message, but I think that emacs-quick-startup (-Q) should. (After your
> patch it doesn't.)

Actually, this initial scratch message serves as a quick visual reminder
for the user that the current buffer is the scratch buffer (that doesn't
save its content) even when Emacs is stared with `emacs -Q'.

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