Size of select listing?

Size of select listing?

[Andrej Borsenkow]

Running under dtterm with 24x80 size and doing

patch TAB

creates a select listing longer than screen size. At least, if I do it in a
directory with ~ 15 files.

bor@itsrm2:~%> patch
--backup                  --reverse                 -i
--backup-if-mismatch      --set-time                -l
--basename-prefix         --set-utc                 -n
--batch                   --strip                   -o
--binary                  --suffix                  -p
--context                 --unified                 -r
--directory               --use-index-line          -s
--dry-run                 --verbose                 -t
--ed                      --version                 -u
--force                   --version-control         -v
--forward                 -B                        -z
--fuzz                    -D                        Brodsky/
--get                     -E                        FM2000
--help                    -F                        ICONS/
--ifdef                   -N                        addrbook.d/
--ignore-whitespace       -R                        bin/
--input                   -S                        dead.letter
--no-backup-if-mismatch   -T                        dikz/
--normal                  -V                        fnt/
--output                  -Y                        mail/
--patch-root              -Z                        observe/
--posix                   -b                        save/
--prefix                  -c                        src/
--quiet                   -d                        test/
--quoting-style           -e                        tmp/
--reject-file             -f                        xxxx/
--remove-empty-files      -g

/andrej

Re: Size of select listing?

[Oliver Kiddle]

Andrej Borsenkow wrote:

> patch TAB
> 
> creates a select listing longer than screen size. At least, if I do it in a
> directory with ~ 15 files.
> 
> bor@itsrm2:~%> patch
> --backup                  --reverse                 -i
> --backup-if-mismatch      --set-time                -l
> . . .
> --quoting-style           -e                        tmp/
> --reject-file             -f                        xxxx/
> --remove-empty-files      -g

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. I
don't like the mixed file and option lists as above 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. The way I've always written
compctls (and the way the compctl-examples are done), is that 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. In
summary, I think that patch <tab> should list and complete file names
only, patch -<tab> should complete options and should display them
without the initial '-' and patch --<tab> should list only the long
options (unless we have filenames starting with '-') without displaying
'--' before every option. This way of doing things would reduce the
number of things which get listed.

I'd write a patch for _arguments/_long_options for this but I suspect
people might disagree with me and because they have both become quite
complicated so it'd take me a while.

Oliver Kiddle

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

Re: Size of select listing?

[Peter Stephenson]

Oliver Kiddle wrote:
> 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.

Look at the option_prefix configuration key in zshcompsys(1).

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56100 Pisa, Italy

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.

RE: Size of select listing?

[Andrej Borsenkow]

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

It does relate to screen size. I repeat - if I have a "Really Large List" of
matches, zsh asks me if I want to see them before printing. But if I have a
list, that is only "a bit longer" than screen size, it is printed.

So, my question is - why zsh prints list that is longer than screen size? Is it
intentional? I call it a bug. Either I need a way to scroll list (or to page
through it one screen at a time) - or zsh must ask me before printing it.

/andrej

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