GNU bug report logs -
#11906
24.1; completion-at-point failures
Previous Next
Reported by: Leo <sdl.web <at> gmail.com>
Date: Wed, 11 Jul 2012 06:00:01 UTC
Severity: normal
Found in version 24.1
Done: Dmitry Gutov <dgutov <at> yandex.ru>
Bug is archived. No further changes may be made.
Full log
Message #89 received at 11906 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 11 years and 164 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.