From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by coral.primenet.com.au (8.7.5/8.7.3) with ESMTP id FAA01913 for ; Wed, 28 Aug 1996 05:56:24 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id PAA26786; Tue, 27 Aug 1996 15:56:19 -0400 (EDT) Resent-Date: Tue, 27 Aug 1996 15:56:19 -0400 (EDT) Message-Id: <199608271953.PAA25249@redwood.skiles.gatech.edu> X-Mailer: exmh version 1.6.6 3/24/96 To: zsh-workers@math.gatech.edu Subject: future of zsh In-reply-to: Your message of "Tue, 27 Aug 1996 21:25:28 +0200." <199608271925.VAA08321@bolyai.cs.elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Aug 1996 15:53:06 -0400 From: Richard Coleman Resent-Message-ID: <"IQJxF3.0.PY6.YBr8o"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/2084 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@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