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: Wed, 1 Aug 2007 07:32:54 -0700 Message-ID: References: <46B0458B.8080608@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1185978896 27035 80.91.229.12 (1 Aug 2007 14:34:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 1 Aug 2007 14:34:56 +0000 (UTC) To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 01 16:34:49 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 1IGFHi-0001m0-Td for ged-emacs-devel@m.gmane.org; Wed, 01 Aug 2007 16:34:47 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IGFHi-0001uK-8X for ged-emacs-devel@m.gmane.org; Wed, 01 Aug 2007 10:34:46 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IGFHB-0001SJ-2Q for emacs-devel@gnu.org; Wed, 01 Aug 2007 10:34:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IGFH8-0001Pr-DV for emacs-devel@gnu.org; Wed, 01 Aug 2007 10:34:12 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IGFH8-0001Po-B8 for emacs-devel@gnu.org; Wed, 01 Aug 2007 10:34:10 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IGFH7-0003ZD-Tv for emacs-devel@gnu.org; Wed, 01 Aug 2007 10:34:10 -0400 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l71EY64e012420 for ; Wed, 1 Aug 2007 08:34:06 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l71CsP3G022201 for ; Wed, 1 Aug 2007 08:34:06 -0600 Original-Received: from dhcp-amer-whq-csvpn-gw3-141-144-84-209.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 3087284801185978782; Wed, 01 Aug 2007 07:33:02 -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: <46B0458B.8080608@gnu.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 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:75908 Archived-At: > > What am I missing? Why is this thread so Byzantine? > > You are making a distinction in the UI between buffer and file. But the > distinction is thrown away immediately because buffer, file and > directory all map to strings. If Customize can determine whether a string is a proper file or directory name (types `file' and `directory'), then Emacs can tell whether a string is a file or directory name. If you're worried about interpreting relative file names in the wrong default directory, as David is, then require an absolute file name as the value. [Or warn users that if they use a relative name then the behavior depends on the current directory.] So, if the string is an absolute file or directory name, then visit the file or directory; if not, interpret the string as a buffer name. If there is a problem (e.g. error) visiting that file or directory, then punt in some reasonable way - e.g. show the splash screen and an error message. We could also require that the file to visit exist, but I don't think that is even necessary. There might be other details to work out, but, honestly, this just doesn't seem that complex. We ought to be able to get something reasonable up and running before 2010. Of course, then there's the name of the option to worry about...