From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 21575 invoked from network); 2 May 2020 00:44:46 -0000 Received-SPF: pass (primenet.com.au: domain of zsh.org designates 203.24.36.2 as permitted sender) receiver=inbox.vuxu.org; client-ip=203.24.36.2 envelope-from= Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 2 May 2020 00:44:46 -0000 Received: (qmail 22754 invoked by alias); 2 May 2020 00:44:32 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 45757 Received: (qmail 6981 invoked by uid 1010); 2 May 2020 00:44:32 -0000 X-Qmail-Scanner-Diagnostics: from wout1-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.2/25793. spamassassin: 3.4.4. Clear:RC:0(64.147.123.24):SA:0(-1.1/5.0):. Processed in 4.63665 secs); 02 May 2020 00:44:32 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrieekgdefiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfgjfhfogggtgfesthhqtd dtredtjeenucfhrhhomhepffgrnhhivghlucfuhhgrhhgrfhcuoegurdhssegurghnihgv lhdrshhhrghhrghfrdhnrghmvgeqnecuggftrfgrthhtvghrnhephfdtteefheevuedthe dutdeifeegteettdejtdffheduieeijeelteetkeduteehnecukfhppedutdelrdeiiedr udehrddvfeelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepugdrshesuggrnhhivghlrdhshhgrhhgrfhdrnhgrmhgv X-ME-Proxy: Date: Sat, 2 May 2020 00:43:47 +0000 From: Daniel Shahaf To: zsh-workers@zsh.org Subject: Re: completion for compilers (cc, gcc...) and -o Message-ID: <20200502004347.5b6d880a@tarpaulin.shahaf.local2> In-Reply-To: <20200501011116.GE818727@zira.vinc17.org> References: <20200430085111.GA1649750@zira.vinc17.org> <20200430181459.051d3fd1@tarpaulin.shahaf.local2> <20200430201747.GA818727@zira.vinc17.org> <5a4631d6-578e-4362-b0b3-e397f0990ebb@www.fastmail.com> <20200501011116.GE818727@zira.vinc17.org> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Vincent Lefevre wrote on Fri, 01 May 2020 03:11 +0200: > On 2020-04-30 22:05:32 +0000, Daniel Shahaf wrote: > > Vincent Lefevre wrote on Thu, 30 Apr 2020 20:17 +00:00: =20 > > > On 2020-04-30 18:14:59 +0000, Daniel Shahaf wrote: =20 > > > > Vincent Lefevre wrote on Thu, 30 Apr 2020 10:51 +0200: =20 > > > > > The -o option is currently handled by > > > > >=20 > > > > > '-o:output file:_files -g "^*.(c|h|cc|C|cxx)(-.)"' > > > > >=20 > > > > > I wonder whether .i files (preprocessed files, e.g. for bug repor= ts) > > > > > should be excluded too. One can choose such files for output with > > > > > "gcc -E", but: > > > > > * in this case, one generally chooses to use the shorter ">" (o= r a > > > > > pipe) rather than "-o" (gcc -E file.c > file.i); =20 > > > >=20 > > > > I don't see how the existence of other ways to create .i files is > > > > a reason not to complete .i files after -o. =20 > > >=20 > > > I've googled a bit, and most examples with -E and storage in a file > > > used the redirection. =20 > >=20 > > You've got your conditional probabilities backwards. The _a priori_ > > likelihood that -o should be used to create a .i file is irrelevant to > > what should be completed after -o. =20 >=20 > The issue is that with a completion result on -o that is unexpected by > the user, there is a risk of destroying a source file, while the user > may expect something more sensible. That'd be a pilot error. People should read command lines before executing them. That's also why _rm doesn't filter out source files, even though rm(1) is as likely to destroy source files as the -o option in _gcc. Besides, source files are generally in version control, so the destruction will generally be reversible (up to local mods). (And I'm still not convinced that completing .i after -o is unexpected.) > And note that after all, filename extensions are just conventions, > and the whole completion system is based on it, so that for instance, > completion on "xz -c" will not propose filenames that do not end with > ".xz" (except when there are no other candidates), even though there > may be unlikely candidates without a ".xz" suffix. I can't quite parse this paragraph, sorry. > Typing "gcc file.i -o f[TAB]" and getting "gcc file.i -o file.i" > does not make any sense. Agreed. > > > BTW, all examples used the -E first, so perhaps > > > accept .i files for -o only when -E is present. > > >=20 > > > Note that GCC describes .i files as source files (among other > > > extensions of source files). =20 > >=20 > > They're _intermediate_ files; they can be either input or output. But > > they _can_ be output, so we should complete them, shouldn't we? =20 >=20 > I would say only with -E, then. Maybe complete them always, but not under the same tag as output files which aren't intermediate files (such as .so files)? When the user has typed =C2=ABcc -o =C2=BB, we don't know whether the user intends to cr= eate a .i, or .o, or .exe, or .so, but in any case separating the possibilities by type (=3D set of extensions) is likely to be helpful. "In the face of ambiguity, refuse the temptation to guess." Cheers, Daniel P.S. I don't understand why it's useful for -o to complete .c files when all files in the directory are .c files. Wouldn't a "No matches" error be more practical? I suppose there's a way to coerce the tag-order style into providing these semantics=E2=80=A6