Re: about beta11

[Richard Coleman <coleman@xxxxxxxxxxxxxxx>]

> >One of the things I'm doing for beta11 is splitting the hash table
> >cmdnamtab into three separate tables for shell functions, builtins,
> >and external commands.  This fixes some of the weird command name
> >space problems that would have been difficult to fix any other way.
> 
> Does this mean that command completion, equals substitution and the
> hash builtin will all agree on whether a command exists?

I've just started looking at the completion code changes necessary.
I hope to keep all this consistent.  Most likely, these new changes
will actually make things much more consistent than they currently are.
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

> >1) enable/disable by default will only work on builtin functions
> >2) enable -f, disable -f will enable/disable shell functions
> >3) enable -r, disable -r will enable/disable reserved words
> 
> Great.  Atm, one can disable functions, but not reserved words or
> external commands (though they will be added to the disable list), but
> can't enable anything other than a builtin.  It's all rather silly.

Yes, the way things were before Peter split the reserved words table
was that to remove a reserved word, you used unalias (reserved words
and aliases shared a hash table).  Unfortunately you couldn't re-enable
it after that.  Also, using disable on a shell function actually caused
it to be removed so that it couldn't be re-enable it either.  With the
changes I've made, disable/enable only adds/removes the DISABLED flag.
Nothing gets removed from the hash table.  Therefore you can easily
re-enable it.  To remove something you use unhash (or one of its aliases).

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.

> >Is there anything preventing us from using a hash table for this
> >rather than a linked list (which is what it currently uses)?
> 
> 'fraid so.  The named directory table is sorted.  (Actually, I'm pretty
> sure it's a big array, not a linked list, hence the occasional comment
> that calls it a hash table even though there's no real hashing
> involved.)  It has to be sorted so that %~ in prompts gives the
> shortest possible name for the directory.  That capability isn't used
> anywhere else, but unless you have a brilliant way to do that with a
> hash table then hash -d will have to stay as an exception.

I was afraid something like that would be the case.  I guess we'll just
have to leave this that way.

> I think it might make the builtins a bit neater if hash/rehash -d, and
> unhash -d if it gets added (it should be), were handled by separate
> functions from the normal bin_{,re,un}hash.  There would be a statement
> "if(ops['d']) return dir_hash(whatever)" at the beginning of each
> bin_*hash function, and the rest of the function would be the normal
> hash table stuff.

I was planning on adding unhash -d.  I don't know if I'll get to it
this version.  I'll probably move all the name directory code into
a separate function like you suggest.

> It *might* also be good to merge bin_hash and bin_rehash, and have
> rehash merely as an alias to hash -r.  It should be documented that way
> anyway.

I've been planning on this for awhile now.  I started working on this
yesterday but didn't finish it.  Unfortunately this doesn't save as
much code as the previous changes.  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.

> Speaking of builtin aliases, is "where" (whence -ca) going to appear at
> some point?  I sent a one-line patch for it, and Zoltan's release has
> that patch plus documentation.  It is genuinely useful to have a
> builtin that does a whence -a (I alias it).  And has anyone considered
> adding the csh "glob" command, which would be something like "print
>  -rN"?  (Less useful, but it occurred to me as being appropriate.  Does
> anyone use glob these days?)

Hmm...  My current feelings are that since we already have type/which/
whence, that another alias for this seems excessive.  But if enough
people thinks it is useful, I could add it.  I always just use
"type -a" myself.

> At this point I was going to request that the remaining disgusting bits
> of inconsistent ! quoting be fixed, as Zoltan's release contains a
> patch to make it just a normal character.  That was certainly the case
> a few betas ago.  But then I tested, just to make sure:

Yes, there are many patches for little things like this that I've
been ignoring lately.  I've just been so preoccupied which fixing
some of the underlying code, that I've sorta ignored some of the
more user-visible bug fixes.  I haven't forgotten about them.  Once
I finish all these changes to the various hash table and add some
of the other big patches (such as Peter's changes to history.c and
some of the patches of Zoltan's I've been procrastinating about),
I'll start adding many of these small patches.  Hopefully we soon
can begin the final shakedown necessary before we go to production
release.

Also, since this letter is already too long I might as well mention
that the next production release will be zsh-3.00 rather than zsh-2.7.
There have been so many changes that I think a new major version
number is justified.  I realize that this breaks the practice of using
even version numbers for development and odd version numbers for
production releases.  I would like to either reverse this (use odd
for development, even for production) which would make us match the
way Linux does version numbers, or just drop this practice altogether.

I've said before that I want the next production release to be the
best zsh ever.  Since it will have a new major version number, I'm
even more determined for this to be the case.

rc