Re: fix for bug#34330 breaks makefile target complete in `compile' prompt

[Stephen Leake]

Stefan Monnier <address@hidden> writes:

>> It's not clear from this if "applicable" means "there are actual
>> completions", but it appears that it should.
>
> No.  The idea rather is to decide on the completion-table to use only
> based on *where* we are.  You can't easily know whether there are
> any completions (because it depends on completion-styles).

Hmm. Why don't we know the style? Won't completion-try-completion, using
the candidate completion table, return the right result?

> Maybe we should remove comint-filename-completion from the list of
> completion functions and rely on pcomplete-default-completion-function
> for that instead?

No, that's what bug 34330 is about; pcomplete does not handle that case
properly; it either returns no completions, or incorrect completions. I
guess that could be fixed, either by telling pcomplete to always return
nil for a file completion, or by incorporating the logic from
comint-complete (although I think that means adding pcomplete/ls etc, so
it knows it's looking for a file).

Setting pcomplete-default-completion-function to 'ignore might work (ie,
"don't guess if you are not sure"). That could be done in
pcomplete-completions-at-point, so it doesn't affect the normal
operation of pcomplete.

> Or maybe shell-dynamic-complete-functions should not do like
> completion-at-point-functions and should run all its functions (without
> stopping at the first non-nil answer) and then combine them using
> completion-table-in-turn?

That would work in more cases, but it's a big change.

And all of the functions on shell-dynamic-complete-functions can also be
on completion-at-point-functions, so that should change as well.

-- 
-- Stephe