bug#42411: Bug with M-x compile

[Gregory Heytings]

> > There are too many completion candidates in the list of targets when 
> > completing M-x compile.  For example, for the Makefile 
> > "foo:\n\techo\x20bar:\n" three candidates are displayed: "foo", "echo" 
> > and "bar".  The regexp in pcmpl-gnu-make-targets is too large, and 
> > should be fixed as follows:
>
> I'm not sure your proposed change is TRT.

I proposed three options: (1) the regexp "^\\([^\t\n#%.$][^:=\n]*\\)\\s-*:[^=]", (2) the 
regexp "^ *\\([^\t\n#%.$][^:=\n]*\\)\\s-*:[^=]", (3) make that regexp a configuration 
option.

> It could very well cause the opposite problem: valid targets are not 
> proposed as completion candidates.

I agree with you that in more complex cases, it is possible that valid 
targets would not be proposed as completion candidates anymore.  But OTOH 
I don't think it is possible to have a complete list of valid targets only 
by parsing the Makefile with a regexp.  To have such a list it is 
necessary to use make itself (for example by using the output of make 
--print-data-base for GNU Make).

> Another situation we need to consider is the X makefiles, where target 
> names were preceded by whitespace.

Yes, that was my option (2).

> And there could be other situations as well.  I'm not an expert; if we 
> want to review all the possible use cases, perhaps we should ask Paul 
> Smith, the GNU Make maintainer, to join this discussion and help us 
> enumerate the possible cases.

I'm not an expert either, so yes, please ask Paul Smith for advice on 
this.  I do think that the way to compute completion candidates should be 
improved.

There will always be exceptional cases (for example, for GNU Make, 
.RECIPEPREFIX with which it is possible to use another prefix character 
instead of TAB can apparently be used multiple times), but for something 
like 99.9% cases, a line starting with a TAB is a recipe element and not a 
target, a line starting with a '#' is a comment, and a line starting with 
a '.' sets a special variable.  The current regexp correctly excludes the 
last two, but includes the first one.

> So I think we could have the change you propose as an optional feature, 
> but certainly not as the only behavior.  We could later discuss whether 
> this would be an opt-in or opt-out, but IMO it must be controlled by a 
> user option.

Yes, that was my option (3).  I certainly don't want to impose a change on 
everyone, especially as it has been Emacs's behavior for a long time. 
Ideally I think that it should be controlled by a variable, with a 
docstring presenting a number of typical values.

Gregory