PATCH: new _print and thoughts on _arguments mutexes

PATCH: new _print and thoughts on _arguments mutexes

[Oliver Kiddle]

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 find out which file-descriptors are currently active using
/dev/fd/n tests but I haven't bothered because it wouldn't be much use
unless I could create meaningful descriptions of the file/pipe that the
file-descriptor points to.

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.

To implement it, the list of mutexes of all arguments to the left of the
cursor would be considered and for all arguments to the right of the
cursor, any arguments which have them in their mutex list should not be
offered for completion.

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?

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).

Oliver Kiddle

Index: .distfiles
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Builtins/.distfiles,v
retrieving revision 1.2
diff -r1.2 .distfiles
5,7c5,7
<     _hash _kill _limits _nothing _pids _popd _sched _set _setopt _source
<     _stat _trap _unhash _unsetopt _vars _vars_eq _wait _which _zcompile
<     _zftp _zle _zmodload _zpty _signals _zstyle
---
>     _hash _kill _limits _nothing _pids _popd _print _sched _set _setopt
>     _source _stat _trap _unhash _unsetopt _vars _vars_eq _wait _which
>     _zcompile _zftp _zle _zmodload _zpty _signals _zstyle
Index: _nothing
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Builtins/_nothing,v
retrieving revision 1.2
diff -r1.2 _nothing
1c1
< #compdef true false log times whoami
---
> #compdef true false log times clear logname whoami
--- /dev/null	Wed Mar  3 17:20:11 1999
+++ Completion/Builtins/_print	Wed Apr 19 15:27:23 2000
@@ -0,0 +1,26 @@
+#compdef print
+
+local state expl line eflag
+
+# -e flag available only after -R 
+eflag="${words[1,CURRENT-1][(r)-*R*]:+-e[enable escapes]}"
+
+_arguments -C -s \
+  '-r[ignore escape conventions of echo]' \
+  '(-r -b -m -s -l -N -o -O -i -c -u -p -z -D -P)-R[emulate BSD echo (no escapes, -n & -e flags only)]' \
+  '-b[recognise bindkey escape sequences]' \
+  '-m[remove arguments matching specified pattern]' \
+  '(-u -p -z)-s[place results in the history list]' \
+  '(-N -c)-n[do not add a newline to the result]' \
+  '(-N -c)-l[print arguments separated by newlines]' \
+  '(-n -l -c)-N[print arguments separated and terminated by nulls]' \
+  '(-O)-o[sort arguments in ascending order]' \
+  '(-o)-O[sort arguments in descending order]' \
+  '-i[case-insensitive sorting]' \
+  '(-n -l -N)-c[print arguments in columns]' \
+  '(-s -p -z)-u+[specify file-descriptor to print arguments to]:file-descritor' \
+  '(-s -u -z)-p[print arguments to input of coprocess]' \
+  '(-s -p -u)-z[push arguments onto editing buffer stack]' \
+  '-D[substitute any arguments which are named directories using ~ notation]' \
+  '-P[perform prompt expansion]' \
+  $eflag '*:default:_default'

Re: PATCH: new _print and thoughts on _arguments mutexes

[Zefram]

Oliver Kiddle wrote:
>                      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 suppose you could play with (:>&p) type stuff.

>      I can find out which file-descriptors are currently active using
>/dev/fd/n tests but I haven't bothered because it wouldn't be much use
>unless I could create meaningful descriptions of the file/pipe that the
>file-descriptor points to.

Under Linux, readlink(2) on /proc/<foo>/fd/<n> is scarily useful.

-zefram

Re: PATCH: new _print and thoughts on _arguments mutexes

[Oliver Kiddle]

Zefram wrote:

> I suppose you could play with (:>&p) type stuff.

That seems to work nicely, thanks.

> >      I can find out which file-descriptors are currently active using
> >/dev/fd/n tests but I haven't bothered because it wouldn't be much use
> >unless I could create meaningful descriptions of the file/pipe that the
> >file-descriptor points to.
> 
> Under Linux, readlink(2) on /proc/<foo>/fd/<n> is scarily useful.

That is useful. On the debian system here, there is a readlink(1). Is
that common on Linux?

When I look in /proc/$$/fd after creating a coprocess, I get something
like:
lrwx------    1 kiddleo  kiddleo        64 Apr 19 16:35 0 -> /dev/pts/0
lrwx------    1 kiddleo  kiddleo        64 Apr 19 16:35 1 -> /dev/pts/0
lrwx------    1 kiddleo  kiddleo        64 Apr 19 16:35 10 -> /dev/pts/0
lr-x------    1 kiddleo  kiddleo        64 Apr 19 16:35 11 ->
pipe:[111653]
l-wx------    1 kiddleo  kiddleo        64 Apr 19 16:35 14 ->
pipe:[111654]
lrwx------    1 kiddleo  kiddleo        64 Apr 19 16:35 2 -> /dev/pts/0
l-wx------    1 kiddleo  kiddleo        64 Apr 19 16:35 4 ->
pipe:[111654]

Does anyone know what the significance of the 111654 and 111653 is. Can
I convert them into anything useful like the PID of the coprocess. 

I'll look at doing an _file_descriptors this evening. Which directory
should it go in - Builtins? I suppose it'll only be useful for _print,
_read and _redirect?

Oliver

Re: PATCH: new _print and thoughts on _arguments mutexes

[Zefram]

Oliver Kiddle wrote:
>That is useful. On the debian system here, there is a readlink(1). Is
>that common on Linux?

I don't see one on Red Hat.  But there's this really neat shell that has a
`stat' command...

>lrwx------    1 kiddleo  kiddleo        64 Apr 19 16:35 10 -> /dev/pts/0

Fantastic, isn't it.  I just saw this full-pathname behaviour for the
first time today; last time I had looked (2.0, I think) it just gave
device and inode numbers.

>lr-x------    1 kiddleo  kiddleo        64 Apr 19 16:35 11 -> pipe:[111653]
>
>Does anyone know what the significance of the 111654 and 111653 is.

Different from all other pipes?

>I convert them into anything useful like the PID of the coprocess. 

No way.

-zefram

Re: PATCH: new _print and thoughts on _arguments mutexes

[Trond Eivind Glomsrød]

Zefram <zefram@fysh.org> writes:

> Oliver Kiddle wrote:
> >That is useful. On the debian system here, there is a readlink(1). Is
> >that common on Linux?
> 
> I don't see one on Red Hat. 

It's included with tetex:

[teg@hoser teg]$ whatis readlink
readlink             (1)  - print contents of symbolic link
readlink             (2)  - read value of a symbolic link
[teg@hoser teg]$ which readlink
/usr/bin/readlink
[teg@hoser teg]$ rpm -qf /usr/bin/readlink 
tetex-1.0.6-11
[teg@hoser teg$
-- 
Trond Eivind Glomsrød
Red Hat, Inc.

Re: PATCH: new _print and thoughts on _arguments mutexes

[Sven Wischnowsky]

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@informatik.hu-berlin.de