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: Size of select listing?

[Sven Wischnowsky]

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

Could you investigate further? This works well for me -- with
`LISTMAX=0', of course.

Have you set `LISTMAX' to something else? Is your LINES correct?

(Hm, yes, I think you made sure, I just can't think of other reasons...)

Bye
 Sven


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