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 7819 invoked from network); 4 May 2020 23:59:00 -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; 4 May 2020 23:59:00 -0000 Received: (qmail 14601 invoked by alias); 4 May 2020 23:58:51 -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: 45781 Received: (qmail 11969 invoked by uid 1010); 4 May 2020 23:58:50 -0000 X-Qmail-Scanner-Diagnostics: from out2-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.2/25801. spamassassin: 3.4.4. Clear:RC:0(66.111.4.26):SA:0(-1.1/5.0):. Processed in 5.154609 secs); 04 May 2020 23:58:50 -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: gggruggvucftvghtrhhoucdtuddrgeduhedrjeehgddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkjghfofggtgfgsehtqhdttdertdejnecuhfhrohhmpeffrghnihgv lhcuufhhrghhrghfuceougdrshesuggrnhhivghlrdhshhgrhhgrfhdrnhgrmhgvqeenuc ggtffrrghtthgvrhhnpefhtdetfeehveeutdehuddtieefgeettedtjedtffehudeiieej leetteekudetheenucfkphepuddtledrieeirdduhedrvdefleenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegurdhssegurghnihgvlhdrshhh rghhrghfrdhnrghmvg X-ME-Proxy: Date: Mon, 4 May 2020 23:58:03 +0000 From: Daniel Shahaf To: Vincent Lefevre Cc: zsh-workers@zsh.org Subject: Re: completion for compilers (cc, gcc...) and -o Message-ID: <20200504235803.07d7c9dc@tarpaulin.shahaf.local2> In-Reply-To: <20200503231710.GA2808728@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> <20200502004347.5b6d880a@tarpaulin.shahaf.local2> <20200503231710.GA2808728@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 Mon, 04 May 2020 01:17 +0200: > On 2020-05-02 00:43:47 +0000, Daniel Shahaf wrote: > > Vincent Lefevre wrote on Fri, 01 May 2020 03:11 +0200: =20 > > > On 2020-04-30 22:05:32 +0000, Daniel Shahaf wrote: =20 > > > > 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 r= eports) > > > > > > > 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 ">= " (or 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 fi= le > > > > > 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. =20 > >=20 > > 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. =20 >=20 > I type / validate commands quite quickly in general. So, I have some > protections, e.g. "rm" aliased to "rm -i" (ditto for cp and mv), and > I use NO_CLOBBER. But for -o, there is no protection if the target > already exists. On the one hand: The user typed the -o, so the user may be presumed to know that it's destructive. The user typed , which completes existing filenames. Caveat emptor. On the other hand: We do have the RM_STAR_SILENT warning. The rationale behind that warning is that people are going to make typos and execute the command line before they notice them (e.g., `rm * .txt`). In comparison, the _gcc case is going to involve inputs along the lines of =C2=ABgcc -Wall -E = -o -std=3Dc89 foo.c=C2=BB. The command line will be longer, so there'll= be more time to catch the typo before executing it); the failure mode, were the safety net not in place, would be more benign (only one file is lost); and completion is involved, which is generally an interactive process. --- In balance, I'm not convinced that protection should be added. I suppose you could implement in gcc the equivalent of rm's -i flag. That would be analogous to the two examples you gave. > > Besides, source files are generally in version control, so the > > destruction will generally be reversible (up to local mods). =20 >=20 > Generally, but not .i files. I've never seen such files in sources. > Actually, the only use of .i files I've heard of is testcases for > compilers. The first step is to generate the .i file, normally > with a command like "gcc -E [options] file.c > file.i", then do > a sequence of reduction steps on the .i file in order to get a > minimal testcase. Sorry, I don't follow. What has this got to do with the expected completions after -o? > > > 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 "[unxz] -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. =20 > >=20 > > I can't quite parse this paragraph, sorry. =20 >=20 > Sorry, I meant "unxz -c". In general, xz-compressed files will > have a ".xz" extension, but this is not mandatory (with sometimes > a good reason: one can imagine a text-based file format with its > own extension but compressed with xz), and "unxz -c" will happily > decompress such a file (to stdout). However, zsh assumes the .xz > extension by default in unxz completion. >=20 > In short, with its completion rules, zsh makes arbitrary choices > about what to complete, based on the common usage. And I think > that the same kind of choice should be done concerning .i files. The choices aren't "arbitrary"; they are designed to be useful in the common case. Thus, by this line of reasoning, you should be making the case that users who type -o when a .i file exists in the directory will seldom if ever want to complete it=C2=A0=E2=80=94 which is exactly what I'v= e repeatedly asked you to explain. You have argued that _you personally_ would like _gcc to catch errors for you because you read command lines very quickly. However, that's just your personal use, not a general argument, and accordingly the way to handle it is in your dotfiles. > > > I would say only with -E, then. =20 > >=20 > > 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 t= o create > > a .i, or .o, or .exe, or .so, but in any case separating the possibilit= ies > > by type (=3D set of extensions) is likely to be helpful. =20 >=20 > The user would probably have chosen the type of generation before > the -o. For instance, if the directory contains file.c, then "file" > should be regarded as a prefix candidate in what follows: =E2=8B=AE > cc -o >=20 > should just complete to "file", and the user could add an extension > if he wishes to do so. Or maybe it could offer file.o, file.i, file.so, file.exe as completions and let the user choose among them the usual way. > For instance, if a directory contains: >=20 > bar.c > foo.i > obj.o >=20 > and the completion should give a .o file (due to the -c as above), > then the possible completions are >=20 > bar.o (because of bar.c) > foo.o (because of foo.i) > obj.o (usual completion to files that already exist) >=20 > With -E, bar.i should be a possible completion, but I have some > objection concerning foo.i (as I've said earlier). So you're saying that an existing obj.o should be completed after -c but an existing foo.i shouldn't be after -E? Special cases are generally better avoided. > [...] Cheers, Daniel