zsh-workers
 help / color / mirror / code / Atom feed
* completion for compilers (cc, gcc...) and -o
@ 2020-04-30  8:51 Vincent Lefevre
  2020-04-30 17:57 ` Bart Schaefer
  2020-04-30 18:14 ` Daniel Shahaf
  0 siblings, 2 replies; 15+ messages in thread
From: Vincent Lefevre @ 2020-04-30  8:51 UTC (permalink / raw)
  To: zsh-workers

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);
  * using such files as a source may be more common.

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

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: completion for compilers (cc, gcc...) and -o
  2020-04-30  8:51 completion for compilers (cc, gcc...) and -o Vincent Lefevre
@ 2020-04-30 17:57 ` Bart Schaefer
  2020-04-30 18:14 ` Daniel Shahaf
  1 sibling, 0 replies; 15+ messages in thread
From: Bart Schaefer @ 2020-04-30 17:57 UTC (permalink / raw)
  To: zsh-workers

On Thu, Apr 30, 2020 at 1:52 AM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> 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.
>
> 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 [...]
>
>   cc -o my[TAB]
>
> I'd like the "myprogram" to be taken into account.

That seems pretty simple:

zstyle :completion::complete:gcc:option-o-1: file-patterns \
    "^*.(c|h|cc|C|cxx|i)(-.) *.(c|cc|C|cxx)(N\:r)"

Interesting tidbit, you have to backslash the colon there because
_files is parsing this in pattern:tag format, and it's not clever
about parens.

If we think this is useful enough to fold in to the default (pardon
likely line wrapping by gmail):

diff --git a/Completion/Unix/Command/_gcc b/Completion/Unix/Command/_gcc
index 9ec09200e..7437b96c0 100644
--- a/Completion/Unix/Command/_gcc
+++ b/Completion/Unix/Command/_gcc
@@ -390,7 +390,7 @@ languages=(
 # generic options (from --help)
 args+=(
   '-###[print commands to run this compilation]'
-  '-o:output file:_files -g "^*.(c|h|cc|C|cxx)(-.)"'
+  '-o:output file:_files -g "^*.(c|h|cc|C|cxx|i)(-.) *.(c|cc|C|cxx)(N\:r)"'
   '-x[Specify the language of the following input files]:input file
language:('"$languages"')'
   '+e-:virtual function definitions in classes:((0\:only\ interface
1\:generate\ code))'
   '-d-:dump:->dump'

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: completion for compilers (cc, gcc...) and -o
  2020-04-30  8:51 completion for compilers (cc, gcc...) and -o Vincent Lefevre
  2020-04-30 17:57 ` Bart Schaefer
@ 2020-04-30 18:14 ` Daniel Shahaf
  2020-04-30 20:17   ` Vincent Lefevre
  1 sibling, 1 reply; 15+ messages in thread
From: Daniel Shahaf @ 2020-04-30 18:14 UTC (permalink / raw)
  To: Vincent Lefevre; +Cc: zsh-workers

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.

>   * 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.

Cheers,

Daniel

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: completion for compilers (cc, gcc...) and -o
  2020-04-30 18:14 ` Daniel Shahaf
@ 2020-04-30 20:17   ` Vincent Lefevre
  2020-04-30 20:32     ` Bart Schaefer
  2020-04-30 22:05     ` Daniel Shahaf
  0 siblings, 2 replies; 15+ messages in thread
From: Vincent Lefevre @ 2020-04-30 20:17 UTC (permalink / raw)
  To: zsh-workers

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 <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: completion for compilers (cc, gcc...) and -o
  2020-04-30 20:17   ` Vincent Lefevre
@ 2020-04-30 20:32     ` Bart Schaefer
  2020-04-30 20:54       ` Vincent Lefevre
  2020-04-30 22:05     ` Daniel Shahaf
  1 sibling, 1 reply; 15+ messages in thread
From: Bart Schaefer @ 2020-04-30 20:32 UTC (permalink / raw)
  To: zsh-workers

On Thu, Apr 30, 2020 at 1:18 PM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> (perhaps this should be configurable by the user) for -o:

Hmm, people seem not to have seen my zstyle example?

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: completion for compilers (cc, gcc...) and -o
  2020-04-30 20:32     ` Bart Schaefer
@ 2020-04-30 20:54       ` Vincent Lefevre
  2020-04-30 22:34         ` Daniel Shahaf
  0 siblings, 1 reply; 15+ messages in thread
From: Vincent Lefevre @ 2020-04-30 20:54 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh-workers

On 2020-04-30 13:32:25 -0700, Bart Schaefer wrote:
> On Thu, Apr 30, 2020 at 1:18 PM Vincent Lefevre <vincent@vinc17.net> wrote:
> >
> > (perhaps this should be configurable by the user) for -o:
> 
> Hmm, people seem not to have seen my zstyle example?

I did, and tested it. Thanks a lot. A few comments:

It worked only with "gcc". I've changed it to use

  ":completion::complete:(c99|cc|gcc*):option-o-1:"

together with

  compdef c99=gcc

to support the c99 utility.

Now I'm wondering whether there is a way to automatically apply
the zstyle to the _gcc command list (I also sometimes use clang
and so on).

I was also wondering whether there is a way to get the extension
list automatically from the one in _gcc (assuming that it could
evolve[*]).

[*] On this subject, I'm quite sure I've already used the .cpp
extension. I do not program in C++, but sometimes have to do
some tests of small examples... I think that it should be added
to the standard list, but C++ programmers may tell you more.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: completion for compilers (cc, gcc...) and -o
  2020-04-30 20:17   ` Vincent Lefevre
  2020-04-30 20:32     ` Bart Schaefer
@ 2020-04-30 22:05     ` Daniel Shahaf
  2020-05-01  1:11       ` Vincent Lefevre
  1 sibling, 1 reply; 15+ messages in thread
From: Daniel Shahaf @ 2020-04-30 22:05 UTC (permalink / raw)
  To: zsh-workers

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: completion for compilers (cc, gcc...) and -o
  2020-04-30 20:54       ` Vincent Lefevre
@ 2020-04-30 22:34         ` Daniel Shahaf
  2020-04-30 22:36           ` Daniel Shahaf
  0 siblings, 1 reply; 15+ messages in thread
From: Daniel Shahaf @ 2020-04-30 22:34 UTC (permalink / raw)
  To: Vincent Lefevre; +Cc: Bart Schaefer, zsh-workers

Vincent Lefevre wrote on Thu, 30 Apr 2020 22:54 +0200:
> Now I'm wondering whether there is a way to automatically apply
> the zstyle to the _gcc command list (I also sometimes use clang
> and so on).

This? —

zstyle -e ":completion::complete:*:option-o-1:" file-patterns '(( ${+funcstack[_gcc]} )) && reply=( … )'

---

More generally, I think it might be nice if the code evaluated by
«zstyle -e» could be told what context it's being looked up under.
Something like this:

% zstyle -e '*' foo 'echo $CONTEXT > /dev/tty'
% zstyle -s bar foo REPLY
bar
% 

(though the name $CONTEXT is already taken)

> I was also wondering whether there is a way to get the extension
> list automatically from the one in _gcc (assuming that it could
> evolve[*]).
> 

I don't know how likely it is to evolve, but I suppose we could drop
the list of extensions in a variable, «cc_extensions=( c h cc C cxx cpp
hpp )», then you'll be able to use «zstyle -e» to build on top of it?

> [*] On this subject, I'm quite sure I've already used the .cpp
> extension. I do not program in C++, but sometimes have to do
> some tests of small examples... I think that it should be added
> to the standard list, but C++ programmers may tell you more.

Sure.  This? —

diff --git a/Completion/Unix/Command/_gcc b/Completion/Unix/Command/_gcc
index 9ec09200e..20b3abe59 100644
--- a/Completion/Unix/Command/_gcc
+++ b/Completion/Unix/Command/_gcc
@@ -390,7 +390,7 @@ languages=(
 # generic options (from --help)
 args+=(
   '-###[print commands to run this compilation]'
-  '-o:output file:_files -g "^*.(c|h|cc|C|cxx)(-.)"'
+  '-o:output file:_files -g "^*.(c|h|cc|C|cxx|cpp|hpp)(-.)"'
   '-x[Specify the language of the following input files]:input file language:('"$languages"')'
   '+e-:virtual function definitions in classes:((0\:only\ interface 1\:generate\ code))'
   '-d-:dump:->dump'
@@ -1004,7 +1004,7 @@ args+=(
   '--help[Display this information]'
   '--no-warnings[Same as -w]'
   '--optimize[Same as -O]'
-  '--output[Same as -o]'
+  '--output:output file:_files -g "^*.(c|h|cc|C|cxx|cpp|hpp)(-.)"'
   '--param[Set parameter <param> to value.  See manpage for a complete list of parameters]:name=value'
   '--verbose[Same as -v]'
   '--version[Display version information]'

Cheers,

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: completion for compilers (cc, gcc...) and -o
  2020-04-30 22:34         ` Daniel Shahaf
@ 2020-04-30 22:36           ` Daniel Shahaf
  2020-04-30 23:07             ` Bart Schaefer
  0 siblings, 1 reply; 15+ messages in thread
From: Daniel Shahaf @ 2020-04-30 22:36 UTC (permalink / raw)
  To: Vincent Lefevre; +Cc: Bart Schaefer, zsh-workers

Daniel Shahaf wrote on Thu, 30 Apr 2020 22:34 +0000:
> Vincent Lefevre wrote on Thu, 30 Apr 2020 22:54 +0200:
> > Now I'm wondering whether there is a way to automatically apply
> > the zstyle to the _gcc command list (I also sometimes use clang
> > and so on).  
> 
> This? —
> 
> zstyle -e ":completion::complete:*:option-o-1:" file-patterns '(( ${+funcstack[_gcc]} )) && reply=( … )'

I meant «${+funcstack[(r)_gcc]}», of course.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: completion for compilers (cc, gcc...) and -o
  2020-04-30 22:36           ` Daniel Shahaf
@ 2020-04-30 23:07             ` Bart Schaefer
  0 siblings, 0 replies; 15+ messages in thread
From: Bart Schaefer @ 2020-04-30 23:07 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Vincent Lefevre, zsh-workers

On Thu, Apr 30, 2020 at 3:36 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Daniel Shahaf wrote on Thu, 30 Apr 2020 22:34 +0000:
> > Vincent Lefevre wrote on Thu, 30 Apr 2020 22:54 +0200:
> > > Now I'm wondering whether there is a way to automatically apply
> > > the zstyle to the _gcc command list (I also sometimes use clang
> > > and so on).
> >
> > zstyle -e ":completion::complete:*:option-o-1:" file-patterns '(( ${+funcstack[_gcc]} )) && reply=( … )'
>
> I meant «${+funcstack[(r)_gcc]}», of course.

You don't need zstyle -e if you use zstyle after compinit:

zstyle :completion::complete:\(${(j:|:)${(@k)_comps[(R)_gcc]##-*}}\):option-o-1:
...

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: completion for compilers (cc, gcc...) and -o
  2020-04-30 22:05     ` Daniel Shahaf
@ 2020-05-01  1:11       ` Vincent Lefevre
  2020-05-02  0:43         ` Daniel Shahaf
  0 siblings, 1 reply; 15+ messages in thread
From: Vincent Lefevre @ 2020-05-01  1:11 UTC (permalink / raw)
  To: zsh-workers

On 2020-04-30 22:05:32 +0000, Daniel Shahaf wrote:
> 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.

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.

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.

> > 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?

I would say only with -E, then.

Typing "gcc file.i -o f[TAB]" and getting "gcc file.i -o file.i"
does not make any sense.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: completion for compilers (cc, gcc...) and -o
  2020-05-01  1:11       ` Vincent Lefevre
@ 2020-05-02  0:43         ` Daniel Shahaf
  2020-05-02  1:26           ` Bart Schaefer
  2020-05-03 23:17           ` Vincent Lefevre
  0 siblings, 2 replies; 15+ messages in thread
From: Daniel Shahaf @ 2020-05-02  0:43 UTC (permalink / raw)
  To: zsh-workers

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:  
> > > 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.  
> 
> 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.
> > > 
> > > 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?  
> 
> 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 «cc -o <TAB>», we don't know whether the user intends to create
a .i, or .o, or .exe, or .so, but in any case separating the possibilities
by type (= 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…

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: completion for compilers (cc, gcc...) and -o
  2020-05-02  0:43         ` Daniel Shahaf
@ 2020-05-02  1:26           ` Bart Schaefer
  2020-05-03 23:17           ` Vincent Lefevre
  1 sibling, 0 replies; 15+ messages in thread
From: Bart Schaefer @ 2020-05-02  1:26 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: zsh-workers

On Fri, May 1, 2020 at 5:44 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> 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…

Back when Sven was working on compadd et al. and building
_main_complete etc., the theory was that file completion should almost
never fail outright unless the target directory was actually empty.
Hence the default to complete directories if there are no files, to
complete files that "don't make sense" if there are none that fit,
etc.  The feeling was that the users would be more surprised if
nothing happened (because the completion system decided for them what
was "wrong"), than they would be by a "wrong" result.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: completion for compilers (cc, gcc...) and -o
  2020-05-02  0:43         ` Daniel Shahaf
  2020-05-02  1:26           ` Bart Schaefer
@ 2020-05-03 23:17           ` Vincent Lefevre
  2020-05-04 23:58             ` Daniel Shahaf
  1 sibling, 1 reply; 15+ messages in thread
From: Vincent Lefevre @ 2020-05-03 23:17 UTC (permalink / raw)
  To: zsh-workers

On 2020-05-02 00:43:47 +0000, Daniel Shahaf wrote:
> 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:  
> > > > 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.  
> > 
> > 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.

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.

Note: I also use \rm, etc., but in such a case, I pay more attention
to what I type.

> Besides, source files are generally in version control, so the
> destruction will generally be reversible (up to local mods).

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.

> > 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.

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.

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.

> > Typing "gcc file.i -o f[TAB]" and getting "gcc file.i -o file.i"
> > does not make any sense.
> 
> Agreed.

So the completion rule should avoid generating such a case.

[...]
> > 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 «cc -o <TAB>», we don't know whether the user intends to create
> a .i, or .o, or .exe, or .so, but in any case separating the possibilities
> by type (= set of extensions) is likely to be helpful.

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:

  cc -c -o <TAB>

should complete to "file.o", and

  cc -E -o <TAB>

could complete to "file.i", but

  cc -o <TAB>

should just complete to "file", and the user could add an extension
if he wishes to do so.

About, I've said "file.o", "file.i" and "file", because "file" was
the only prefix candidate. The list of prefix candidates should be
the source files in the directory with their extension removed.

For instance, if a directory contains:

  bar.c
  foo.i
  obj.o

and the completion should give a .o file (due to the -c as above),
then the possible completions are

  bar.o   (because of bar.c)
  foo.o   (because of foo.i)
  obj.o   (usual completion to files that already exist)

With -E, bar.i should be a possible completion, but I have some
objection concerning foo.i (as I've said earlier). If foo.i is
already a source argument in the command line, then it must not
be proposed for the completion after -o.

With just "cc -o", the possible completions are

  bar   (because of bar.c)
  foo   (because of foo.i)
  obj   (as one can generate executables from .o files, i.e. cc can
        be used for linking, and the executable name is likely to be
        based on one of the existing source or .o files)

Well, that's no longer completing to existing files, but some kind
of predictive completion.

> "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…

See above.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: completion for compilers (cc, gcc...) and -o
  2020-05-03 23:17           ` Vincent Lefevre
@ 2020-05-04 23:58             ` Daniel Shahaf
  0 siblings, 0 replies; 15+ messages in thread
From: Daniel Shahaf @ 2020-05-04 23:58 UTC (permalink / raw)
  To: Vincent Lefevre; +Cc: zsh-workers

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:  
> > > On 2020-04-30 22:05:32 +0000, Daniel Shahaf wrote:  
> > > > 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.    
> > > 
> > > 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.  
> 
> 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 <TAB>, 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 «gcc -Wall -E -o
<TAB> -std=c89 foo.c».  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).  
> 
> 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.  
> > 
> > I can't quite parse this paragraph, sorry.  
> 
> 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.
> 
> 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 — which is exactly what I've 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.  
> > 
> > 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 «cc -o <TAB>», we don't know whether the user intends to create
> > a .i, or .o, or .exe, or .so, but in any case separating the possibilities
> > by type (= set of extensions) is likely to be helpful.  
> 
> 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:
>   cc -o <TAB>
> 
> 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:
> 
>   bar.c
>   foo.i
>   obj.o
> 
> and the completion should give a .o file (due to the -c as above),
> then the possible completions are
> 
>   bar.o   (because of bar.c)
>   foo.o   (because of foo.i)
>   obj.o   (usual completion to files that already exist)
> 
> 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2020-05-04 23:59 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-30  8:51 completion for compilers (cc, gcc...) and -o Vincent Lefevre
2020-04-30 17:57 ` Bart Schaefer
2020-04-30 18:14 ` Daniel Shahaf
2020-04-30 20:17   ` Vincent Lefevre
2020-04-30 20:32     ` Bart Schaefer
2020-04-30 20:54       ` Vincent Lefevre
2020-04-30 22:34         ` Daniel Shahaf
2020-04-30 22:36           ` Daniel Shahaf
2020-04-30 23:07             ` Bart Schaefer
2020-04-30 22:05     ` Daniel Shahaf
2020-05-01  1:11       ` Vincent Lefevre
2020-05-02  0:43         ` Daniel Shahaf
2020-05-02  1:26           ` Bart Schaefer
2020-05-03 23:17           ` Vincent Lefevre
2020-05-04 23:58             ` Daniel Shahaf

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).