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: Start value in minibuffer [Was: opening /tmp//foo doesn't work.] Date: Sun, 13 Nov 2005 14:57:38 -0800 Message-ID: References: <4377C214.3090405@student.lu.se> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1131922719 18758 80.91.229.2 (13 Nov 2005 22:58:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 13 Nov 2005 22:58:39 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 13 23:58:36 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EbQnS-0004VB-IK for ged-emacs-devel@m.gmane.org; Sun, 13 Nov 2005 23:58:02 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EbQnS-0005Jd-2M for ged-emacs-devel@m.gmane.org; Sun, 13 Nov 2005 17:58:02 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EbQnJ-0005JY-4j for emacs-devel@gnu.org; Sun, 13 Nov 2005 17:57:53 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EbQnH-0005JM-Jj for emacs-devel@gnu.org; Sun, 13 Nov 2005 17:57:52 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EbQnH-0005JJ-Et for emacs-devel@gnu.org; Sun, 13 Nov 2005 17:57:51 -0500 Original-Received: from [148.87.122.30] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EbQnH-0004Po-D8 for emacs-devel@gnu.org; Sun, 13 Nov 2005 17:57:51 -0500 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id jADMvmKZ021354 for ; Sun, 13 Nov 2005 15:57:48 -0700 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jADMvmeV002549 for ; Sun, 13 Nov 2005 15:57:48 -0700 Original-Received: from dradamslap (dhcp-amer-whq-csvpn-gw3-141-144-81-128.vpn.oracle.com [141.144.81.128]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jADMvlgM002538 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 13 Nov 2005 15:57:48 -0700 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <4377C214.3090405@student.lu.se> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE 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:45909 Archived-At: I do not like that decision either. GUI applications at least on w32 use to select a field when you enter it. Maybe there is a chance to rethink this decision after the release. Could such things be put in the TODO list? It's not clear which decision you are referring to. I was speaking of the decision to deprecate INITIAL-VALUE insertion (in favor of using only DEF). It sounds like you're arguing for preselection of an initial value. IOW, there are two questions: 1. Can INIT-VALUE be reinstated as a legitimate (i.e. not disrecommended) option? 2. Can preselection of an initial value be provided (e.g. as an option)? In my post, I was considering #1 to be a precondition to #2, because of the mention of "start value" by the OP. However, preselection could, alternatively, be applied to the default value pulled in by M-n. That might be something people would agree to. I've asked for #1 before, and I don't expect any turnaround on that question. The most we can hope for in that regard, I think, is a user option to control the behavior, such as the one I mentioned.