[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8926: 24.0.50; pcomplete regression
From: |
Thierry Volpiatto |
Subject: |
bug#8926: 24.0.50; pcomplete regression |
Date: |
Fri, 01 Jul 2011 21:30:28 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> 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.
>
> Am I missing something? pcomplete-completions can't be called just like
> that, you have to let-bind a bunch of vars, among which pcomplete-stub
> which will hold the `what':
>
> (let* (pcomplete-stub
> ..various other pcomplete vars need to be let-bound here otherwise
> ..pcomplete-completions will modify the global vars instead.
> (table (pcomplete-completions))
> (old-style-completion-list (all-completions pcomplete-stub table)))
> ..use old-style-completion-list..)
Thanks that's working, i was let binding all these, but wasn't passing
pcomplete-stub to all-completions.
--
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997