From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Reitter Newsgroups: gmane.emacs.devel Subject: Re: C-x C-f, Tab (in)completion and visiting the wrong, new files Date: Mon, 13 Aug 2007 19:46:18 +0100 Message-ID: <9630B95D-8192-471F-9C6C-5859BB65678E@gmail.com> References: <64CC15CF-72D0-4765-8D7F-CE0DFBCF96EE@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1187030796 23562 80.91.229.12 (13 Aug 2007 18:46:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 13 Aug 2007 18:46:36 +0000 (UTC) Cc: Development of Aquamacs Emacs , Drew Adams , emacs- devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 13 20:46:32 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 1IKevu-0005eN-1Q for ged-emacs-devel@m.gmane.org; Mon, 13 Aug 2007 20:46:30 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IKevt-0000pk-C3 for ged-emacs-devel@m.gmane.org; Mon, 13 Aug 2007 14:46:29 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IKevr-0000pU-0Q for emacs-devel@gnu.org; Mon, 13 Aug 2007 14:46:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IKevp-0000oH-2t for emacs-devel@gnu.org; Mon, 13 Aug 2007 14:46:26 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IKevo-0000oE-Rl for emacs-devel@gnu.org; Mon, 13 Aug 2007 14:46:24 -0400 Original-Received: from fk-out-0910.google.com ([209.85.128.187]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IKevo-0004YZ-DG for emacs-devel@gnu.org; Mon, 13 Aug 2007 14:46:24 -0400 Original-Received: by fk-out-0910.google.com with SMTP id 19so1477775fkr for ; Mon, 13 Aug 2007 11:46:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=NgiCQLh5or5Fkv6mn+gdBo4uKfRzS1KRCmC0X4zszbs8uiOTpFEeau2HGBX/peDUq4ClLKItSDnm1nsP1TwyMT39HRHFuYNb3lU6poVIMofNsuIdS287pAKkCnvLFFV+4JdUSy+RB3mXzb16WGVOdiVl2W92Yc6kMWZ2Ate9Q5Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=aaf/RxrdgXiDPzr2xgZdtsvy4PjSDeevic/7RgN83fIW0NGoefccdEy1hcYiCBzrq9rDZLDFvexTjXD1oFslYQZOdDwOFtaP1AIZLw8UlpF1xXIfvw3wWBWh2qZN0ySsuZqiUXm1r1HN2Ywwn/y156+Aj2Wd4f9l0GHa0sguffg= Original-Received: by 10.82.175.17 with SMTP id x17mr7587123bue.1187030782073; Mon, 13 Aug 2007 11:46:22 -0700 (PDT) Original-Received: from ?10.5.5.200? ( [84.9.229.108]) by mx.google.com with ESMTPS id h7sm12831870nfh.2007.08.13.11.46.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Aug 2007 11:46:20 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.752.2) X-Detected-Kernel: Linux 2.6 (newer, 2) 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:76472 Archived-At: On 13 Aug 2007, at 19:15, Stefan Monnier wrote: > find-file-confirm-nonexistent doesn't use a "confirmation dialog", > it just > puts a "[Confirm]" text in the minibuffer and rejects the RET (so > you just > need to hit RET a second time). Is that a variable to set (I don't have it), or how can I try this out? I presume the [Confirm] text appears next to the entered file name and doesn't replace it? That would be good. Drew Adams wrote: > The same considerations apply, probably, but it's not clear that a > given > user would necessarily want the same behavior for all lax > completion. Dunno > if it might be good to have two such options, one for `read-file- > name' and > one for `completing-read'. The reason why I'm pushing for this is that I find it reasonable to have one behavior for as many cases as possible. Special cases are usually confusing. To experiment with this, we could use the two keymaps that exist, e.g. `minibuffer-local-filename-completion-map', where we could rebind RET to something that checks whether the previous command was a completion command. > BTW, I assume (and hope) that this `only-after-completion' behavior > would > apply only for TAB RET, not for TAB followed by some editing > followed by > RET. That is, it is not just "after completion"; it is "immediately > after > completion". Correct.