* Re: return code of _arguments
@ 2001-03-26 9:21 Sven Wischnowsky
2001-03-26 14:05 ` Oliver Kiddle
0 siblings, 1 reply; 4+ messages in thread
From: Sven Wischnowsky @ 2001-03-26 9:21 UTC (permalink / raw)
To: zsh-workers
Bart Schaefer wrote:
> On Mar 23, 11:33pm, Oliver Kiddle wrote:
> } Subject: return code of _arguments
> }
> } If my understanding is correct the test [[ $? = 300 ]] after _arguments
> } is going to be equivalent to the test [[ -n $state ]]?
>
> I suggested getting rid of the 300 return code once before.
Hm. We could of course add an option to _arguments to make it return
300 when needed. Non-_arguments-wrappers would call it without the
option...
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: return code of _arguments
2001-03-26 9:21 return code of _arguments Sven Wischnowsky
@ 2001-03-26 14:05 ` Oliver Kiddle
0 siblings, 0 replies; 4+ messages in thread
From: Oliver Kiddle @ 2001-03-26 14:05 UTC (permalink / raw)
To: zsh-workers
--- Sven Wischnowsky <wischnow@informatik.hu-berlin.de> wrote: >
> > On Mar 23, 11:33pm, Oliver Kiddle wrote:
> > } If my understanding is correct the test [[ $? = 300 ]] after
> _arguments
> > } is going to be equivalent to the test [[ -n $state ]]?
I gather that the reason I was wrong there is because $state may
contain something before the call to _arguments (an may not be a local)
and without ->state actions, it would be unchanged.
> Hm. We could of course add an option to _arguments to make it return
> 300 when needed. Non-_arguments-wrappers would call it without the
> option...
I think doing something like this would definitely be a good idea. I
think it is better if the functions for user commands (like _bzip2) are
kept simpler at the expense of things like _arguments and _x_arguments.
I suppose the latter will also need to take the new option and when
called without it will need to use compstate[nmatches].
Oliver
____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie
^ permalink raw reply [flat|nested] 4+ messages in thread
* return code of _arguments
@ 2001-03-23 23:33 Oliver Kiddle
2001-03-24 16:37 ` Bart Schaefer
0 siblings, 1 reply; 4+ messages in thread
From: Oliver Kiddle @ 2001-03-23 23:33 UTC (permalink / raw)
To: Zsh workers
In a couple of instances, I realised that despite _complete finding
matches, the _approximate completer was also being given a go. For
example, bzip2 --k<tab> was offering loads of other things besides
--keep.
The basic cause of this is that _bzip2 doesn't handle return codes of
300 from _arguments. This is a problem for any completion function
which uses a state machine action for any non-option spec (the *:... or
1:... specs) and is followed by && or || to determine the return code.
There are a good few.
If my understanding is correct the test [[ $? = 300 ]] after _arguments
is going to be equivalent to the test [[ -n $state ]]? The test appears
only twice - in _x_arguments and _xt_arguments so maybe this 300
feature isn't as useful as first anticipated by Sven. I therefore
wonder that the best thing to do here wouldn't be to remove the 300
return-code feature of _arguments and adapt the two functions which
rely on it.
Once we've resolved this, I'll rethink through the return codes for
many of the functions. In cases like _bzip2, the && return 0 is
actually quite handy because you need to use '--' first to compress
files whose names start with a -. If one of the options matched, the
current word must start with a - so we are better not to be completing
files. That said, I'd bet there are a number of functions where return
0 is used but we should be doing ret=0 -- especially any written by me
I fear.
Oliver
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: return code of _arguments
2001-03-23 23:33 Oliver Kiddle
@ 2001-03-24 16:37 ` Bart Schaefer
0 siblings, 0 replies; 4+ messages in thread
From: Bart Schaefer @ 2001-03-24 16:37 UTC (permalink / raw)
To: Oliver Kiddle, Zsh workers
On Mar 23, 11:33pm, Oliver Kiddle wrote:
} Subject: return code of _arguments
}
} If my understanding is correct the test [[ $? = 300 ]] after _arguments
} is going to be equivalent to the test [[ -n $state ]]?
I suggested getting rid of the 300 return code once before.
Back in zsh-workers/12475, Sven wrote:
>
> No. The special return value is used by the wrappers around _arguments
> such as _x_arguments. And there we *need* to be able to distinguish
> the cases (to keep the special parameters from being reset).
>
> And anyway, the problem is not with the return value, since, as you
> observed, we use $state for tests anyway. The problem is that with
> ->state actions _arguments may have to generate matches (the options)
> and it can't know if the caller adds more matches. What I wanted is an
> easier way for calling functions to distinguish this from the case
> where _arguments generates real matches (by executing one of the other
> forms for actions). Currently this can be done by relying on the
> return value to test if `real' matches (not only options) were
> generated and then use $state to find out if a state has to be handled
> and *there* use $compstate[nmatches] to find out if options were
> completed. If needed, and it is seldom needed because in most cases
> the state doesn't have to be handled in a loop.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2001-03-26 14:05 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-03-26 9:21 return code of _arguments Sven Wischnowsky
2001-03-26 14:05 ` Oliver Kiddle
-- strict thread matches above, loose matches on Subject: below --
2001-03-23 23:33 Oliver Kiddle
2001-03-24 16:37 ` Bart Schaefer
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).