From unknown Fri Jun 20 07:17:42 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#42411 <42411@debbugs.gnu.org> To: bug#42411 <42411@debbugs.gnu.org> Subject: Status: Bug with M-x compile Reply-To: bug#42411 <42411@debbugs.gnu.org> Date: Fri, 20 Jun 2025 14:17:42 +0000 retitle 42411 Bug with M-x compile reassign 42411 emacs submitter 42411 Gregory Heytings severity 42411 normal tag 42411 fixed patch thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 18 05:02:14 2020 Received: (at submit) by debbugs.gnu.org; 18 Jul 2020 09:02:14 +0000 Received: from localhost ([127.0.0.1]:58419 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jwijW-0000DG-FR for submit@debbugs.gnu.org; Sat, 18 Jul 2020 05:02:14 -0400 Received: from lists.gnu.org ([209.51.188.17]:50852) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jwijR-0000D6-Nq for submit@debbugs.gnu.org; Sat, 18 Jul 2020 05:02:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44164) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jwijR-0001mz-FM for bug-gnu-emacs@gnu.org; Sat, 18 Jul 2020 05:02:09 -0400 Received: from mx.sdf.org ([205.166.94.24]:65160) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jwijP-0003wr-Fm for bug-gnu-emacs@gnu.org; Sat, 18 Jul 2020 05:02:09 -0400 Received: from sdf.org (IDENT:ghe@faeroes.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 06I91puA023348 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 18 Jul 2020 09:01:51 GMT Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 06I91p0s015227; Sat, 18 Jul 2020 09:01:51 GMT Date: Sat, 18 Jul 2020 09:01:48 +0000 From: Gregory Heytings To: bug-gnu-emacs@gnu.org Subject: Bug with M-x compile Message-ID: User-Agent: Alpine 2.21 (NEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Received-SPF: pass client-ip=205.166.94.24; envelope-from=ghe@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/07/18 03:43:37 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Thanks for fixing (the second part of) bug#42383. The first part remains unfixed, however: 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: --- 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-*". If one really wants to allow spaces (but not TABs) at the beginning of a target label, the following regexp could also be used: "^ *\\([^\t\n#%.$][^:=\n]*\\)\\s-*:[^=]". The current regexp is an old one (since Emacs 21 at least), and is inconsistent with for example how bash computes completions (see _make_target_extract_script). If changing the regexp is not an option, please make it a configuration option. Gregory From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 25 03:25:09 2020 Received: (at 42411) by debbugs.gnu.org; 25 Jul 2020 07:25:09 +0000 Received: from localhost ([127.0.0.1]:49267 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jzEYP-00068N-J5 for submit@debbugs.gnu.org; Sat, 25 Jul 2020 03:25:09 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46190) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jzEYM-00067j-49 for 42411@debbugs.gnu.org; Sat, 25 Jul 2020 03:25:07 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41581) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jzEYG-0004v0-HJ; Sat, 25 Jul 2020 03:25:00 -0400 Received: from [176.228.60.248] (port=3344 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jzEYF-0007rL-HH; Sat, 25 Jul 2020 03:25:00 -0400 Date: Sat, 25 Jul 2020 10:24:46 +0300 Message-Id: <83tuxwcb0h.fsf@gnu.org> From: Eli Zaretskii To: Gregory Heytings In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#42411: Bug with M-x compile References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 42411 Cc: 42411@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 18 Jul 2020 09:01:48 +0000 > From: Gregory Heytings via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > 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. It could very well cause the opposite problem: valid targets are not proposed as completion candidates. You seem to assume that the valid candidates are only those that appear as explicit targets in a Makefile. But that disregards implicit targets, which Make intuits on its own. In the example you show, those implicit targets make no sense, but that's not the only use case we might want to support. In a more general case, there could be targets collected that way which are non-trivial, and which users may wish to have as completion candidates. Another situation we need to consider is the X makefiles, where target names were preceded by whitespace. 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. 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. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 25 19:29:20 2020 Received: (at 42411) by debbugs.gnu.org; 25 Jul 2020 23:29:21 +0000 Received: from localhost ([127.0.0.1]:51362 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jzTbU-0006yh-Js for submit@debbugs.gnu.org; Sat, 25 Jul 2020 19:29:20 -0400 Received: from mx.sdf.org ([205.166.94.24]:51673) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jzTbR-0006yU-Oq for 42411@debbugs.gnu.org; Sat, 25 Jul 2020 19:29:19 -0400 Received: from sdf.org (IDENT:ghe@faeroes.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 06PNTCoo017277 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 25 Jul 2020 23:29:13 GMT Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 06PNTBdv016193; Sat, 25 Jul 2020 23:29:11 GMT Date: Sat, 25 Jul 2020 23:29:09 +0000 From: Gregory Heytings To: 42411@debbugs.gnu.org Subject: Re: bug#42411: Bug with M-x compile In-Reply-To: <83tuxwcb0h.fsf@gnu.org> Message-ID: References: <83tuxwcb0h.fsf@gnu.org> User-Agent: Alpine 2.21 (NEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 42411 Cc: Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: 42411@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > >> 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 From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 26 09:55:47 2020 Received: (at 42411) by debbugs.gnu.org; 26 Jul 2020 13:55:47 +0000 Received: from localhost ([127.0.0.1]:53208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jzh7z-0007TU-GT for submit@debbugs.gnu.org; Sun, 26 Jul 2020 09:55:47 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57330) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jzh7w-0007TO-1l for 42411@debbugs.gnu.org; Sun, 26 Jul 2020 09:55:46 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:35251) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jzh7q-0007ok-Ke; Sun, 26 Jul 2020 09:55:38 -0400 Received: from [176.228.60.248] (port=4371 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jzh7q-00044a-1m; Sun, 26 Jul 2020 09:55:38 -0400 Date: Sun, 26 Jul 2020 16:55:29 +0300 Message-Id: <83r1sybctq.fsf@gnu.org> From: Eli Zaretskii To: Paul Smith In-Reply-To: (message from Gregory Heytings on Sat, 25 Jul 2020 23:29:09 +0000) Subject: Re: bug#42411: Bug with M-x compile References: <83tuxwcb0h.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 42411 Cc: 42411@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 25 Jul 2020 23:29:09 +0000 > From: Gregory Heytings > cc: Eli Zaretskii > > > 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. Paul, could you please chime in and share your views on this? If you want to read the discussion from the beginning, you can find it at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42411 or, if you prefer to read all of it in your MUA, you can download all the messages in the mbox format: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42411;mbox=yes TIA From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 31 14:20:46 2020 Received: (at 42411) by debbugs.gnu.org; 31 Jul 2020 18:20:47 +0000 Received: from localhost ([127.0.0.1]:38587 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k1ZeA-0002xT-KK for submit@debbugs.gnu.org; Fri, 31 Jul 2020 14:20:46 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47800) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k1Ze9-0002xD-Dv for 42411@debbugs.gnu.org; Fri, 31 Jul 2020 14:20:45 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47645) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k1Ze4-0005Ho-6j for 42411@debbugs.gnu.org; Fri, 31 Jul 2020 14:20:40 -0400 Received: from pool-96-233-64-159.bstnma.fios.verizon.net ([96.233.64.159]:36628 helo=pdslaptop.home) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1k1Ze3-00085D-DI; Fri, 31 Jul 2020 14:20:39 -0400 Message-ID: <7a41931db76f055f1e904c964fd5b12eb2ee27b8.camel@gnu.org> Subject: Re: bug#42411: Bug with M-x compile From: Paul Smith To: Eli Zaretskii Date: Fri, 31 Jul 2020 14:20:38 -0400 In-Reply-To: <83r1sybctq.fsf@gnu.org> References: <83tuxwcb0h.fsf@gnu.org> <83r1sybctq.fsf@gnu.org> Organization: GNU's Not UNIX! Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.3-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 42411 Cc: 42411@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: psmith@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On Sun, 2020-07-26 at 16:55 +0300, Eli Zaretskii wrote: > > > 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. > > > Paul, could you please chime in and share your views on this? If you > want to read the discussion from the beginning, you can find it at > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42411 > > or, if you prefer to read all of it in your MUA, you can download all > the messages in the mbox format: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42411;mbox=yes Sorry for the delay in response: it's been a week at $DAYJOB. I guess I'm not exactly sure what the ask is here. It's definitely true that technically, it is possible to have targets that are indented by TABs. A line indented by a TAB is only considered part of a recipe if it appears in the "recipe context", which means somewhere that a recipe is legal in the syntax. If it's not legal for a recipe command to appear there then TABs are treated like any other whitespace. In practice, I think it's highly unlikely that anyone would intentionally use TABs to indent targets because it's so fragile: any reordering of the makefile or adding new lines could cause that makefile to break. So, as a simplifying assumption it makes sense to me to ignore any line starting with TAB when trying to detect targets. Of course, as Eli points out there are certainly a large number of potential targets which cannot be determined using this type of simple investigation. The most obvious are targets that match patterns. However I'll say two things about this: First, I think it's unlikely that users would really want to see all the potential matches of targets when doing completion. It's most likely that they are interested in the "top level" intended command line goals rather than every possible object, source, etc. file that make considers a target due to pattern or suffix rules. Second, I don't think there's currently any good way to list those targets anyway. Just using --print-database by itself won't do it. Using the -n option will help, but many makefiles are not carefully written to ensure that -n is really idempotent, and make -n could delete files or similar operations. And of course this still only finds the targets that are available "by default"; providing a target on the command line could cause more pattern rules to generate more targets that the "default" goal target doesn't. I hope that helps but if I completely missed the point please feel free to redirect me! Cheers, and stay safe; Paul From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 31 14:42:22 2020 Received: (at 42411) by debbugs.gnu.org; 31 Jul 2020 18:42:22 +0000 Received: from localhost ([127.0.0.1]:38620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k1Zz3-0003Uo-Mv for submit@debbugs.gnu.org; Fri, 31 Jul 2020 14:42:21 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52272) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k1Zz2-0003Ud-6n for 42411@debbugs.gnu.org; Fri, 31 Jul 2020 14:42:20 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47901) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k1Zyw-00083P-Uq; Fri, 31 Jul 2020 14:42:14 -0400 Received: from [176.228.60.248] (port=2977 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1k1Zyw-0004Pc-Ek; Fri, 31 Jul 2020 14:42:14 -0400 Date: Fri, 31 Jul 2020 21:42:01 +0300 Message-Id: <838sezedc6.fsf@gnu.org> From: Eli Zaretskii To: psmith@gnu.org In-Reply-To: <7a41931db76f055f1e904c964fd5b12eb2ee27b8.camel@gnu.org> (message from Paul Smith on Fri, 31 Jul 2020 14:20:38 -0400) Subject: Re: bug#42411: Bug with M-x compile References: <83tuxwcb0h.fsf@gnu.org> <83r1sybctq.fsf@gnu.org> <7a41931db76f055f1e904c964fd5b12eb2ee27b8.camel@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 42411 Cc: 42411@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Paul Smith > Cc: 42411@debbugs.gnu.org > Date: Fri, 31 Jul 2020 14:20:38 -0400 > > It's definitely true that technically, it is possible to have targets > that are indented by TABs. A line indented by a TAB is only considered > part of a recipe if it appears in the "recipe context", which means > somewhere that a recipe is legal in the syntax. > > If it's not legal for a recipe command to appear there then TABs are > treated like any other whitespace. > > In practice, I think it's highly unlikely that anyone would > intentionally use TABs to indent targets because it's so fragile: any > reordering of the makefile or adding new lines could cause that > makefile to break. > > So, as a simplifying assumption it makes sense to me to ignore any line > starting with TAB when trying to detect targets. > > Of course, as Eli points out there are certainly a large number of > potential targets which cannot be determined using this type of simple > investigation. The most obvious are targets that match patterns. > > However I'll say two things about this: > > First, I think it's unlikely that users would really want to see all > the potential matches of targets when doing completion. It's most > likely that they are interested in the "top level" intended command > line goals rather than every possible object, source, etc. file that > make considers a target due to pattern or suffix rules. > > Second, I don't think there's currently any good way to list those > targets anyway. Just using --print-database by itself won't do it. > Using the -n option will help, but many makefiles are not carefully > written to ensure that -n is really idempotent, and make -n could > delete files or similar operations. And of course this still only > finds the targets that are available "by default"; providing a target > on the command line could cause more pattern rules to generate more > targets that the "default" goal target doesn't. > > I hope that helps but if I completely missed the point please feel free > to redirect me! Thanks for the feedback. So you think the current regexp is trying to match too much, and the proposed change is TRT and we should make it unconditionally? From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 31 14:58:37 2020 Received: (at 42411) by debbugs.gnu.org; 31 Jul 2020 18:58:37 +0000 Received: from localhost ([127.0.0.1]:38635 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k1aEn-0003tQ-Ds for submit@debbugs.gnu.org; Fri, 31 Jul 2020 14:58:37 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54792) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k1aEl-0003t9-Of for 42411@debbugs.gnu.org; Fri, 31 Jul 2020 14:58:36 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48051) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k1aEg-0001MO-BX for 42411@debbugs.gnu.org; Fri, 31 Jul 2020 14:58:30 -0400 Received: from pool-96-233-64-159.bstnma.fios.verizon.net ([96.233.64.159]:37154 helo=pdslaptop.home) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1k1aEe-0000Ku-V9; Fri, 31 Jul 2020 14:58:29 -0400 Message-ID: <903ac46ee911754227570ea0344b34d142b502af.camel@gnu.org> Subject: Re: bug#42411: Bug with M-x compile From: Paul Smith To: Eli Zaretskii Date: Fri, 31 Jul 2020 14:58:28 -0400 In-Reply-To: <838sezedc6.fsf@gnu.org> References: <83tuxwcb0h.fsf@gnu.org> <83r1sybctq.fsf@gnu.org> <7a41931db76f055f1e904c964fd5b12eb2ee27b8.camel@gnu.org> <838sezedc6.fsf@gnu.org> Organization: GNU's Not UNIX! Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.3-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 42411 Cc: 42411@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: psmith@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On Fri, 2020-07-31 at 21:42 +0300, Eli Zaretskii wrote: > So you think the current regexp is trying to match too much, and the > proposed change is TRT and we should make it unconditionally? I think so yes. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 21 06:46:18 2020 Received: (at 42411) by debbugs.gnu.org; 21 Aug 2020 10:46:18 +0000 Received: from localhost ([127.0.0.1]:45081 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k94Ys-00062c-1C for submit@debbugs.gnu.org; Fri, 21 Aug 2020 06:46:18 -0400 Received: from quimby.gnus.org ([95.216.78.240]:40858) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k94Ym-00062I-It for 42411@debbugs.gnu.org; Fri, 21 Aug 2020 06:46:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=cBeEALyyw9uWRaW2tcB6BZnWWjRy3V1KoaWcNVIKXhY=; b=Z4rlzOVQl4Amu4LTVV/QpfJY4h /lZhuCHNPBOZwgLr0pjIAVJ32/JoZ5FTylgov3oBddSfwae1nUw1Z3uBdMCDfobcVryybGEB17Qb4 PWdXBospA1rgWy1UgmlwryrACHIX6kDoNoI2j30q7Jh+sZDFSJ7zvllxIQbHF7F6rEok=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k94YT-0002Z8-KI; Fri, 21 Aug 2020 12:46:05 +0200 From: Lars Ingebrigtsen To: Gregory Heytings Subject: Re: bug#42411: Bug with M-x compile References: X-Now-Playing: Renaldo and the Loaf's _Songs for Swinging Larvae & Songs from the Surgery_: "N2O (Going Under)" Date: Fri, 21 Aug 2020 12:45:52 +0200 In-Reply-To: (Gregory Heytings's message of "Sat, 18 Jul 2020 09:01:48 +0000") Message-ID: <871rk09t0f.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Gregory Heytings writes: > (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)) Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 42411 Cc: 42411@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gregory Heytings writes: > (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)) Paul Smith writes: > On Fri, 2020-07-31 at 21:42 +0300, Eli Zaretskii wrote: >> So you think the current regexp is trying to match too much, and the >> proposed change is TRT and we should make it unconditionally? > > I think so yes. OK; I've now applied Gregory's patch to Emacs 28 (after checking a bit). -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 21 06:51:51 2020 Received: (at control) by debbugs.gnu.org; 21 Aug 2020 10:51:51 +0000 Received: from localhost ([127.0.0.1]:45086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k94eE-0006BP-Mm for submit@debbugs.gnu.org; Fri, 21 Aug 2020 06:51:50 -0400 Received: from quimby.gnus.org ([95.216.78.240]:40912) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k94eD-0006B8-4M for control@debbugs.gnu.org; Fri, 21 Aug 2020 06:51:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=VGH56c34UVFZQpNk6dWHu6B8v3tcXtTnw3rH/ynFE98=; b=HWlM3VR/6NEeEp/j2zrMrDl4PX HFWkcydM67XqHcFYULIJXFHARCrHlvmI7PMw7VD0nQp0gRZLv6HRChdhEYcu/V9HrqDQdrNYT6kcS 3PtxutS1KU2mDlhCamTFfUaVgxH4jdlj1/5AlT2D7RnRV04MeTUIfq47KejdE99+/YjA=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k94e4-0002aw-S3 for control@debbugs.gnu.org; Fri, 21 Aug 2020 12:51:43 +0200 Date: Fri, 21 Aug 2020 12:51:39 +0200 Message-Id: <87zh6o8e6c.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #42411 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 42411 + patch tags 42411 fixed close 42411 28.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tags 42411 + patch tags 42411 fixed close 42411 28.1 quit From unknown Fri Jun 20 07:17:42 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 18 Sep 2020 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator