Re: about beta11

[Zefram <A.Main@xxxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----

>I'll probably have to change some of the options to compctl to do
>this.  Currently -d tells compctl to expect names of disabled commands.
>This won't be good enough anymore.  What would be better would be
>to make -d a modifier that says require the DISABLED flag on whatever
>you are completing.  Something like:
>
>compctl -dF      # complete the name of disable shell functions
>compctl -eF      # complete the name of enabled shell functions
>compctl -F       # complete the name of shell functions

Hmm, more modifiers.  Time to roll out one of my nascent compctl
ideas...  compctl options that control what is completed to fall into
two completely distinct categories, with no overlap.  The options -P,
- -S, -q and -Q; and -d and -e if you do as you suggest; and possibly
others if the compctl options are ever reviewed in the interests of
orthogonality; all modify a basic choice of what to complete to (which
is decided by most of the other options).

At present, any single completion (one command, or one XOR'ed
completion, or one branch of an extended completion) can only have one
set of basic options and one set of modifiers, and all the modifiers
apply to all the basic options.  It would increase flexibility
enormously if one could do an *inclusive* OR of completions, which
could if necessary be nested inside an exclusive OR, and so on.  For
example, if = separates OR'ed sets of flags:

compctl -dF = -oeB gronk

(assuming -d and -e act as you describe above) makes completion of
arguments to gronk(1) include options, enabled builtins and disabled
functions.  Note that there is already an implicit OR'ing of options.
IMO, the lack of an explicit OR syntax is what has lead to the current
situation of compctl having separate options for, for example, (a)
variables, (b) arrays, (c) scalars, (d) integer variables, (e)
non-exported parameters, (f) exported parameters, (g) readonly
variables, and (h) special parameters.  If there were an explicit OR
syntax, most of these options could become modifiers in nature, and
have an AND-type effect individually.

I see this type of syntax being even more useful if different
completions can have different -S suffixes, particularly if completion
functions can return a list of suffixes in addition to the list of
completions.  Is this a reasonable feature to add at some point?

>Also, I can (trivially) add it so that disable -a, enable -a will
>disable/enable aliases.  I didn't do this yet, since I wasn't sure
>if this would be useful.  It would only be a two line change to the
>code I currently have.  I might add it just for completeness sake.

Do it.  It's a stupendously crufty bit of orthogonality.

[re the named directory table]
>I was afraid something like that would be the case.  I guess we'll just
>have to leave this that way.

Actually, it might be worth temporarily rewriting finddir() to do a
linear search, in order to do some performance tests.  (It would have
to go through the entire table, storing the index of the most
preferable name found so far.)  The comments in it indicate that the
current binary search, which is followed by a linear search of usually
a great deal of the table anyway, doesn't make much difference.  The
caching of the last response (code already there) may actually make the
performance loss acceptable, even on a system with several thousand
users.

If you're too busy to try this, I'll copy the code across to the other
computer system here (Solaris 2.4, NIS, about eleven thousand users)
and make a comparison.

>                                    One change I've been looking at
>is changing the syntax of hash to more closely match that of the
>builtin alias.  So to add a named directory, you would use
>
>hash -d foo=bar
>
>rather than
>
>hash -d foo bar
>
>This way I will probably be able to combine the code for alias and
>hash like I've already done for unalias and unhash.  It also allows
>you to add multiple named directories by
>
>hash -d foo1=bar1 foo2=bar2
>
>It also makes it more consistent with the syntax of other zsh builtins.

Looks good.  In the light of this new syntax, I'd like to draw everyone's attention to the output format of hash -d.  It currently give output like

~cs126=/tmp
~dain=/home/dain
~=/home/zefram

Should it have the ~ there?  When I wrote the code I rationalised that
hash alone gives output of the form <command>=<path>, which I
interpreted as meaning <command> is translated into <path>.  Hence the
hash -d output ~<name>=<path>, meaning that ~<name> is translated into
<path>.  Should it instead output <name>=<path>, to match the setting
syntax?

Another oddity I just noticed: if I do

% hash -d '' /foo/bar

then finddir() says that ~ can only be used if I'm under /foo/bar, but
"echo ~" still gives my real home directory.  This doesn't happen with
~user (i.e. "echo ~user" gives my bogus path).  What *should* the
semantics be?

>Hmm...  My current feelings are that since we already have type/which/
>whence, that another alias for this seems excessive.

Not really.  We have type from sh/bash, whence from ksh, which from
csh, so it makes perfect sense to provide the tcsh command as well.
And it's only one line in the builtin table, and doesn't clash with any
real commands.

 -zefram

-----BEGIN PGP SIGNATURE-----
Version: 2.6.i

iQBVAgUBMAdzRWWJ8JfKi+e9AQH9eAIAqj3YPDFHDo7AfC5EaLDg0ls2YioTnPgh
iQOzDTgiQpRXOV1ONsIA5LvNvy2e0CTcjrx+tDDxELQE0Nh/2kv3jg==
=srNg
-----END PGP SIGNATURE-----