RE: all-completions DTWT for "" and non-nil HIDE-SPACES

[Drew Adams]

    > The doc string for all-completions says that if the first arg
    > doesn't start with a space then a non-nil 4th arg means ignore
    > candidates that start with a space. "Start with a space" means
    > that the first character is a space.
    > This is undefined (ambiguous) if the string has no first
    > character (doesn't start at all; is empty).

    I don't follow. An empty string clearly does not start with a space.

What does it start with? All of the alligators on the moon are red. True or
false? Every character that the empty string starts with is a space, no? Or
is every such character a non-space? or a balloon?

To me, "start with a space" doesn't mean much for a string that does not
start at all. If it has no first character, then it doesn't start with
either a space or a non-space.

The real question, however, is what the `all-completions' functionality
should be for an empty string. If the first character of a string determines
some behavior, and the string can be empty, then the empty-string behavior
needs also to be defined (and documented). That is, it needs to be defined
separately from the first-character behavior - they are disjoint cases.

    > I think the functionality should be changed

    I don't agree.  That would change the behaviour of buffer
    completions: If you type TAB in the empty minibuffer when being
    prompted for a buffer you don't want buffers starting with a space
    in the list of completions.

That's true, but TAB is not bound to `all-completions'. I want to fix
`all-completions'; I don't want to change minibuffer completion. What you
correctly point out is that I was wrong in my assumption that no existing
code depends on this (bugged, IMO) behavior.

A quick look at the C code tells me that `all-completions' is used only once
(by Fminibuffer_completion_help), and then only with a non-nil value for
HIDE-SPACES. I could be wrong (I don't speak C well), but I think I'm right.

IOW, the C code does not use the possibility of providing different values
for HIDE-SPACES at all. The definition of `all-completion' wrt HIDE-SPACES
should not depend on a single use of it. If that were to be the case, then
we might as well eliminate the HIDE-SPACES argument and always give it the
non-nil behavior. `all-completions' is supposed to be more general than
that.

If we make the fix to `all-completions' that I propose, then, yes,
Fminibuffer_completion_help would need to be redefined to not simply call
all-completions with a non-nil HIDE-SPACES arg. It would itself need to
treat "" so as to avoid completions that start with a space. That behavior
is part of _its_ logic, not part of `all-completions' logic.

IOW, I'm suggesting that `all-completions' should return all of the
completions (including those that start with space) when given "", but
Fminibuffer_completion_help (hence also `minibuffer-complete', and
`minibuffer-complete-word', which call Fminibuffer_completion_help) should
keep the behavior it has now. It just wouldn't be able to rely on providing
a non-nil HIDE-SPACES to `all-completions' - it would have to treat the ""
case itself since it doesn't want all completions in the case of no typed
input.

My concern is using `all-completions' from Lisp. The unique use of
`all-completions' in the C code could be made to work with the fix I
suggested.

Since I was wrong about C code depending on the current behavior, perhaps
I'm also wrong about Lisp code depending on it. The fix would require first
checking all calls to `all-completions' that provide an explicit HIDE-SPACES
arg. I just spent a few minutes doing that, and guess what? (drum roll...) I
found zero (0) uses of an explicit HIDE-SPACES arg! The only place I found
this used anywhere in the Emacs code is in the C code, and then only in a
single call by Fminibuffer_completion_help.

`all-completions' should be for Lisp programmers, not just for
Fminibuffer_completion_help. The (all-completions "" ...) idiom should DTRT:
return _all_ completions. I don't see any reason not to fix this now.