From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Scratch buffer annoyance Date: Wed, 01 Aug 2007 09:46:44 +0200 Message-ID: <864pjjpuhn.fsf@lola.quinscape.zz> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1185954429 8329 80.91.229.12 (1 Aug 2007 07:47:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 1 Aug 2007 07:47:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 01 09:47:01 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 1IG8v3-0005zO-TT for ged-emacs-devel@m.gmane.org; Wed, 01 Aug 2007 09:46:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IG8v3-00052z-9B for ged-emacs-devel@m.gmane.org; Wed, 01 Aug 2007 03:46:57 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IG8uy-0004zt-AG for emacs-devel@gnu.org; Wed, 01 Aug 2007 03:46:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IG8ut-0004xQ-Ir for emacs-devel@gnu.org; Wed, 01 Aug 2007 03:46:50 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IG8ut-0004xN-Cr for emacs-devel@gnu.org; Wed, 01 Aug 2007 03:46:47 -0400 Original-Received: from pc3.berlin.powerweb.de ([62.67.228.11]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IG8us-00031n-JN for emacs-devel@gnu.org; Wed, 01 Aug 2007 03:46:47 -0400 Original-Received: from quinscape.de (dslnet.212-29-44.ip210.dokom.de [212.29.44.210] (may be forged)) by pc3.berlin.powerweb.de (8.9.3p3/8.9.3) with ESMTP id JAA05817 for ; Wed, 1 Aug 2007 09:46:44 +0200 X-Delivered-To: Original-Received: (qmail 8318 invoked from network); 1 Aug 2007 07:46:45 -0000 Original-Received: from unknown (HELO lola.quinscape.zz) ([10.0.3.43]) (envelope-sender ) by ns.quinscape.de (qmail-ldap-1.03) with SMTP for ; 1 Aug 2007 07:46:45 -0000 Original-Received: by lola.quinscape.zz (Postfix, from userid 1001) id CF1EE8FA2F; Wed, 1 Aug 2007 09:46:44 +0200 (CEST) In-Reply-To: (Drew Adams's message of "Tue\, 31 Jul 2007 23\:18\:26 -0700") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.51 (gnu/linux) 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:75888 Archived-At: "Drew Adams" writes: >> > (defcustom visit-on-startup nil >> > "What Emacs visits when it starts up. >> > A non-nil value is a string naming a directory, file, or buffer >> to visit. >> > If nil, then the splash screen is displayed." >> > :type '(choice >> > (directory :tag "Directory" :value "~/") >> > (file :tag "File" :value "~/new.txt") >> > (string :tag "Buffer" :value "*scratch*") >> > (const :tag "Splash Screen" nil)) >> > :group 'startup-display) >> > >> > The value is a string or nil. If you choose `Buffer', then you >> > can enter any string (without completion). If the string names a >> > buffer that exists at startup, such as *scratch* or *Messages*, >> > then that buffer is visited (in the proper mode). If the string >> > names a nonexistent buffer, then that buffer is created and >> > visited. >> >> You mean: then that _file_ is visited. It does not make sense to >> visit a buffer. > > Oh, if you insist. I think we could use "visit" loosely here, to get the > point across, but if you want to be pedantic about it, then we shouldn't say > "visit" the splash screen either. So change it to speak of "visiting" a file > or directory, "displaying and selecting" a buffer, and "displaying" the > splash screen. Or whatever terminology is PC. > > Call the option "what-to-do-at-startup" if you like ("And tomorrow morning, > we shall have what to do after firing. But today, today we have naming of > parts."). > >> What does "exist at startup" mean? At the time the splash screen >> might get displayed, .emacs is already processed, and any number of >> buffers might be loaded already (including a whole desktop). > > And? > > If the string value of the option names a file or directory, then > visit it. You mean, if the name is "*scratch*" and in the current directory at the time the desktop finished loading, there exists a file named "*scratch*", this should be visited? And if the current directory at the time of the startup happens to be "/dak@fencepost.gnu.org:/home/g/gnudist" because there was the last file loaded, then it should go through a remote connection and check for the existence of "*scratch*" there? > If not, and if the value names one of those numerous buffers "loaded > already" (do we "load" buffers, BTW?), No. Files are visited by loading them into buffers. > then display and select it. If not, and the value is a string, > create, display, and select a buffer with that name. > >> Those numbers in general _don't_ have a buffer name corresponding to an >> actual complete file name (there certainly won't be a buffer named ~/ >> even if ~/ is already visited at the time the splash screen might get >> displayed). > > And? > > If the string value is "~/", then visit the home directory. You have provided no coherent logic that would have this effect without a lot of drawbacks. > If the string names an existing buffer, then display and select it; > if not, create, display, and select a buffer with that name. Why > would such a buffer need to "have a buffer name corresponding to an > actual complete file name"? Because visiting a random file depending on just where we are at startup is not useful behavior. > I still don't get the point or the difficulty here. On that point I agree. -- David Kastrup