From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: On the new startup and scratch buffer Date: Sun, 02 Mar 2008 16:41:45 +0200 Organization: JURTA Message-ID: <873ar9mecr.fsf@jurta.org> References: <47B319AD.3030804@alice.it> <87zlu4oi48.fsf@bar.jrock.us> <47B3320C.8060800@alice.it> <87ve4ip7g1.fsf@bar.jrock.us> <873arcvg86.fsf@jurta.org> <87hcfrid17.fsf@stupidchicken.com> <87ablhu96w.fsf@jurta.org> <47CA77FF.2000306@alice.it> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1204469062 21232 80.91.229.12 (2 Mar 2008 14:44:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Mar 2008 14:44:22 +0000 (UTC) Cc: Sascha Wilde , Chong Yidong , Jonathan Rockway , emacs-devel@gnu.org To: Angelo Graziosi Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 02 15:44:46 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JVpQj-000312-TD for ged-emacs-devel@m.gmane.org; Sun, 02 Mar 2008 15:44:46 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JVpQD-0003GH-4I for ged-emacs-devel@m.gmane.org; Sun, 02 Mar 2008 09:44:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JVpPR-0002TU-Ld for emacs-devel@gnu.org; Sun, 02 Mar 2008 09:43:25 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JVpPP-0002QS-PR for emacs-devel@gnu.org; Sun, 02 Mar 2008 09:43:25 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JVpPP-0002Q0-Dl for emacs-devel@gnu.org; Sun, 02 Mar 2008 09:43:23 -0500 Original-Received: from relay03.kiev.sovam.com ([62.64.120.201]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JVpPO-0001AD-Gs for emacs-devel@gnu.org; Sun, 02 Mar 2008 09:43:23 -0500 Original-Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay03.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1JVpPJ-000A4A-Om; Sun, 02 Mar 2008 16:43:20 +0200 In-Reply-To: <47CA77FF.2000306@alice.it> (Angelo Graziosi's message of "Sun, 02 Mar 2008 10:48:47 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-unknown-linux-gnu) X-Scanner-Signature: efe3bc1504fa577d936f03857ce6b673 X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2347 [Mar 2 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {HEADERS: header Content-Type found without required header Content-Transfer-Encoding} X-SpamTest-Method: none X-SpamTest-Rate: 11 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release X-detected-kernel: by monty-python.gnu.org: FreeBSD 6.x (1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:91061 Archived-At: >>>>>>>> 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/