>> For more complex cases, there is also the issue of what to do when some >> parts of the completion are case-sensitive and other parts aren't >> (e.g. completion of case-sensitive envvars in case-insensitive file >> names), although this is less important for completion-at-point than >> for minibuffer completion since you don't have to return a table that >> covers the completion of the whole field (composed of file names and >> env-vars, for example), and instead you can just limit the completion to >> the particular subfield. > There's still something wrong to me in the solution provided by Tassilo. > It works fine, but it is returning a function to bypass the usual > completion code completion code. Ignoring case, like doing smarter > completion (e.g. where the typed prefix does not match the returned > choices at all) is something that is very useful.
> Therefore I wonder if we should either: > - Edit `completion-at-point-functions' docstring to remove the word > "discouraged" in that sentence: > "or a function of no argument to perform completion (discouraged),"; There's a misunderstanding: AFAIK the patch sent by Tassilo does not make the completion-at-point-function return a "function that performs completion" but does properly return completion data (i.e. region start, region end, and completion table), part of which happens to be represented by a function. I.e. this is not one of the discouraged cases. > - Make completing code allows to replace the region being completed with > somethig that does not match at all. AFAIK that's already the case, tho it depends on lots of factors, such as what you mean by "completing code". Stefan