[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#42411: Bug with M-x compile
From: |
Gregory Heytings |
Subject: |
bug#42411: Bug with M-x compile |
Date: |
Sat, 25 Jul 2020 23:29:09 +0000 |
User-agent: |
Alpine 2.21 (NEB 202 2017-01-01) |
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