Q on read-file-name and completion-ignored-extensions

Q on read-file-name and completion-ignored-extensions

[Drew Adams]

Function `read-file-name' does not seem to respect
`completion-ignored-extensions'. This is true in Emacs 22 and as far back as
Emacs 20. Some questions:

1. Is this on purpose or an old bug?

2. If on purpose, then shouldn't the doc string of
`completion-ignored-extensions' be changed slightly? It says:

 This variable does not affect lists of possible completions,
 but does affect the commands that actually do completions.

(BTW, "do completion" or "complete input" would be better than "do
completions", here.)

The case of `read-file-name' itself is neither - it does not produce a list
of completions and it is not a command that completes input.

But when you hit TAB at the prompt from `read-file-name', shouldn't
`minibuffer-complete' respect that variable, according to its doc string?
(TAB is bound to `minibuffer-complete', a "command that does completion".)

If the current behavior is by design, then perhaps the doc string should say
something about this case. I'm not sure what it should say, because I don't
know if `read-file-name' is the only exception to letting "commands that
actually do completion" respect the variable.

Re: Q on read-file-name and completion-ignored-extensions

[Stefan Monnier]

> Function `read-file-name' does not seem to respect
> `completion-ignored-extensions'.

Works for me and worked in Emacs-20 and Emacs-21 as well.
Please give a recipe.


        Stefan

RE: Q on read-file-name and completion-ignored-extensions

[Drew Adams]

    > Function `read-file-name' does not seem to respect
    > `completion-ignored-extensions'.

    Works for me and worked in Emacs-20 and Emacs-21 as well.
    Please give a recipe.

emacs -q

(setq completion-ignored-extensions (cons ".el"
completion-ignored-extensions))

cd to a directory with .el files

M-: (read-file-name "foo: ")

Type the beginning of the name of one of the .el files - e.g. app, then TAB.

I see all files starting with "app" in *Completions*, including .el files.
If there is only one matching file, then its name is inserted in the
minibuffer.

In Emacs 20.7 and also in GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
 of 2005-06-26 on NONIQPC
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc
(3.3) --cflags -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include -I../.
./tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include -I../../zlib-1.2.2/incl
ude'

Re: Q on read-file-name and completion-ignored-extensions

[Kevin Rodgers]

Drew Adams wrote:
>     > Function `read-file-name' does not seem to respect
>     > `completion-ignored-extensions'.
> 
>     Works for me and worked in Emacs-20 and Emacs-21 as well.
>     Please give a recipe.
> 
> emacs -q
> 
> (setq completion-ignored-extensions (cons ".el"
> completion-ignored-extensions))
> 
> cd to a directory with .el files
> 
> M-: (read-file-name "foo: ")
> 
> Type the beginning of the name of one of the .el files - e.g. app, then TAB.
> 
> I see all files starting with "app" in *Completions*, including .el files.
> If there is only one matching file, then its name is inserted in the
> minibuffer.
> 
> In Emacs 20.7 and also in GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
>  of 2005-06-26 on NONIQPC
> X server distributor `Microsoft Corp.', version 5.1.2600
> configured using `configure --with-gcc
> (3.3) --cflags -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include -I../.
> ./tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include -I../../zlib-1.2.2/incl
> ude'

Not for me, in Emacs 21.4 on Solaris 9.  Try it with
`emacs -q --no-site-file`
just to make sure it's not a problem with your local configuration.

-- 
Kevin Rodgers

RE: Q on read-file-name and completion-ignored-extensions

[Drew Adams]

    > emacs -q
    > (setq completion-ignored-extensions (cons ".el"
    > completion-ignored-extensions))
    >
    > cd to a directory with .el files
    > M-: (read-file-name "foo: ")
    >
    > Type the beginning of the name of one of the .el files - e.g.
    > app, then TAB.
    >
    > I see all files starting with "app" in *Completions*,
    > including .el files.
    > If there is only one matching file, then its name is inserted in the
    > minibuffer.

    Not for me, in Emacs 21.4 on Solaris 9.  Try it with
    `emacs -q --no-site-file`
    just to make sure it's not a problem with your local configuration.

The plot thickens...  Stefan confirms the behavior I see and he says that it
is by design. Keven does not see the same behavior.

I did use emacs -q --no-site-file, BTW. I suspect now that the difference
might be the platform (I'm on Windows). So, which behavior is by design?

Re: Q on read-file-name and completion-ignored-extensions

[Stefan Monnier]

> Type the beginning of the name of one of the .el files - e.g. app, then TAB.

> I see all files starting with "app" in *Completions*, including .el files.

Yes, that's the intended behavior.  The docstring says:

   This variable does not affect lists of possible completions,
   but does affect the commands that actually do completions.


-- Stefan

RE: Q on read-file-name and completion-ignored-extensions

[Drew Adams]

    > Type the beginning of the name of one of the .el files - e.g.
    > app, then TAB. I see all files starting with "app" in
    > *Completions*, including .el files.

    Yes, that's the intended behavior.

Thanks for the confirmation.

    The docstring says:

       This variable does not affect lists of possible completions,
       but does affect the commands that actually do completions.

Here, you're parroting what I said in my first post, where I quoted the same
doc string. That doc string contradicts the `read-file-name' behavior, at
least by my reading of it. You say "it works", but by my reading it doesn't
work, as I pointed out: `minibuffer-complete' is a "command that actually
does completion", but it does not respect this variable when you use it in
the context of `read-file-name'. Apparently, sometimes such commands are
affected by the variable and other times they are not.

Based on your confirmation, I repeat what I said initially:

    If the current behavior is by design, then perhaps the doc
    string should say something about this case. I'm not sure
    what it should say, because I don't
    know if `read-file-name' is the only exception to letting
    "commands that actually do completion" respect the variable.

By "commands that actually do completion", I assume is meant commands such
as `minibuffer-complete' (TAB), `minibuffer-complete-and-exit' (RET), and
`minibuffer-complete-word' (SPC). If that's not correct, then please explain
what is meant (that should also be done in the doc string, in that case).

`read-file-name' is neither a command that does completion nor does it
provide a list of possible completions, so the current doc string does not
address its case at all, directly.

However, you can use commands that complete input while inputting a file
name to `read-file-name'. In this case, those commands do _not_ act as the
doc string says they should - they do not respect the variable (be
"affected" by its value). IOW, `read-file-name' is an exception to the
behavior expressed by the doc string (an exception by design, according to
your confirmation).

If `read-file-name' is the only such exception, then it should be called out
in the doc string as a special case:

       Commands that complete minibuffer input respect this variable,
       except for input to `read-file-name'. This variable also does
       not affect lists of possible completions.

If `read-file-name' is not the only such exception, then something else
should be said, which characterizes the cases where completion commands do
and do not respect this variable.

The phrase "lists of possible completions" could profitably be clarified as
well. I suppose it means functions like `all-completions', but I'm not sure,
as it's not very clear.

Re: Q on read-file-name and completion-ignored-extensions

[Stefan Monnier]

>        This variable does not affect lists of possible completions,
>        but does affect the commands that actually do completions.

> Here, you're parroting what I said in my first post, where I quoted the same
> doc string. That doc string contradicts the `read-file-name' behavior, at
> least by my reading of it. You say "it works", but by my reading it doesn't
> work, as I pointed out: `minibuffer-complete' is a "command that actually
> does completion", but it does not respect this variable when you use it in
> the context of `read-file-name'.

minibuffer-complete doesn't only do completion.  It also lists
possible completions.  When it does completion it does take
completion-ignored-extensions into account.  When it lists completions
it doesn't.  Just like the docstring says.


        Stefan

RE: Q on read-file-name and completion-ignored-extensions

[Drew Adams]

    >        This variable does not affect lists of possible completions,
    >        but does affect the commands that actually do completions.

    > That doc string contradicts the `read-file-name' behavior, at
    > least by my reading of it. You say "it works", but by my
    > reading it doesn't work, as I pointed out: `minibuffer-complete'
    > is a "command that actually does completion", but it does not
    > respect this variable when you use it in
    > the context of `read-file-name'.

    minibuffer-complete doesn't only do completion.  It also lists
    possible completions.  When it does completion it does take
    completion-ignored-extensions into account.  When it lists completions
    it doesn't.  Just like the docstring says.

1. Sorry, but I don't see what you're describing, as I said. Leaving aside
listing of possible completions in *Completions* (but see #3),
`minibuffer-complete' (TAB) merrily __completes__ a filename that has a
supposedly ignored extension - it does _not_ take the variable into account.
See the recipe I provided. I don't know how to be clearer: "ignored"
filenames are being completed, not simply displayed in *Completions*.

2. Kevin Rodgers seemed to be saying that he does not see on Solaris the
same behavior I see on Windows. That in itself should indicate a problem
somewhere.

3. If display in *Completions* is what is meant in the doc string by "lists
of possible completions", then I wonder why we have such a design. Why would
we display "possible completions" for the user that are in reality
IMpossible completions for him/her? I interpreted "does not affect lists of
possible completions" to mean that functions such as `all-completions' that
return lists of possible completions are not affected by the variable - that
behavior would make sense to me. Showing completion candidates in
*Completions* that cannot be obtained by completion makes no sense to me.

4. If you are right about the meaning of "does not affect lists of possible
completions", then this phrase should be clarified. If it means only
*Completions* display, then just say that: "does not affect possible
completions listed in buffer *Completions*". If it means also things like
`all-completions', then that should be made clear. The phrase is, to say the
least, open to (mis)interpretation.

Re: Q on read-file-name and completion-ignored-extensions

[Luc Teirlinck]

It is always dangerous to jump into a long thread you have not read,
but, just in case it might be useful, here is part of what
`(elisp)File Name Completion' says about completion-ignored-extensions:

 -- User Option: completion-ignored-extensions
     `file-name-completion' usually ignores file names that end in any
     string in this list.  It does not ignore them when all the possible
     completions end in one of these suffixes.  This variable has no
     effect on `file-name-all-completions'.

Sincerely,

Luc.

RE: Q on read-file-name and completion-ignored-extensions

[Drew Adams]

    It is always dangerous to jump into a long thread you have not read,
    but, just in case it might be useful, here is part of what
    `(elisp)File Name Completion' says about completion-ignored-extensions:

     -- User Option: completion-ignored-extensions
         `file-name-completion' usually ignores file names that end in any
         string in this list.  It does not ignore them when all the possible
         completions end in one of these suffixes.  This variable has no
         effect on `file-name-all-completions'.

Thanks.

That seems to corroborate my feeling that either there is a bug (on Windows)
or the doc string for `completion-ignored-extensions' is incorrect.

In my test, there were other files present, with other extensions, so the
next-to-the-last sentence above does not apply. But it's good to know, and,
I'd suggest, should be included in the doc string as well!

The last sentence above also seems to corroborate my understanding that the
"does not affect lists of possible completions" text in the doc string is
about functions like `file-name-all-completions' (I mentioned
`all-completions'), rather than being about the list in buffer
*Completions*.

I say only "seems to", because there is nothing here that flatly contradicts
Stefan's interpretation.

Re: Q on read-file-name and completion-ignored-extensions

[Luc Teirlinck]

Drew Adams wrote:

   That seems to corroborate my feeling that either there is a bug (on Windows)
   or the doc string for `completion-ignored-extensions' is incorrect.

What about the alternative docstring in the patch below?  That one
should describe the actual behavior or there _is_ a bug (on Windows).
I can install if desired.

To explain what _should_ happen and _does_ happen on GNU/Linux: I have
four files starting with cin: cinv.tex, cinv.tex~, cinv.aux and cinv.dvi.
All but one end in a string in completion-ignored-extensions.  If I do
`C-x C-f cin TAB', it completes to cinv.tex, ignoring the three other
ones.  But if I do `C-x C-f cin ?', I get a list of all four.  This
feature is meant to allow you to complete to what you _probably_ want
with less typing.  It is _not_ meant to prevent you from visiting
files that end in one of these suffixes.

===File ~/dired.c-diff======================================
*** dired.c	01 Oct 2005 08:42:10 -0500	1.119
--- dired.c	19 Jan 2006 18:37:07 -0600	
***************
*** 1036,1046 ****
  #endif /* VMS */
  
    DEFVAR_LISP ("completion-ignored-extensions", &Vcompletion_ignored_extensions,
! 	       doc: /* *Completion ignores filenames ending in any string in this list.
! Directories are ignored if they match any string in this list which
! ends in a slash.
! This variable does not affect lists of possible completions,
! but does affect the commands that actually do completions.  */);
    Vcompletion_ignored_extensions = Qnil;
  }
  
--- 1036,1046 ----
  #endif /* VMS */
  
    DEFVAR_LISP ("completion-ignored-extensions", &Vcompletion_ignored_extensions,
! 	       doc: /* Completion ignores file names ending in any string in this list.
! It does not ignore them if all possible completions end in one of
! these strings or when displaying a list of completions.
! It ignores directory names if they match any string in this list which
! ends in a slash.  */);
    Vcompletion_ignored_extensions = Qnil;
  }
  
============================================================

RE: Q on read-file-name and completion-ignored-extensions

[Drew Adams]

    What about the alternative docstring in the patch below?  That one
    should describe the actual behavior or there _is_ a bug (on Windows).
    I can install if desired.

    To explain what _should_ happen and _does_ happen on GNU/Linux: I have
    four files starting with cin: cinv.tex, cinv.tex~, cinv.aux and
    cinv.dvi.

    All but one end in a string in completion-ignored-extensions.  If I do
    `C-x C-f cin TAB', it completes to cinv.tex, ignoring the three other
    ones.  But if I do `C-x C-f cin ?', I get a list of all four.  This
    feature is meant to allow you to complete to what you _probably_ want
    with less typing.  It is _not_ meant to prevent you from visiting
    files that end in one of these suffixes.

    ! 	       Completion ignores file names ending in any
    string in this list.
    ! It does not ignore them if all possible completions end in one of
    ! these strings or when displaying a list of completions.
    ! It ignores directory names if they match any string in this list which
    ! ends in a slash.

Thanks very much. This clears up a lot.

I guess the reference to `file-name-all-completions' was mistaken, and
"affects lists of possible completions" in the original doc string meant
only (?) what you write above: _displaying_ a list of completions (in buffer
*Completions*).

What's more, the part about "if all possible completions end in one of these
strings" is new to me, and it clears up my misunderstanding wrt why it was
completing filenames that have the ignored extensions. There is apparently
no bug on Windows - I was just missing this bit of info (if all possible
completions have ignored extensions, then no ignoring is done).

We should perhaps clarify this case: C-x C-f cinv. TAB

This does _not_ display the list (of all four files), even though TAB would
normally display the list of possible completions in that case (since the
common part is already in the minibuffer). Instead, it completes to
cinv.tex. This case should somehow be documented - I don't think it's
implied by the rules expressed in your doc string.

Is it perhaps true that the "displaying a list of completions" that shows
ignored completions (even when there are non-ignored candidates) applies
only to display by `?' and not to display by TAB? If so, that would make the
explanation even simpler: just say that `?' is unaffected by this variable.
Whatever the real rule is, we should make it clear.

IMO, it wouldn't hurt to add short examples of the various cases to either
the doc string or the manual: 1) if all possible completions have ignored
extensions, they are not ignored, 2) otherwise, completions with ignored
extensions are still displayed in *Completions*, so you can compare them
with filenames that you can complete to, ...

Thanks, Luc. I don't know if what you wrote was obvious from the beginning
to others, but it was certainly not obvious to me.

Re: Q on read-file-name and completion-ignored-extensions

[Luc Teirlinck]

Drew Adams wrote:

   I guess the reference to `file-name-all-completions' was mistaken,

No, that reference is correct.  `file-name-all-completions' is the
function used internally by the commands that display completion lists
and it is _really_ unaffected by `completion-ignored-extensions'
(otherwise, there would be a bug).  Note that
`file-name-all-completions' is described in exactly the same Info node
as `completion-ignored-extensions'.

Sincerely,

Luc.

Re: Q on read-file-name and completion-ignored-extensions

[Luc Teirlinck]

Drew Adams wrote:

   This does _not_ display the list (of all four files), even though TAB would
   normally display the list of possible completions in that case (since the
   common part is already in the minibuffer).

The minibuffer commands do not ignore completion-ignored-extensions in
deciding _whether_ to display lists of completions (as opposed to
doing completion), it only ignores it _when_ it displays them.

Sincerely,

Luc.

Re: Q on read-file-name and completion-ignored-extensions

[Luc Teirlinck]

Drew Adams wrote:

   Is it perhaps true that the "displaying a list of completions" that shows
   ignored completions (even when there are non-ignored candidates) applies
   only to display by `?' and not to display by TAB?

No, it affects TAB too, if TAB can not do completion, even ignoring
all extensions in completion-ignored-extensions.  As I explained, TAB
takes completion-ignored-extensions into account in deciding whether
it can do completion (as opposed to having to display a list of
completions), but _after_ it decides that it has to display a list, it
ignores the variable.

Sincerely,

Luc.

RE: Q on read-file-name and completion-ignored-extensions

[Drew Adams]

       I guess the reference to `file-name-all-completions' was mistaken,

    No, that reference is correct.  `file-name-all-completions' is the
    function used internally by the commands that display completion lists
    and it is _really_ unaffected by `completion-ignored-extensions'
    (otherwise, there would be a bug).  Note that
    `file-name-all-completions' is described in exactly the same Info node
    as `completion-ignored-extensions'.

       This does _not_ display the list (of all four files), even
       though TAB would normally display the list of possible
       completions in that case (since the
       common part is already in the minibuffer).

    The minibuffer commands do not ignore completion-ignored-extensions in
    deciding _whether_ to display lists of completions (as opposed to
    doing completion), it only ignores it _when_ it displays them.

       Is it perhaps true that the "displaying a list of
       completions" that shows ignored completions (even
       when there are non-ignored candidates) applies
       only to display by `?' and not to display by TAB?

    No, it affects TAB too, if TAB can not do completion, even ignoring
    all extensions in completion-ignored-extensions.  As I explained, TAB
    takes completion-ignored-extensions into account in deciding whether
    it can do completion (as opposed to having to display a list of
    completions), but _after_ it decides that it has to display a list, it
    ignores the variable.

Great. So, since none of that info is in the doc string or the manual, let's
add it:

 Completion ignores file names ending in any string in this list.
 It ignores directory names if they match any string in the list
 that ends in a slash (/).
 However:
  - If all possible completions have ignored extensions, then those
    completions are not ignored.
    Example: If .ico is an ignored extension, and the only possible
    completions are fun.ico and fudge.ico, then those file names
    are available for completion: `C-x C-f fud TAB' completes to
    fudge.ico.
  - Displayed and returned lists of possible completions include
    file names, even if they have ignored extensions. This includes
    the completions displayed in buffer *Completions*, as well as
    the lists of completions returned by functions such as
    `file-name-all-completions'. File names with ignored extensions
    are ignored in deciding whether buffer *Completions* is to be
    displayed, but if it is displayed then it includes any matching
    file names with ignored extensions.
    Example: files fun.ico and fun.el, `C-x C-f fun. TAB' completes
    to fun.el, because fun.ico is ignored for completion.
    `C-x C-f fun ?' displays fun.el and fun.ico in *Completions*,
    because ignored file names are included whenever *Completions*
    is displayed.

Reword as needed. The various points you've made should be addressed in a
clear way, preferably with examples. The examples might be reserved for the
Elisp manual, leaving the doc string simpler (if less clear):

 Completion ignores file names ending in any string in this list.
 It ignores directory names if they match any string in the list
 that ends in a slash (/).
 However:
  - If all possible completions have ignored extensions, then those
    completions are not ignored.
  - Displayed and returned lists of possible completions include
    file names, even if they have ignored extensions. This includes
    the completions displayed in buffer *Completions*, as well as
    the lists of completions returned by functions such as
    `file-name-all-completions'. File names with ignored extensions
    are ignored in deciding whether buffer *Completions* is to be
    displayed, but if it is displayed then it includes any matching
    file names with ignored extensions.

Re: Q on read-file-name and completion-ignored-extensions

[Richard M. Stallman]

Your change seems good.  Please install it.

Re: Q on read-file-name and completion-ignored-extensions

[Lennart Borgman]

Stefan Monnier wrote:
> minibuffer-complete doesn't only do completion.  It also lists
> possible completions.  When it does completion it does take
> completion-ignored-extensions into account.  When it lists completions
> it doesn't.  Just like the docstring says.
>   

Maybe I missed something here, but my Emacs from 2006-01-06 does not say 
so. And it sounds very confusing. Is there a good reason for this?