unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: Q on read-file-name and completion-ignored-extensions
Date: Thu, 19 Jan 2006 17:50:05 -0800	[thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICMEKHDBAA.drew.adams@oracle.com> (raw)
In-Reply-To: <200601200047.k0K0lG025176@raven.dms.auburn.edu>

    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.

  reply	other threads:[~2006-01-20  1:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-18 17:44 Q on read-file-name and completion-ignored-extensions Drew Adams
2006-01-18 20:58 ` Stefan Monnier
2006-01-18 21:46   ` Drew Adams
2006-01-19  0:42     ` Kevin Rodgers
2006-01-19  1:52       ` Drew Adams
2006-01-19  1:13     ` Stefan Monnier
2006-01-19  1:45       ` Drew Adams
2006-01-19 18:59         ` Stefan Monnier
2006-01-19 19:29           ` Drew Adams
2006-01-19 21:32             ` Luc Teirlinck
2006-01-19 22:10               ` Drew Adams
2006-01-20  0:47                 ` Luc Teirlinck
2006-01-20  1:50                   ` Drew Adams [this message]
2006-01-20  2:11                     ` Luc Teirlinck
2006-01-20  2:20                     ` Luc Teirlinck
2006-01-20  2:33                     ` Luc Teirlinck
2006-01-20 16:34                       ` Drew Adams
2006-01-22  3:59                   ` Richard M. Stallman
2006-01-19 23:00           ` Lennart Borgman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DNEMKBNJBGPAOPIJOOICMEKHDBAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).