From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gatech.edu (gatech.edu [130.207.244.244]) by werple.mira.net.au (8.6.12/8.6.9) with SMTP id SAA10093 for ; Sat, 15 Jul 1995 18:08:33 +1000 Received: from math (math.skiles.gatech.edu) by gatech.edu with SMTP id AA09071 (5.65c/Gatech-10.0-IDA for ); Sat, 15 Jul 1995 04:08:45 -0400 Received: by math (5.x/SMI-SVR4) id AA16280; Sat, 15 Jul 1995 04:05:08 -0400 Resent-Date: Sat, 15 Jul 1995 08:51:13 +0100 (BST) Old-Return-Path: From: Zefram Message-Id: <7227.199507150806@stone.dcs.warwick.ac.uk> Subject: Re: about beta11 To: coleman@math.gatech.edu (Richard Coleman) Date: Sat, 15 Jul 1995 08:51:13 +0100 (BST) In-Reply-To: <9507150628.AA09777@redwood.skiles.gatech.edu> from "Richard Coleman" at Jul 15, 95 02:28:40 am X-Loop: zefram@dcs.warwick.ac.uk X-Stardate: [-31]5981.63 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: zefram@dcs.warwick.ac.uk Resent-Message-Id: <"QFvom1.0.E-3.pQt1m"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/212 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu -----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 =, which I interpreted as meaning is translated into . Hence the hash -d output ~=, meaning that ~ is translated into . Should it instead output =, 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-----