all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Gregory Heytings <ghe@sdf.org>
Cc: 42411@debbugs.gnu.org
Subject: bug#42411: Bug with M-x compile
Date: Sat, 25 Jul 2020 10:24:46 +0300	[thread overview]
Message-ID: <83tuxwcb0h.fsf@gnu.org> (raw)
In-Reply-To: <alpine.NEB.2.21.2007181038001394.17147@sdf.lonestar.org> (bug-gnu-emacs@gnu.org)

> 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" <bug-gnu-emacs@gnu.org>
> 
> 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.





  reply	other threads:[~2020-07-25  7:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-18  9:01 bug#42411: Bug with M-x compile Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-07-25  7:24 ` Eli Zaretskii [this message]
2020-07-25 23:29   ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-07-26 13:55     ` Eli Zaretskii
2020-07-31 18:20       ` Paul Smith
2020-07-31 18:42         ` Eli Zaretskii
2020-07-31 18:58           ` Paul Smith
2020-08-21 10:45 ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83tuxwcb0h.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=42411@debbugs.gnu.org \
    --cc=ghe@sdf.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.