From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Smith Newsgroups: gmane.emacs.bugs Subject: bug#42411: Bug with M-x compile Date: Fri, 31 Jul 2020 14:20:38 -0400 Organization: GNU's Not UNIX! Message-ID: <7a41931db76f055f1e904c964fd5b12eb2ee27b8.camel@gnu.org> References: <83tuxwcb0h.fsf@gnu.org> <83r1sybctq.fsf@gnu.org> Reply-To: psmith@gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38149"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.36.3-0ubuntu1 Cc: 42411@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jul 31 20:24:39 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k1Zhv-0009p1-GR for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 31 Jul 2020 20:24:39 +0200 Original-Received: from localhost ([::1]:52602 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k1Zhu-0006ha-GA for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 31 Jul 2020 14:24:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58082) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k1ZeQ-0001pj-5L for bug-gnu-emacs@gnu.org; Fri, 31 Jul 2020 14:21:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55274) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1k1ZeP-0005PS-RW for bug-gnu-emacs@gnu.org; Fri, 31 Jul 2020 14:21:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1k1ZeP-0002y3-Nj for bug-gnu-emacs@gnu.org; Fri, 31 Jul 2020 14:21:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Smith Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 31 Jul 2020 18:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42411 X-GNU-PR-Package: emacs Original-Received: via spool by 42411-submit@debbugs.gnu.org id=B42411.159621964711379 (code B ref 42411); Fri, 31 Jul 2020 18:21:01 +0000 Original-Received: (at 42411) by debbugs.gnu.org; 31 Jul 2020 18:20:47 +0000 Original-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 Original-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 Original-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 Original-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 In-Reply-To: <83r1sybctq.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:183743 Archived-At: 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