bug#42411: Bug with M-x compile

[Eli Zaretskii]

> From: Paul Smith <psmith@gnu.org>
> 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?