23.0.60; doc string of minibuffer-completing-file-name

23.0.60; doc string of minibuffer-completing-file-name

[Drew Adams]

Doc string:
 
"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).
 
In Emacs 20 and 21, the "and non-`lambda'" part was not there, and
that still seems correct. When would a user or Lisp access show the
value as `lambda'? I get the impression that a value of `lambda' is
only temporary, within the C code. Shouldn't Lisp code be able to test
this simply for nil/non-nil, to see if file-name completion is
happening?

Also, should this variable be documented in the Elisp manual, along with
minibuffer-completion-(table|predicate|confirm)?
 

In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-04-04 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include
-fno-crossjumping'
 

Re: 23.0.60; doc string of minibuffer-completing-file-name

[Stefan Monnier]

> "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.


        Stefan


PS: It turns out that sending to both emacs-pretest-bug and
submit@... is a bad idea because replies then also go to both addresses,
and are thus considered as new bug-reports, etc...

RE: 23.0.60; doc string of minibuffer-completing-file-name

[Drew Adams]

> > 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.

Thanks for fixing it. What about this other part?

> > should this variable be documented in the Elisp manual,
> > along with minibuffer-completion-(table|predicate|confirm)?


> PS: It turns out that sending to both emacs-pretest-bug and
> submit@... is a bad idea because replies then also go to both 
> addresses, and are thus considered as new bug-reports, etc...

Then I will send only to whatever M-x report-emacs-bug chooses, as before.

Re: 23.0.60; doc string of minibuffer-completing-file-name

[Stefan Monnier]

>> > 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.

> Thanks for fixing it. What about this other part?

I don't think it's necessary.


        Stefan

Re: 23.0.60; doc string of minibuffer-completing-file-name

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 19 Apr 2008 17:46:04 -0400
> Cc: emacs-pretest-bug@gnu.org
> 
> > "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?

RE: 23.0.60; doc string of minibuffer-completing-file-name

[Drew Adams]

> > > "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.

Re: 23.0.60; doc string of minibuffer-completing-file-name

[Stefan Monnier]

> 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, the value `lambda' is used, and quite visibly.  But "external code"
only need to know that it's non-nil.


        Stefan