From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: RE: 23.0.60; doc string of minibuffer-completing-file-name Date: Sun, 20 Apr 2008 01:38:16 -0700 Message-ID: <000801c8a2c1$e1b7dc10$0200a8c0@us.oracle.com> References: <000a01c8a22b$5bdaf9b0$0200a8c0@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1208680715 15679 80.91.229.12 (20 Apr 2008 08:38:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Apr 2008 08:38:35 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org To: "'Eli Zaretskii'" , "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 20 10:39:10 2008 connect(): Connection refused 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 1JnV4j-0007Pj-3I for ged-emacs-devel@m.gmane.org; Sun, 20 Apr 2008 10:39:05 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JnV43-0000nH-Oi for ged-emacs-devel@m.gmane.org; Sun, 20 Apr 2008 04:38:23 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JnV3v-0000l5-J5 for emacs-devel@gnu.org; Sun, 20 Apr 2008 04:38:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JnV3u-0000k8-BJ for emacs-devel@gnu.org; Sun, 20 Apr 2008 04:38:14 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JnV3u-0000ju-5h for emacs-devel@gnu.org; Sun, 20 Apr 2008 04:38:14 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JnV3t-00072X-VA for emacs-devel@gnu.org; Sun, 20 Apr 2008 04:38:14 -0400 Original-Received: from mail.gnu.org ([199.232.76.166] helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1JnV3t-00033a-9C for emacs-pretest-bug@gnu.org; Sun, 20 Apr 2008 04:38:13 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1JnV3o-00071P-O8 for emacs-pretest-bug@gnu.org; Sun, 20 Apr 2008 04:38:13 -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 1JnV3o-000715-Br; Sun, 20 Apr 2008 04:38:08 -0400 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m3K8c59B011927; Sun, 20 Apr 2008 02:38:05 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id m3K8c2B8003956; Sun, 20 Apr 2008 02:38:02 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3654670031208680676; Sun, 20 Apr 2008 01:37:56 -0700 Original-Received: from dradamslap1 (/141.144.120.206) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 20 Apr 2008 01:37:56 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AciiuNkYYxumMt+nQg2s62Zx/7g9nwAAkCLg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:95508 gmane.emacs.pretest.bugs:22077 Archived-At: > > > "Non-nil and non-`lambda' means completing file names." > > > > > Is that correct? It doesn't seem so, by looking at the C > > > code (but I'm no expert on that). > > > > Indeed, thank you. Fixed. > > Are you sure? I see this fragment in minibuf.c: > > /* If this minibuffer is reading a file name, that doesn't mean > recursive ones are. But we cannot set it to nil, because > completion code still need to know the minibuffer is completing a > file name. So use `lambda' as intermediate value meaning > "t" in this minibuffer, but "nil" in next minibuffer. */ > if (!NILP (Vminibuffer_completing_file_name)) > Vminibuffer_completing_file_name = Qlambda; > > So it sounds like `lambda' is used in recursive minibuffers. Am I > missing something? Yes, I saw that. No, I'm not sure. My impression is that the value of `lambda' is temporary, until the recursive minibuffer gets its correct value of nil - that is, until the recursive call to read_minibuf. At this point in the code it cannot yet be set to nil (for the next invocation), because the current invocation still needs to treat it as non-nil. AFAICT, it is the completion code that does that: tests whether it is currently non-nil. Note that right at the beginning of read_minibuf, a `lambda' value set by the parent invocation is converted to a nil value for this (recursive) invocation: /* If Vminibuffer_completing_file_name is `lambda' on entry, it was t in previous recursive minibuffer, but was not set explicitly to t for this invocation, so set it to nil in this minibuffer. Save the old value now, before we change it. */ specbind (intern ("minibuffer-completing-file-name"), Vminibuffer_completing_file_name); if (EQ (Vminibuffer_completing_file_name, Qlambda)) Vminibuffer_completing_file_name = Qnil; The phrase "in a previous recursive minibuffer" is I think poor here. It was in a previous minibuffer, but not necessarily a recursive one - it is _this_ invocation that is recursive (if the value is `lambda'). Otherwise, the comment is good - it is this comment that explains what the value of `lambda' means. The following read_minibuf call from completing-read treats nil and `lambda' the same way when determining the map to use: val = read_minibuf (NILP (require_match) ? (NILP (Vminibuffer_completing_file_name) || EQ (Vminibuffer_completing_file_name, Qlambda) ? Vminibuffer_local_completion_map : Vminibuffer_local_filename_completion_map) : (NILP (Vminibuffer_completing_file_name) || EQ (Vminibuffer_completing_file_name, Qlambda) ? Vminibuffer_local_must_match_map : Vminibuffer_local_must_match_filename_map), init, prompt, make_number (pos), 0, histvar, histpos, def, 0, !NILP (inherit_input_method)); So it is _not_ for this use that `lambda' was kept non-nil. do_completion is one place where `lambda' is used temporarily to signify non-nil during this invocation (it will become nil in a future recursive call). This happens right after try_completion is called: if (! NILP (Vminibuffer_completing_file_name) && SREF (completion, SBYTES (completion) - 1) == '/' ... And here is another such place, in minibuffer-complete-word (again, after try_completion) - there are two such places in this function: /* If reading a file name, expand any $ENVVAR refs in the buffer and in TEM. */ if (! NILP (Vminibuffer_completing_file_name)) { Lisp_Object substituted; substituted = Fsubstitute_in_file_name (tem); ... So AFAICT, the idea is just to save the current non-nil value for use during the completion code of this invocation, while nevertheless preparing a nil value to be used in the recursive call. I would say that this motivation could be made clearer in the code, both in comments and perhaps by using a more parlant non-nil value than `lambda'. `lambda' signifies on entry that this is a recursive call and the value should be nil, that's all. Again, no, I'm not sure. (1) I'm no C expert. (2) I didn't study the code in detail.