--- Begin Message ---
|
Subject: |
28.0.50; Two bugs with M-x compile |
|
Date: |
Wed, 15 Jul 2020 23:23:37 +0000 |
|
User-agent: |
Alpine 2.21 (NEB 202 2017-01-01) |
** Bug 1 **
Steps to reproduce:
1. create a Makefile with a few targets
2. start emacs -Q
3. M-x compile
4. press TAB: the list of targets is displayed
5. type the first character of an existing target, and press TAB
6. the result is a "[No match]"
This has been working correctly for years (tested with Emacs 24, 25, 26),
and does not work anymore with Emacs 28.
It seems that at step 5 above the list of completion candidates that is
considered are subdirectories.
** Bug 2 **
There are too many completion candidates for the list of targets. For
example, for the Makefile "foo:\n\techo foo:\n" two candidates are
displayed: "foo" and "echo". It seems that the regexp in
pcmpl-gnu-make-targets is too large, and should be fixed as follows:
--- pcmpl-gnu.el.orig 2020-06-29 17:39:26.000000000 +0000
+++ pcmpl-gnu.el 2020-07-15 22:43:14.368938346 +0000
@@ -118,7 +118,7 @@
Return the new list."
(goto-char (point-min))
(while (re-search-forward
- "^\\s-*\\([^\n#%.$][^:=\n]*\\)\\s-*:[^=]" nil t)
+ "^\\([^\t\n#%.$][^:=\n]*\\)\\s-*:[^=]" nil t)
(setq targets (nconc (split-string (match-string-no-properties 1))
targets)))
targets)
I see no reason to allow one or more TABs or spaces at the beginning of
targets, as does the "^\\s-*".
Gregory
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#42383: 28.0.50; Two bugs with M-x compile |
|
Date: |
Sat, 18 Jul 2020 11:22:50 +0300 |
unarchive 10417
reopen 10417
unarchive 34330
reopen 34330
thanks
> From: Alex Branham <alex.branham@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, Gregory Heytings <ghe@sdf.org>,
> 42383@debbugs.gnu.org
> Date: Thu, 16 Jul 2020 17:39:57 -0400
>
> > yet, `pcomplete-completions-at-point` is supposed to perform filename
> > completion also (via `pcomplete-default-completion-function`), so
> > I think `pcomplete-completions-at-point` should come first and I suspect
> > that the problem in bug#34330 is internal to pcomplete and the above
> > commit just worked around it.
>
> I find pcomplete really confusing (why is it that there's a whole second
> kind of completion framework outside completion-at-point?). But yes,
> sounds like this should be reverted. I didn't notice this regression
> since I use ivy which obviates the need to re-complete after typing a
> letter.
>
> Someone will need to reopen bugs #10417 and #34330.
OK, thanks. I've reverted the change and reopened those two bugs.
--- End Message ---