[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fix for bug#34330 breaks makefile target complete in `compile' promp
Re: fix for bug#34330 breaks makefile target complete in `compile' prompt
Sun, 15 Sep 2019 13:07:29 -0700
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (windows-nt)
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
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.