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 09:53:26 -0700 Message-ID: References: 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 1185987297 28367 80.91.229.12 (1 Aug 2007 16:54:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 1 Aug 2007 16:54:57 +0000 (UTC) To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 01 18:54:50 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 1IGHTF-0003GI-C7 for ged-emacs-devel@m.gmane.org; Wed, 01 Aug 2007 18:54:49 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IGHTE-0005tY-UB for ged-emacs-devel@m.gmane.org; Wed, 01 Aug 2007 12:54:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IGHTA-0005tL-D2 for emacs-devel@gnu.org; Wed, 01 Aug 2007 12:54:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IGHT7-0005t4-Ph for emacs-devel@gnu.org; Wed, 01 Aug 2007 12:54:43 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IGHT7-0005t1-Ke for emacs-devel@gnu.org; Wed, 01 Aug 2007 12:54:41 -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 1IGHT7-0006EX-BC for emacs-devel@gnu.org; Wed, 01 Aug 2007 12:54:41 -0400 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l71GsdaH028319 for ; Wed, 1 Aug 2007 10:54:39 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l71AegFq013345 for ; Wed, 1 Aug 2007 10:54:35 -0600 Original-Received: from dhcp-4op11-4op12-west-130-35-178-179.us.oracle.com by acsmt350.oracle.com with ESMTP id 3087532141185987207; Wed, 01 Aug 2007 09:53:27 -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: 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:75917 Archived-At: > > If Customize can determine whether a string is a proper file or > > directory name (types `file' and `directory'), > > It doesn't. The difference is only in the UI, but otherwise matches any > string. I see; I wasn't aware of that. Why is that? Then shouldn't the doc (e.g. Elisp manual) be corrected to explain that strong statements such as "The value must be a directory name" don't mean what they say, that they mean only that you can use completion to insert an existing directory name? They apparently mean nothing about the value itself. If there is really no requirement that "the value _must_ be a directory name", then why say that? Wrt requiring an absolute name for a file or directory: We already do that elsewhere - note the doc string here: (defcustom auto-insert-directory "~/insert/" "*Directory from which auto-inserted files are taken. The value must be an absolute directory name..." :type 'directory :group 'auto-insert) Presumably, it is the code that uses `auto-insert-directory' that ensures that the value is in fact an absolute directory name. The same could be done for `visit-on-startup': check its value at startup time, to see if it is `file-name-absolute-p', and use a buffer if it is not. And document this behavior in the doc string. Going beyond control at startup time, couldn't we use, instead of `file' and `directory' for :type, a suitable `restricted-sexp' expression, to ensure that the saved value is in fact a string that satisfies `file-name-absolute-p'? I'm no expert on custom types, but what about something like this - its seems to work OK: :type '(restricted-sexp :match-alternatives ((lambda (x) (and (stringp x) (file-name-absolute-p x))))) Anyway, this doesn't sound like an unsurmountable problem, however we approach it. We should be able to let a user specify an absolute file or directory name or a buffer name.