GNU bug report logs - #42383
28.0.50; Two bugs with M-x compile

Previous Next

Package: emacs;

Reported by: Gregory Heytings <ghe <at> sdf.org>

Date: Wed, 15 Jul 2020 23:25:02 UTC

Severity: normal

Found in version 28.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 42383 in the body.
You can then email your comments to 42383 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#42383; Package emacs. (Wed, 15 Jul 2020 23:25:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Gregory Heytings <ghe <at> sdf.org>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 15 Jul 2020 23:25:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <ghe <at> sdf.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Two bugs with M-x compile
Date: Wed, 15 Jul 2020 23:23:37 +0000
** 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42383; Package emacs. (Thu, 16 Jul 2020 09:50:02 GMT) Full text and rfc822 format available.

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <ghe <at> sdf.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: 28.0.50; Two bugs with M-x compile
Date: Thu, 16 Jul 2020 09:48:56 +0000
>
> ** 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.
>

Upon further investigation, this bug has been introduced by the patch for 
bug#34330, which moved pcomplete-completions-at-point last in 
shell-dynamic-complete-functions in shell.el:

(defcustom shell-dynamic-complete-functions
   '(comint-c-a-p-replace-by-expanded-history
     shell-environment-variable-completion
     shell-command-completion
     shell-c-a-p-replace-by-expanded-directory
     shell-filename-completion
     comint-filename-completion
     ;; Put `pcomplete-completions-at-point' last so that other
     ;; functions can run before it does, see bug#34330.
     pcomplete-completions-at-point)

See https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e4d17d8cb479ffeeb7dfb7320a1432722ac8df75 .

The obvious fix is to revert the situation (that is, to move 
pcomplete-completions-at-point again before shell-filename-completion), 
but I'm not sure, because bug#34330 would again exist.  That being said, 
I'm not sure that handling the exceptional case of filenames with '&' 
characters correctly when completing in M-x shell (which is what bug#34330 
is about) justifies to break normal behavior in other situations.

Gregory




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42383; Package emacs. (Thu, 16 Jul 2020 15:18:02 GMT) Full text and rfc822 format available.

Message #11 received at 42383 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <ghe <at> sdf.org>, Alex Branham <alex.branham <at> gmail.com>
Cc: 42383 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#42383: 28.0.50; Two bugs with M-x compile
Date: Thu, 16 Jul 2020 18:17:28 +0300
> Date: Thu, 16 Jul 2020 09:48:56 +0000
> From: Gregory Heytings via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> 
> > 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.
> >
> 
> Upon further investigation, this bug has been introduced by the patch for 
> bug#34330, which moved pcomplete-completions-at-point last in 
> shell-dynamic-complete-functions in shell.el:
> 
> (defcustom shell-dynamic-complete-functions
>     '(comint-c-a-p-replace-by-expanded-history
>       shell-environment-variable-completion
>       shell-command-completion
>       shell-c-a-p-replace-by-expanded-directory
>       shell-filename-completion
>       comint-filename-completion
>       ;; Put `pcomplete-completions-at-point' last so that other
>       ;; functions can run before it does, see bug#34330.
>       pcomplete-completions-at-point)
> 
> See https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e4d17d8cb479ffeeb7dfb7320a1432722ac8df75 .
> 
> The obvious fix is to revert the situation (that is, to move 
> pcomplete-completions-at-point again before shell-filename-completion), 
> but I'm not sure, because bug#34330 would again exist.  That being said, 
> I'm not sure that handling the exceptional case of filenames with '&' 
> characters correctly when completing in M-x shell (which is what bug#34330 
> is about) justifies to break normal behavior in other situations.

Indeed.

Stefan, Alex: any ideas for how to fix this?  This problem exists on
the emacs-27 branch, so we must find a safe solution for that branch,
and we must do that quickly.  If we don't have any better ideas, I
think we should revert that fix on emacs-27 at least.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42383; Package emacs. (Thu, 16 Jul 2020 18:56:01 GMT) Full text and rfc822 format available.

Message #14 received at 42383 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gregory Heytings <ghe <at> sdf.org>, Alex Branham <alex.branham <at> gmail.com>,
 42383 <at> debbugs.gnu.org
Subject: Re: bug#42383: 28.0.50; Two bugs with M-x compile
Date: Thu, 16 Jul 2020 14:55:05 -0400
>> Upon further investigation, this bug has been introduced by the patch for 
>> bug#34330, which moved pcomplete-completions-at-point last in 
>> shell-dynamic-complete-functions in shell.el:
> Stefan, Alex: any ideas for how to fix this?

I haven't had time to look into this, but I'll just note that the
commit's message says:

    commit e4d17d8cb479ffeeb7dfb7320a1432722ac8df75
    Author: Alex Branham <alex.branham <at> gmail.com>
    Date:   Thu Aug 15 11:02:38 2019 -0500
    
        Fix filename completion in shell mode buffers
        
        * lisp/shell.el (shell-dynamic-complete-functions): Move
        pcomplete-completions-at-point down the list so that filename
        completion has a chance to complete before pcompletion.
        
        Fixes bug#34330

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.


        Stefan





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42383; Package emacs. (Thu, 16 Jul 2020 21:41:01 GMT) Full text and rfc822 format available.

Message #17 received at 42383 <at> debbugs.gnu.org (full text, mbox):

From: Alex Branham <alex.branham <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Gregory Heytings <ghe <at> sdf.org>, Eli Zaretskii <eliz <at> gnu.org>,
 42383 <at> debbugs.gnu.org
Subject: Re: bug#42383: 28.0.50; Two bugs with M-x compile
Date: Thu, 16 Jul 2020 17:39:57 -0400
On Thu 16 Jul 2020 at 14:55, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:

>         * lisp/shell.el (shell-dynamic-complete-functions): Move
>         pcomplete-completions-at-point down the list so that filename
>         completion has a chance to complete before pcompletion.
>         
>         Fixes bug#34330
>
> 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.

Alex




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42383; Package emacs. (Thu, 16 Jul 2020 22:38:02 GMT) Full text and rfc822 format available.

Message #20 received at 42383 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alex Branham <alex.branham <at> gmail.com>
Cc: Gregory Heytings <ghe <at> sdf.org>, Eli Zaretskii <eliz <at> gnu.org>,
 42383 <at> debbugs.gnu.org
Subject: Re: bug#42383: 28.0.50; Two bugs with M-x compile
Date: Thu, 16 Jul 2020 18:37:08 -0400
>>         * lisp/shell.el (shell-dynamic-complete-functions): Move
>>         pcomplete-completions-at-point down the list so that filename
>>         completion has a chance to complete before pcompletion.
>>         
>>         Fixes bug#34330
>>
>> 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?).

They are not competing nor redundant: pcomplete.el is a system that lets
one explain how to split a line into fields and which completion table
applies to which field (i.e. explain that in a shell command the first
element should be an executable, while the rest will depend on which
executable was used in the first element, ...).

There is sadly some redundancy here in that originally pcomplete.el also
provided a completion UI (under the command `pcomplete`) and this one is
indeed competing with the `completion-at-point` command.
But this part is now obsolete.


        Stefan





Reply sent to Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility. (Sat, 18 Jul 2020 08:24:02 GMT) Full text and rfc822 format available.

Notification sent to Gregory Heytings <ghe <at> sdf.org>:
bug acknowledged by developer. (Sat, 18 Jul 2020 08:24:02 GMT) Full text and rfc822 format available.

Message #25 received at 42383-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex Branham <alex.branham <at> gmail.com>
Cc: ghe <at> sdf.org, monnier <at> iro.umontreal.ca, 42383-done <at> debbugs.gnu.org
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 <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  Gregory Heytings <ghe <at> sdf.org>,
>   42383 <at> 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.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 15 Aug 2020 11:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 226 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.