From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Scratch buffer annoyance Date: Tue, 17 Jul 2007 10:48:53 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1184694666 29855 80.91.229.12 (17 Jul 2007 17:51:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 17 Jul 2007 17:51:06 +0000 (UTC) Cc: kfogel@red-bean.com, sdl.web@gmail.com, emacs-devel@gnu.org To: , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 17 19:51:00 2007 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 1IArCM-0005M4-A3 for ged-emacs-devel@m.gmane.org; Tue, 17 Jul 2007 19:50:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IArCL-0000tR-TD for ged-emacs-devel@m.gmane.org; Tue, 17 Jul 2007 13:50:57 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IArCH-0000sW-8s for emacs-devel@gnu.org; Tue, 17 Jul 2007 13:50:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IArCG-0000sA-Op for emacs-devel@gnu.org; Tue, 17 Jul 2007 13:50:52 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IArCG-0000s7-D4 for emacs-devel@gnu.org; Tue, 17 Jul 2007 13:50:52 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IArC9-0000vS-VO; Tue, 17 Jul 2007 13:50:46 -0400 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l6HHofFr018713; Tue, 17 Jul 2007 12:50:41 -0500 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l6HHFoe8026436; Tue, 17 Jul 2007 11:50:38 -0600 Original-Received: from dhcp-amer-csvpn-gw1-141-144-64-147.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 3046463501184694538; Tue, 17 Jul 2007 10:48:58 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: Linux 2.4-2.6 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:75006 Archived-At: > 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.