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

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

[Stephen Leake]

bug#34330 (now closed) was about completing file names with special
chars in the shell. The fix was to move `pcomplete-completions-at-point'
to last in `shell-dynamic-complete-functions'.

However, that now breaks completing on makefile targets in the prompt
for `compile'.

The problem is that `comint-filename-completion' returns non-nil even
when there are no filename completions for the word at point.

One fix would be to make `comint--complete-file-name-data' return nil if
`try-completion' returns nil.

The real cause for bug#34330 is that pcomplete uses
`pcomplete-default-completion-function' in this case (there is no
pcomplete/ls), and it also returns a non-nil result even when there are
no completions.

The doc string for `completion-at-point-functions' says, in part:

    should return either nil, meaning it is not applicable at point,

It's not clear from this if "applicable" means "there are actual
completions", but it appears that it should.

So should these functions be fixed to return nil when there are no completions?

--
-- Stephe

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

[Stefan Monnier]

> 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).

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

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?


        Stefan

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

[Stephen Leake]

Stefan Monnier <monnier@iro.umontreal.ca> 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

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

[Stefan Monnier]

>> 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?

You could try and do that, but it might make things too slow
(completion-at-point-functions is also called at times with no
intention to actually perform the completion, but rather just to know
if we're still in the same completion-spot as before, e.g. to know when
to pop-down the *Completions* buffer).

> comint-complete (although I think that means adding pcomplete/ls etc, so
> it knows it's looking for a file).

I don't think pcomplete/ls would help in any way.  The issue is with
*all* commands: we want to complete file-names by default (i.e. the
absence of any other information).

Also I think it makes sense to allow file-name completion for make
arguments, since even if not listed explicitly in the Makefile, it's
likely that "make <file>" can be a valid&useful command.

> 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.

Oh, wait.  When you said `pcomplete` before were you sometimes talking
about the specific `pcomplete` command rather than about the
pcomplete.el functionality in general?
Nowadays the `pcomplete` command should basically not be used any more
(the pcomplete functionality should be used from completion-at-point via
pcomplete-completions-at-point instead).


        Stefan