[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#42383: closed (28.0.50; Two bugs with M-x compile)

From: GNU bug Tracking System
Subject: bug#42383: closed (28.0.50; Two bugs with M-x compile)
Date: Sat, 18 Jul 2020 08:24:02 +0000

Your message dated Sat, 18 Jul 2020 11:22:50 +0300
with message-id <837dv1i65h.fsf@gnu.org>
and subject line Re: bug#42383: 28.0.50; Two bugs with M-x compile
has caused the debbugs.gnu.org bug report #42383,
regarding 28.0.50; Two bugs with M-x compile
to be marked as done.

(If you believe you have received this mail in error, please contact

42383: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=42383
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- 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))

I see no reason to allow one or more TABs or spaces at the beginning of targets, as does the "^\\s-*".


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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]