* Re: Completion listing of command options ( Re: Size of select listing?)
@ 1999-09-13 8:34 Sven Wischnowsky
0 siblings, 0 replies; 5+ messages in thread
From: Sven Wischnowsky @ 1999-09-13 8:34 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Completion listing of command options ( Re: Size of select listing?)
@ 1999-09-14 9:56 Sven Wischnowsky
0 siblings, 0 replies; 5+ messages in thread
From: Sven Wischnowsky @ 1999-09-14 9:56 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Completion listing of command options ( Re: Size of select listing?)
@ 1999-09-13 13:45 Sven Wischnowsky
0 siblings, 0 replies; 5+ messages in thread
From: Sven Wischnowsky @ 1999-09-13 13:45 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Completion listing of command options ( Re: Size of select listing?)
1999-09-10 15:23 ` Oliver Kiddle
1999-09-10 15:45 ` Completion listing of command options (Re: Size of select listing?) Bart Schaefer
@ 1999-09-10 15:54 ` Andrej Borsenkow
1 sibling, 0 replies; 5+ messages in thread
From: Andrej Borsenkow @ 1999-09-10 15:54 UTC (permalink / raw)
To: Oliver Kiddle, ZSH workers mailing list
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Completion listing of command options (Re: Size of select listing?)
1999-09-10 15:23 ` Oliver Kiddle
@ 1999-09-10 15:45 ` Bart Schaefer
1999-09-10 15:54 ` Completion listing of command options ( " Andrej Borsenkow
1 sibling, 0 replies; 5+ messages in thread
From: Bart Schaefer @ 1999-09-10 15:45 UTC (permalink / raw)
To: ZSH workers mailing list
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~1999-09-14 9:57 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-09-13 8:34 Completion listing of command options ( Re: Size of select listing?) Sven Wischnowsky
-- strict thread matches above, loose matches on Subject: below --
1999-09-14 9:56 Sven Wischnowsky
1999-09-13 13:45 Sven Wischnowsky
1999-09-09 15:19 Size of select listing? Andrej Borsenkow
1999-09-10 15:23 ` Oliver Kiddle
1999-09-10 15:45 ` Completion listing of command options (Re: Size of select listing?) Bart Schaefer
1999-09-10 15:54 ` Completion listing of command options ( " Andrej Borsenkow
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).