future of zsh

[Richard Coleman <coleman@math.gatech.edu>]

> And about colorizes lists: first there will be a zsh-3.0.1 release.  It
> will definitely not be added before that.  And in zsh-3.1 we have to find
> out a portable way to use dynamically loadable modules.  After that anyone
> can write a plug-in for zsh and can implement any feature he wants.  But
> such features should not blow up zsh.  It would be a good idea to better
> modularise the existing zsh code, make a few things optional (fo rexample
> zle and completion).  I do not know how much is the ovehead caused by a big
> executable.  When zsh is used as a scipt interpreter on a demand-paged
> system only the parts necessary run a script will be loaded so it may not
> give any real improvement.

Aaahhh... time for the inevitable "future of zsh" discusion.  We haven't
had one of those in a while.  But before everyone sends there "We need to
add feature X!" requests, I would like to say a few things.

I think Zoltan's idea of loadable modules is a good idea.  This
would give us the infrastructure to add lots of features, without
bloating the code any more.  Hopefully, some of the current functionality
could be moved out of the zsh core, and into modules such as this.  But
before everyone starts rejoicing at this idea, realize it is non-trivial
and will require work, and will greatly complicate parts of the code.

As to zle and completion, it would be great if this could be moved
to a module, or to a seperate library.  I had similar ideas when I was
maintainer.  Unfortunately, zle and completion use so many of the
internal data structures (just about all of them actually), this would be
very difficult.  I believe a better idea is to move some of the
internals of the completion code into the hash table code.  This was
part of the motivation when I rewrote the hash table code.  Essentially
each object would know how to complete itself.  Again, this is non-trivial,
but a worthwhile goal.  I believe that a general mechanism for hash table
searching would simplify both the completion code and the spell checking
code.

zsh 3.0 is a great increase in modularity over previous version, as well
as being much more maintainable (take a look at the zsh 2.5.03 code if
you don't believe me).  But I believe this is a process that should
continue.  In particular, the exec.c code is still somewhat of a mess.  If
I find some time, I will probably do some work on this myself.

Also, I wanted to say I think zsh has made great progress over the last
couple of years.  Thanks to all who worked on it.

rc