bug#11906: 24.1; completion-at-point failures

[Dmitry Gutov <dgutov@yandex.ru>]

On 06.12.2013 16:04, Leo Liu wrote:
> Another issue as mentioned in the report is when you complete, for
> example, 'abc' to 'aa bb cc' (or whatever strange chars are in the
> completion candidate) and the completion function fails to go back to
> the start.

It seems to me that `completion-at-point' isn't a good facility to 
complete space-separated lists of words or symbols (unlike, say, 
hippie-expand).

Suppose it works, and you have candidates: "aa bb cc", "aa bd ee", 
"aabbc ef". You type "aa", press C-M-i, it completes to the common 
prefix: "aa b". Even if `completion-at-point' still remembers where the 
candidate started, what if you exit `completion-in-region-mode' via, 
say, cursor, movement, and then go back to after "aa b". When you press 
C-M-i again, what completion candidates would you expect to see? Not "aa 
bb cc" and "aa bd ee", right?

Note that this can be fixed in specific completion-at-point functions. 
For example, Objective-C completion can look at the context, or maybe 
just always treat semicolons as symbol constituents (I don't really know 
the syntax).

> Also instead of calling completion function to check if start has
> changed to decide to exit completion-in-region-mode, how about let any
> char insertion or deletion exit the mode instead?

Could be good for some cases and users, but this prohibits the user from 
looking at the completions buffer and typing one of the candidates, 
manually (maybe a part of it, until it's unique).

Hiding the completions buffer right after one character is typed can 
make it less useful.