emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bugs in newly added completion capabilities.


From: Stefan Monnier
Subject: Re: Bugs in newly added completion capabilities.
Date: Thu, 30 Jun 2005 13:42:15 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

>> Yes, but let me first make sure I understand.  Is the reason that we
>> do not want _any_ symbol as car of the list that forbidding _any_
>> symbol as car of the list actually seems _more natural_ than just
>> forbidding lambda?  It seems that any symbol other than lambda can not
>> be mistaken for the car of an anonymous lambda expresion and hence
>> could not lead to ambiguity.

> One possible reason is that if we allow almost all symbol lists, people
> will tend to overlook the need for a `lambda' special case, write their
> code to use straight-forward symbol lists -- and odd bugs will arise
> when lambda does happen to occur at the beginning of such a list.

> Always requiring an initial "" forces the problem to be dealt with, so
> will make such code more robust.

I don't like the idea of changing assoc-string to also match symbols.
Maybe it won't lead to any catastrophe, but it just sounds wrong.

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"))  => ""

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.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]