Re: Bugs in newly added completion capabilities.

[Luc Teirlinck]

Stefan Monnier wrote:

   Honestly, what's so great about being able to use lists of symbols rather
   than lists of strings?  In Emacs-21, we don't even allow lists of strings,
   but only lists of pairs whose car is a string, and people haven't complained
   about it.

I am not arguing for allowing lists of symbols rather than lists of
strings, but mixed lists of strings and symbols _are_ currently allowed
and try-completion and all-completions now nearly everywhere treat
symbols as being completely equivalent to (symbol-name 'symbol)
since the following change made relatively recently (I thought we were
in a feature freeze, but anyway):

2005-02-22  Kim F. Storm  <address@hidden>

            * minibuf.c (Ftry_completion, Fall_completions): Allow
              both string and symbol keys in alists and hash tables.

Again I am not arguing for or against the desirability of this change,
I am trying to deal with its consequences.

There are two problems: the _nearly_ everywhere is very inconsistent
and the exceptions at first seem totally arbitrary, so it should be
clearly documented what the exceptions are and what the motivation for
the exceptions is.

Secondly, try-completion and all-completions are mainly used by
minibuffer completion functions that can also pass the same argument
to test-completion.  If test-completion treats this argument
differently from the other two (as it currently does), there is the
obvious potential for trouble.

So either one just reverts the 2005-02-22 change, or one needs to
take care of the inconsistency problems I pointed out.

   I don't like the idea of adding "" at the beginning of a completion table.
   Here I have a good reason, which is that it changes the behavior:

      (try-completion "" '("aaa" "aab" "aac"))  => "aa"
      (try-completion "" '("" "aaa" "aab" "aac"))  => ""

Of course, the person consing "" to the front of the completion table
will have to write his code to expect the second answer.

Sincerely,

Luc.