bug#34070: 27.0.50; icomplete-mode candidate cycling broken for C-x C-f

[Drew Adams]

> while still honouring the original intention of Drew's change:
> 65797b1d7 "Make icomplete respect `completion-ignored-extensions'"
> the new patch does two things:
>    1. Still fixes the candidate cycling (i.e. this bug)
>    2. Leaves the current directory as a candidate, i.e. "./" is *not*
>       filtered from the prospects list (but "../" is).
> 
> Number 2 can be seen as "new" behaviour, but then Drew's patch also
> silently introduced new behaviour by filtering out "./" and "../",
> which are *not* in completion-ignored-extensions.  Reading bug
> #12939... this seems to have gone unnoticed.
> 
> If someone thinks this is a problem we can make this configurable
> (though I think the default should be what I suggest, since it
> makes C-x C-f'ing directories much easier).

I can't speak to whether `.' or `..' should (always?
sometimes?) be filtered out for Icomplete completion of
file-name candidates.

I think you're right that the intention of my patch was
just to respect `completion-ignored-extensions'.  That was
the "new" behavior to be introduced, and not silently.

But why is it that `completion-pcm--filename-try-filter'
adds `.' and `..' to its filter, so they too are excluded?
I guess it's because they are not candidates returned by
`try'?

Assuming there's a good reason why `c-p--f-t-f' does that,
and if that's not appropriate for Icomplete in all or most
cases, then I guess `c-p--f-t-f' wasn't a perfect match for
Icomplete. ;-)

But maybe someone should take a look at `c-p--f-t-f' more
generally?  If `.' or `..' is appropriate for file-name
completions sometimes (e.g. in Icomplete), then do some of
the current uses of `c-p--f-t-f' also manifest the same
bug that you are adding here?

E.g., is removal of `.' and `..' always appropriate for
`completion-basic-try-completion',
`completion-pcm-try-completion' and
`completion-substring-try-completion'?

(Note too that you are adding to this bug, which was
purportedly about broken cycling. Is this additional
change necessary to fix the cycling problem, or should
it be the subject of a new bug report?)

BTW, see also bug #13322, companion to bug #12939.
It should never have been closed, IMHO.

BTW2, as stated in bug #12939,
`completion-pcm--filename-try-filter' is the wrong name.
It should not use `--'.  It's not "internal" in any way,
or at least it should not be considered so.  Internal to
what?  It's not internal to `completion-pcm' (whatever
that might be/mean now) or to `minibuffer.el'.

It's as general and useful as any other Lisp function -
no reason to try to signal to users that it is (also)
used to build some basic Emacs behavior.  Users can
well make use of such a function.  Misuse of the label
"internal" is akin to Trump trying to "build that wall".