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 24477 invoked from network); 30 Apr 2020 20:18: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 20:18:44 -0000 Received: (qmail 8669 invoked by alias); 30 Apr 2020 20:18:28 -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: 45746 Received: (qmail 10841 invoked by uid 1010); 30 Apr 2020 20:18:28 -0000 X-Qmail-Scanner-Diagnostics: from joooj.vinc17.net 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(155.133.131.76):SA:0(-1.9/5.0):. Processed in 2.472818 secs); 30 Apr 2020 20:18:28 -0000 X-Envelope-From: vincent@vinc17.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at vinc17.net does not designate permitted sender hosts) Date: Thu, 30 Apr 2020 22:17:47 +0200 From: Vincent Lefevre To: zsh-workers@zsh.org Subject: Re: completion for compilers (cc, gcc...) and -o Message-ID: <20200430201747.GA818727@zira.vinc17.org> Mail-Followup-To: zsh-workers@zsh.org References: <20200430085111.GA1649750@zira.vinc17.org> <20200430181459.051d3fd1@tarpaulin.shahaf.local2> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200430181459.051d3fd1@tarpaulin.shahaf.local2> X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/1.13.5+143 (0fdc8668) vl-126968 (2020-04-29) 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. 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). > > * 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. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)