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

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

[Drew Adams]

(all-completions "" ...) is an idiom that returns a list of all possible
completions (in the given context). It is very handy for this, but there is
a hitch.

To me, the following behavior, with non-nil HIDE-SPACES argument, is a bug:

 (all-completions "" '((" a")("b")("c)) nil t) returns
 ("b" "c), not (" a" "b" "c")

This behavior is very old (at least back to Emacs 20), but I doubt that any
existing code depends on it (I have no proof). I cannot see any utility in
this behavior, whereas returning all of the completion candidates seems
appropriate and consistent, and it can be useful.

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 think the functionality should be changed, as well as the doc string,
which should explicitly mention the "" case. Something like this:

 If the optional fourth argument HIDE-SPACES is non-nil,
 then any strings in ALIST that start with a space
 are ignored unless the first char of STRING is a space.
 If STRING is empty (""), then all strings in ALIST are
 returned.

Actually, the last sentence should be stated up front, and not only within
the context of HIDE-SPACES. That is, we should state that it is always true.

WDOT?

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

[Drew Adams]

    To me, the following behavior, with non-nil HIDE-SPACES 
    argument, is a bug:
    
     (all-completions "" '((" a")("b")("c)) nil t) returns
     ("b" "c), not (" a" "b" "c")

Let me be even clearer: STRING = "" should mean treat HIDE-SPACES as nil. 

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

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

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

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

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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.

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

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

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

What are the elements of the empty set?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 12 May 2006 14:27:29 -0700
> 
> To me, the following behavior, with non-nil HIDE-SPACES argument, is a bug:
> 
>  (all-completions "" '((" a")("b")("c)) nil t) returns
>  ("b" "c), not (" a" "b" "c")
> 
> This behavior is very old (at least back to Emacs 20), but I doubt that any
> existing code depends on it (I have no proof).

Actually, I have a proof to the contrary: this feature is used by
buffer-name completions: buffers whose names begin with a space aren't
shown (a.k.a. hidden from the naive users).

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

[Drew Adams]

I was wrong; non-nil HIDE-SPACES with "" is OK as is. Programs can just use
nil HIDE-SPACES with "" to get the alternative behavior.

The doc string should explicitly document the "" case (which is disjoint
from the cases of starting with a space or a non-space), but there is no
need to change the behavior.

Dunno what I was thinking. Sorry for the noise.

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

[Kevin Rodgers]

Andreas Schwab wrote:
> > > I don't follow. An empty string clearly does not start with a space.
> >
> > What does it start with?
> 
> What are the elements of the empty set?

Is the space character a member of the empty set?

-- 
Kevin