Re: PATCH: new _print and thoughts on _arguments mutexes

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Oliver Kiddle wrote:

> This patch adds a new completion for _print and adds a couple more
> commands to _nothing. Does anyone know how I can determine if there is a
> currently active coprocess so the -p flag is only offered if it can be
> used.

I can't think of a way... if it turns out that it is impossible, maybe 
we (c|sh)ould fake `/dev/fd/coproc-{in,out}'?

> ...
> 
> Writing this completion, I came across a characteristic of _arguments
> which I think should be changed (if it can be fairly easily). The -R
> option is unusual in that it can be used after lots of the other options
> but only -n and -e can be used after it. This is easy to handle - the
> list of options which can't appear after -R are in the mutex list for -R
> but -R is not in the mutex list for all the other options. Unfortunately
> this doesn't work when you move the cursor before -R on the line:
> 
> cd -  -R<tab>
>     ^cursor here
> 
> will only complete the -n option. This is fine in that it does what the
> documentation says it does but we have a certain amount of redundancy in
> our _arguments syntax. If two arguments are mutually exclusive, we have
> to put each of them in each others mutex list so in effect we are
> duplicating the information that they are mutually exclusive. If we
> redefined the mutex lists to mean that they listed arguments which could
> not follow this argument then we could handle situations like print's
> -R.

That's easy to implement. No patch yet, I'll have a look at the other
_arguments stuff mentioned by you some time ago and the one mentioned
by Tanaka at the weekend.

> One final question: was _vars_eq intended to be a general function to be
> used from other completion functions? In other words, when I come to do
> _arguments style completion for typeset, should I modify _vars_eq or
> call it from a new _typeset?

No, _vars_eq was only intended for use with commands that get
variables or variable assignments. Use it. Weird name, though. My
fault, no doubt.

> How do I persuade cvs diff to give me something for new files? I've
> manually added a diff against /dev/null so you may have to separate it
> to apply the patch (or wait until I commit it).

I'd like to know that, too...

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx