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 5726 invoked from network); 30 Apr 2020 22:06:44 -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; 30 Apr 2020 22:06:44 -0000 Received: (qmail 2965 invoked by alias); 30 Apr 2020 22:06:35 -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: 45750 Received: (qmail 2388 invoked by uid 1010); 30 Apr 2020 22:06:34 -0000 X-Qmail-Scanner-Diagnostics: from out3-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(66.111.4.27):SA:0(-2.6/5.0):. Processed in 4.830573 secs); 30 Apr 2020 22:06:34 -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: gggruggvucftvghtrhhoucdtuddrgeduhedrieeigddthecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdffrghnihgvlhcuufhhrghhrghffdcuoegurdhssegurghn ihgvlhdrshhhrghhrghfrdhnrghmvgeqnecuggftrfgrthhtvghrnhepjeeuveehueekje dtffegveelhfethefhlefhfffgudeuhfdtvdehhfejkeeghedtnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepugdrshesuggrnhhivghlrdhshh grhhgrfhdrnhgrmhgv X-ME-Proxy: X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <5a4631d6-578e-4362-b0b3-e397f0990ebb@www.fastmail.com> In-Reply-To: <20200430201747.GA818727@zira.vinc17.org> References: <20200430085111.GA1649750@zira.vinc17.org> <20200430181459.051d3fd1@tarpaulin.shahaf.local2> <20200430201747.GA818727@zira.vinc17.org> Date: Thu, 30 Apr 2020 22:05:32 +0000 From: "Daniel Shahaf" To: zsh-workers@zsh.org Subject: Re: completion for compilers (cc, gcc...) and -o Content-Type: text/plain Vincent Lefevre wrote on Thu, 30 Apr 2020 20:17 +00:00: > On 2020-04-30 18:14:59 +0000, Daniel Shahaf wrote: > > Vincent Lefevre wrote on Thu, 30 Apr 2020 10:51 +0200: > > > The -o option is currently handled by > > > > > > '-o:output file:_files -g "^*.(c|h|cc|C|cxx)(-.)"' > > > > > > I wonder whether .i files (preprocessed files, e.g. for bug reports) > > > 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); > > > > I don't see how the existence of other ways to create .i files is > > a reason not to complete .i files after -o. > > I've googled a bit, and most examples with -E and storage in a file > used the redirection. 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. > BTW, all examples used the -E first, so perhaps > accept .i files for -o only when -E is present. > > Note that GCC describes .i files as source files (among other > extensions of source files). They're _intermediate_ files; they can be either input or output. But they _can_ be output, so we should complete them, shouldn't we? > > > * using such files as a source may be more common. > > > > Assuming so arguendo, how does that bear on what the completion function should do? > > > > > Moreover, if I have a C source "myprogram.c", I generally want the > > > output file (program name) to be "myprogram", or if I need several > > > versions (e.g. because I test several options), I choose this as a > > > prefix, e.g. for "myprogram1", "myprogram2", "myprogram-ok", etc. > > > Now, when "myprogram.c" exists, but not any of the program files, > > > and I try to complete with > > > > > > cc -o my[TAB] > > > > > > I'd like the "myprogram" to be taken into account. > > > > > > Currently it seems that if there are no matches without the excluded > > > pattern, the completion is done on all files, that is, one gets > > > > > > cc -o myprogram.c > > > > > > This does not make any sense since a .c file should normally not be > > > an output file. IMHO, instead of that, one should get the filename > > > without the filename extension: > > > > > > cc -o myprogram > > > > Offering basenames seems rather like your own personal preference, not > > something that the completion system should assume everybody does. > > However, refraining from offering .c files when there are no non-.c > > files around is probably a good idea. > > Actually, many people do this (for compiling individual source > files, otherwise for multi-source projects, a Makefile is used > in general). But it's true that the output file may not be one > that is the basename of a source file. I think of 2 possibilities > (perhaps this should be configurable by the user) for -o: > > 1. For the completion, consider all existing non-source items > (files and directories) + the basename of each source file. > > 2. Consider all existing non-source items, and if there are no > candidates for the completion, then consider the basename of > each source file. I didn't dispute that people run $CC manually; I disputed that we should complete *.(c|h|...)(:r) [sic] after -o. On the other hand, I agreed that we shouldn't offer *.c files after -o even when all files in the directory are named *.c. Hope this clarifies my position. Cheers, Daniel