* Re: Completion TODO (was: pws-11)
@ 1999-03-09 8:02 Sven Wischnowsky
0 siblings, 0 replies; 3+ messages in thread
From: Sven Wischnowsky @ 1999-03-09 8:02 UTC (permalink / raw)
To: zsh-workers
Peter Stephenson wrote:
> Sven Wischnowsky wrote:
> > The current state: condition codes, some of them modifying. Saving and
> > restoring of the special parameters is done automatically on function
> > entry and exit (and nowhere else).
> > The problems are: modifying condition codes are considered a bad thing
> > and saving/restoring has to be done explicitly.
>
> I haven't followed what's wrong with having the parameters restored
> automatically unless compstate[restore] is altered.
I was alluding to the restoring inside a function when one has
multiple tests.
> If the modification of the parameters is simply to be removed from [[-style
> tests, then I still think a builtin is the best way of handling it.
> `compset -i 3' ignores three more characters from $PREFIX, or
> whatever. This could allow tests with side effects, like `compset -I
> <pattern>' to ignore a pattern at the head of $PREFIX if it matches,
> or whatever. Then you also could have e.g. `compset -n 2 -1', narrow
> to words 2 to -1 (same as shifting words and decrementing CURRENT),
> `compset -N "start_pat" "optional_end_pat"', narrow to the range of
> words between the patterns with the end pattern optional. If it's
> much more complicated than that, I can't imagine I would use it much.
I had forgotten to include this in the list of suggestions (although,
I think, it was the first suggestion ever made).
The builtin should have a return value usable for `if compset ...; then'
as a `side effect', right?
> I'm not really enthusiastic about more subscripting hieroglyphics.
;-)
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 3+ messages in thread
* Completion TODO (was: pws-11)
@ 1999-03-08 12:52 Sven Wischnowsky
1999-03-08 17:54 ` Peter Stephenson
0 siblings, 1 reply; 3+ messages in thread
From: Sven Wischnowsky @ 1999-03-08 12:52 UTC (permalink / raw)
To: zsh-workers
Peter Stephenson wrote:
> Status report on completion: the parts changed this week (complist is now
> called compgen, many of the variables have been absorbed into the
> associative array $compstate) are probably near their final form --- at
> least, until someone other than the four of us tries it out and finds they
> don't like it. However, Sven still plans to add some other bits,
> e.g. controlling the re-display of an existing completion list.
I was planning to do this anyway and having to leave early today so
that I won't be able to do some real work anyway...
Here is the list of things for the new completion stuff we might want
to think about, add, or modify, collected in one place. There may be
others things, but these are the ones, I could think of.
Testing (and saving/restoring of `PREFIX'...):
The current state: condition codes, some of them modifying. Saving and
restoring of the special parameters is done automatically on function
entry and exit (and nowhere else).
The problems are: modifying condition codes are considered a bad thing
and saving/restoring has to be done explicitly.
Suggestions made:
- Bart's special associative array. Let's call it `comptest', then one
could do: `comptest[(r)string(-1,foo)]' to get the index of the last
`foo' in `PREFIX'. Thus we would have:
index=$comptest[(r)string(-1,foo)]
if (( index )); then
IPREFIX="$IPREFIX$PREFIX[1,index]"
PREFIX="$PREFIX[index+1,-1]"
and probably:
subarr=("${(@)comptest[(r)range(-exec,\;)]}")
if (( $#subarr )); then
words=("$subarr[@]")
The only problems I see with this are implementation issues (haven't
tested how difficult to implement this would be yet) and the fact
that this looks a bit weird (that may be caused by not being used to
it, though).
- Andrej suggested keeping the condition codes and changing them to
not modify `PREFIX' and friends directly. Instead they would set
other special parameters (say, `INDEX', `FIRST', `LAST'). With this:
if [[ -string -1 foo ]]; then
IPREFIX="$IPREFIX$PREFIX[1,INDEX]"
PREFIX="$PREFIX[INDEX+1,-1]"
and:
if [[ -between -exec \; ]]; then
words=("${(@)words[FIRST,LAST]}")
Obviously this has the advantage of being very short and readable
(and could be made more readable by providing a function that does
the modification and then calls the match-generating function(s) or
builtins).
The only thing I don't like about it (once I have been convinced
that condition codes should be non-modifying), is that they again
modify some global state -- it's only in different parameters.
- I suggested using functions in math environments or using only the
already existing parameter expansion magic, e.g. (if combined with
the condition codes we have, turned into non-modifying ones again):
if [[ -string str ]]; then
IPREFIX="${IPREFIX}${PREFIX[1,string(str)-1]}"
PREFIX="${PREFIX[string(str),-1]}"
if [[ -between s1 s2 ]]; then
words=("${(@)words[rangebeg(s1,s2),rangeend(s1,s2)]}")
or (with parameter-magic):
if [[ -string num str ]]; then
index=$PREFIX[(in:num:)str]
IPREFIX="$IPREFIX$PREFIX[1,index]"
PREFIX="$PREFIX[index+1,-1]"
if [[ -between s1 s2 ]]; then
i1=$words[(Ib:CURRENT:)s1]
i2=$words[(ib:i1:)s2]
words=("${(@)words[i1+1,i2-1]}")
Since I think I'm the only one who likes them, I won't comment any
further...
- Apart from the rest it was suggested (by Bart) to have functions
that do the tests, modify the parameters and then call other
functions to generate the matches. Of course, this could already be
implemented. In most cases, however, functions that do all the tests
on the arguments or the current word themselves and then call the
match-generating functions or builtins directly somehow feel more
natural (and probably are more readable, although that depends on
the way the testing functions would be implemented).
With this we wouldn't need more support for saving/restoring the
parameters. I'd like to point out, that this isn't needed very often
anyway (only if the parameters are used again after the test
succeded) and that the only clean solution would be a syntactic
construct that restores the state of the parameters -- and
implementing that is out of the question, I think.
So, I think we don't need to imlpement anything new for this in C.
We could implement some testing functions if we feel the need (and
with the `words' array we have now this would be easier than before)
and otherwise let the user do the modification by hand so that he
knows that he has to restore them afterwards.
Widget-return value:
Andrej suggested using the return value of the widget for
`continuing' when called from `compctl -i'. I.e. if it returns
non-zero, no other `compctl's are tried (or the other way round). I'd
prefer to do this with another key to `compstate' and use the return
value of completion widgets the same way they are used for normal
widgets -- which is still to be defined (and implemented).
More `compstate':
There are some things I'd like to give access to using `compstate' (or
probably another associative array), namely:
- Control for beeping. I'm not to sure about this one because I don't
use beeps, so anyone who relies on it should comment if he likes to
have control over it (and how).
- Access to pre-existing sets of matches, i.e. be able to find out:
- if there is a valid set of matches
- if we are in a menucompletion
- which match is currently inserted in the line (I'd like to be able
to give information about the group this match is in and which of
the matches is on the line, and which groups are in the set, and ...)
together with this: a way to say: `keep the old set and insert
match ... from it' -- maybe we find a way to combine this with
`compstate[insert]'
and this together with `accept the current match and continue with
match ... after it' -- for things like accept-and-menu-complete
- if the set of matches is shown (`listed')
Access to matches:
Finally there may be interest in giving access to all the information
we have about the current set of matches (the old one or the one newly
built). Since there is so many information, we can't easily do this
with a special parameter (it is not only one string per match). Maybe
a builtin would be better, modeled after the `stat'-module, so that
the builtin could put all the information for one match into an
associative array. With this builtin we probably could also add a way
to modify the existing matches (in a controlled way).
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Completion TODO (was: pws-11)
1999-03-08 12:52 Sven Wischnowsky
@ 1999-03-08 17:54 ` Peter Stephenson
0 siblings, 0 replies; 3+ messages in thread
From: Peter Stephenson @ 1999-03-08 17:54 UTC (permalink / raw)
To: Zsh hackers list
Sven Wischnowsky wrote:
> The current state: condition codes, some of them modifying. Saving and
> restoring of the special parameters is done automatically on function
> entry and exit (and nowhere else).
> The problems are: modifying condition codes are considered a bad thing
> and saving/restoring has to be done explicitly.
I haven't followed what's wrong with having the parameters restored
automatically unless compstate[restore] is altered.
If the modification of the parameters is simply to be removed from [[-style
tests, then I still think a builtin is the best way of handling it.
`compset -i 3' ignores three more characters from $PREFIX, or
whatever. This could allow tests with side effects, like `compset -I
<pattern>' to ignore a pattern at the head of $PREFIX if it matches,
or whatever. Then you also could have e.g. `compset -n 2 -1', narrow
to words 2 to -1 (same as shifting words and decrementing CURRENT),
`compset -N "start_pat" "optional_end_pat"', narrow to the range of
words between the patterns with the end pattern optional. If it's
much more complicated than that, I can't imagine I would use it much.
I'm not really enthusiastic about more subscripting hieroglyphics.
--
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~1999-03-09 8:03 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-03-09 8:02 Completion TODO (was: pws-11) Sven Wischnowsky
-- strict thread matches above, loose matches on Subject: below --
1999-03-08 12:52 Sven Wischnowsky
1999-03-08 17:54 ` Peter Stephenson
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).