bug#8926: 24.0.50; pcomplete regression

[Thierry Volpiatto]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>>> Yup.  Because among the various completion cases, the case for "files"
>>>>> used to return a list and now returns a function.  Both are valid
>>>>> completion tables.  Any caller of pcomplete-completions should expect to
>>>>> receive a completion table and not just a list of strings.  It may very
>>>>> well receive a list of strings (which is one kind of completion table),
>>>>> but it may just as well receive something else.
>>>> Yes i saw that, and it's what i didn't understand.
>>> 
>>> BTW, the reason for the above change was not just to fix a bug when
>>> using pcomplete-completions-at-point but also so that partial-completion
>>> now works with pcomplete-entries (so you can "cd ~/e/e TAB" to go to
>>> ~/etc/emacs).
>> Yes, but the downside is now that it is hard to use by external
>> libraries outside the context of emacs shell/eshell.
>
> Presumably such code already handles completion tables, so having to
> handle a completion table rather than a list of strings shouldn't be
> that much of a problem.  Calling `all-completions' shouldn't scare
> those authors.
The problem is not here, the problem is we have now to do extra
computing to extract the context (i.e command?, lisp-sym?, filename?...).
before, running `pcomplete-completions' was doing all the job, now we
have to use also (funcall (pcomplete-entries) string nil nil) to guess
filename, and then decide what to do.

e.g
(all-completions what (pcomplete-completions))
now we have to extract "what", before `pcomplete-completions' was guessing
that alone.

It would be better if it was returning always a table or always a list.
With a table we could use (funcall (pcomplete-completions)) whithout
worring about "what".

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997