|
From: | Dmitry Gutov |
Subject: | bug#11906: 24.1; completion-at-point failures |
Date: | Sat, 07 Dec 2013 04:02:23 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |