Re: Completion listing of command options ( Re: Size of select listing?)

Re: Completion listing of command options ( Re: Size of select listing?)

[Sven Wischnowsky]

I wrote:

> This makes `_arguments' spit out a message saying `no more arguments'
> in such command line positions. Is that OK for everyone?

This makes it a bit nicer:

- don't unconditionally turn on listing in `_message'
- display `no arguments' or `no more arguments' depending on whether
  the command takes normal arguments at all
- don't display the message if completing after an option (e.g. `rpm -b<TAB>')

Bye
 Sven

diff -u -r oldcompletion/Base/_arguments Completion/Base/_arguments
--- oldcompletion/Base/_arguments	Tue Sep 14 10:19:44 1999
+++ Completion/Base/_arguments	Tue Sep 14 11:43:57 1999
@@ -628,8 +628,11 @@
       [[ -n "$inrest" ]] && opt=''
     fi
     if [[ -z "$def" ]]; then
-      _message 'no more arguments'
-      noargs=yes
+      if [[ -z "$args$rest" ]]; then
+        noargs='no arguments'
+      else
+        noargs='no more arguments'
+      fi
     fi
   fi
 
@@ -651,6 +654,7 @@
 	for i in ${(s::)prefix[2,-1]%%${tmp[1][2]}*} ${tmp[1][2]}; do
 	  _options[${prefix[1]}$i]=''
 	done
+	noargs=''
 	break
       elif compset -P "$tmp[1]"; then
 
@@ -659,6 +663,7 @@
 
 	def="$dopts[$tmp[1]]"
 	opt=''
+	noargs=''
 	break
       fi
       shift 1 tmp
@@ -675,10 +680,12 @@
 	for i in ${(s::)prefix[2,-1]%%${tmp[1][2]}*} ${tmp[1][2]}; do
 	  _options[${prefix[1]}$i]=''
 	done
+	noargs=''
 	break
       elif compset -P "$tmp[1]"; then
 	def="$odopts[$tmp[1]]"
 	opt=''
+	noargs=''
 	break
       fi
       shift 1 tmp
@@ -913,6 +920,8 @@
 
   break
 done
+
+[[ -n "$noargs" ]] && _message "$noargs"
 
 [[ -n "$aret" ]] && return 300
 
diff -u -r oldcompletion/Core/_message Completion/Core/_message
--- oldcompletion/Core/_message	Tue Sep 14 09:09:07 1999
+++ Completion/Core/_message	Tue Sep 14 11:55:32 1999
@@ -10,8 +10,8 @@
     compstate[list]=list
     compstate[insert]=''
     compadd -UX "${format//\\%d/$1}" -n ''
+    compstate[force_list]=yes
   else
-    compadd -X "${format//\\%d/$1}" -n ''
+    compadd -X "${format//\\%d/$1}" -n '' && compstate[force_list]=yes
   fi
-  compstate[force_list]=yes
 fi

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Completion listing of command options ( Re: Size of select listing?)

[Sven Wischnowsky]

I wrote:

> Andrej Borsenkow wrote:
>
> ...
> 
> > Still,  _arguments, even with option_prefix set, behaves funnily:
> > 
> > patch TAB -> completes files. It's O.K.
> > patch foo TAB -> again files. Still O.K.
> > patch foo bar TAB - lists all options! But, patch can have only two arguments -
> > so, I'd expected some message about it.
> 
> The fact that you only get options as possible matches even though you 
> normally don't see them could be taken as a (strong) hint for that,
> couldn't it? However, it wouldn't be hard to add either `:no more arguments:'
> descriptions to the calls of `_arguments' or build this into
> `_arguments'.

This makes `_arguments' spit out a message saying `no more arguments'
in such command line positions. Is that OK for everyone?

Bye
 Sven

P.S.:   I haven't tested it with all completion function (you may have
        guessed that already ;-), but this message can also be used as a 
        measure for the quality of the uses of `_arguments' -- if it
        doesn't print the message in places where no more normal
        argument is understood by the program, the descriptions to
        `_arguments' are probably wrong.
P.P.S.: Not so long ago we were happy if TAB would complete the right
        files and things like that. Nowadays...


diff -u oldcompletion/Base/_arguments Completion/Base/_arguments
--- oldcompletion/Base/_arguments	Mon Sep 13 13:58:09 1999
+++ Completion/Base/_arguments	Mon Sep 13 15:39:19 1999
@@ -8,7 +8,7 @@
 local args rest ws cur nth def nm expl descr action opt arg tmp xor
 local single uns ret=1 aret soptseq soptseq1 sopts prefix _line odescr
 local beg optbeg argbeg nargbeg inopt inrest fromrest cmd="$words[1]"
-local matched curopt
+local matched curopt noargs
 
 # Associative arrays used to collect information about the options.
 
@@ -625,6 +625,10 @@
       fromrest=yes
       [[ -n "$inrest" ]] && opt=''
     fi
+    if [[ -z "$def" ]]; then
+      _message 'no more arguments'
+      noargs=yes
+    fi
   fi
 
   # In any case, we have to complete option names here, but we may
@@ -814,7 +818,7 @@
   # Probably add the option names.
 
   if [[ -n "$opt" &&
-        ( ( nm -eq compstate[nmatches] && -z "$aret" ) ||
+        ( ( ( nm -eq compstate[nmatches] || -n "$noargs" ) && -z "$aret" ) ||
           -z "$compconfig[option_prefix]" || 
           "$compconfig[option_prefix]" = *\!${cmd}* ||
           "$PREFIX" = [-+]* ) ]]; then


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Completion listing of command options ( Re: Size of select listing?)

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> You can set option_prefix configuration key. In this case,  options will be
> generated only if anything else fails. This reduces list to "normal arguments"
> completion.
> 
> Still, I'd like to add handling of `--' as option terminator as well. We need
> some way (option?) to tell _arguments, that `--' ends option list for this
> command, so, that after `--' it won't try to complete command options any more.

  _arguments '--:*:all arguments after this one:<action>'

will make everything after a `--' be completed by `<action>'. RTM.

> You can make options and arguments be displayed in separate groups. It adds to
> readability but does not make list size smaller.

How should it.

> About `-' display - it is currently needed to distinguish between option(s) and
> argument(s). If you can make sure, that only options or only arguments are
> displayed - it could be omitted.

Why would you want it, I wonder. It's only a couple of characters
after all and only very seldom will the omission of the `-'s make the
list small enough to fit on the terminal if it didn't fit with the `-'s.

> But, if you make a patch, do make it to use a configuration key  :-)

*Definitely*, yes.

> Still,  _arguments, even with option_prefix set, behaves funnily:
> 
> patch TAB -> completes files. It's O.K.
> patch foo TAB -> again files. Still O.K.
> patch foo bar TAB - lists all options! But, patch can have only two arguments -
> so, I'd expected some message about it.

The fact that you only get options as possible matches even though you 
normally don't see them could be taken as a (strong) hint for that,
couldn't it? However, it wouldn't be hard to add either `:no more arguments:'
descriptions to the calls of `_arguments' or build this into
`_arguments'.

Bye
 Sven

P.S.: Btw, _long_options is dead.

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Completion listing of command options ( Re: Size of select listing?)

[Andrej Borsenkow]

Yes, starting to experiment with _arguments, I discovered the same problem.

You can set option_prefix configuration key. In this case,  options will be
generated only if anything else fails. This reduces list to "normal arguments"
completion.

Still, I'd like to add handling of `--' as option terminator as well. We need
some way (option?) to tell _arguments, that `--' ends option list for this
command, so, that after `--' it won't try to complete command options any more.

You can make options and arguments be displayed in separate groups. It adds to
readability but does not make list size smaller.

About `-' display - it is currently needed to distinguish between option(s) and
argument(s). If you can make sure, that only options or only arguments are
displayed - it could be omitted.

But, if you make a patch, do make it to use a configuration key  :-)

Still,  _arguments, even with option_prefix set, behaves funnily:

patch TAB -> completes files. It's O.K.
patch foo TAB -> again files. Still O.K.
patch foo bar TAB - lists all options! But, patch can have only two arguments -
so, I'd expected some message about it.

/andrej

>
> It doesn't so much relate to handling the screen size but, one area
> which I really don't like about the way _arguments and _long_options
> work is the way options are considered possible matches straight-away.

Completion listing of command options (Re: Size of select listing?)

[Bart Schaefer]

On Sep 10,  4:23pm, Oliver Kiddle wrote:
} Subject: Re: Size of select listing?
} 
} I don't like the mixed file and option lists [...] because 9 times out
} of 10 I don't care what the options to a particular command are and if I
} do, I'll have typed the minus already.

I tend to agree with this.  If a command *requires* at least one option
before anything else can be completed, though, it might be nice to have
more indication of that than just a beep.

} [Historically] options
} are only completed after an initial minus has been typed and long
} options, only after an initial two minuses. I also think it is better if
} the minus signs are not displayed in the lists so as to save a bit more
} screen space - I don't think they add to the readability at all.

However, I do like seeing the long options along with the short ones
after only a single '-' has been typed.  I may not remember which short
option goes with which long one, or that there is a long one that has
no corresponding short, or whatever.  Because of this, I prefer to see
the leading '-' or '--' in the listing (particularly as long as there
remain some commands that have "long options" but still use one '-' to
introduce them).

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com