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 GAA01972 for ; Wed, 28 Aug 1996 06:23:38 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id QAA27311; Tue, 27 Aug 1996 16:24:55 -0400 (EDT) Resent-Date: Tue, 27 Aug 1996 16:24:55 -0400 (EDT) From: Zoltan Hidvegi Message-Id: <199608272023.WAA08708@bolyai.cs.elte.hu> Subject: Re: future of zsh To: coleman@math.gatech.edu (Richard Coleman) Date: Tue, 27 Aug 1996 22:23:47 +0200 (MET DST) Cc: zsh-workers@math.gatech.edu In-Reply-To: <199608271953.PAA25249@redwood.skiles.gatech.edu> from Richard Coleman at "Aug 27, 96 03:53:06 pm" Organization: Dept. of Comp. Sci., Eotvos University, Budapest, Hungary Phone: (36 1)2669833 ext: 2667, home phone: (36 1) 2752368 X-Mailer: ELM [version 2.4ME+ PL16 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"MRfZy1.0.fg6.Ncr8o"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/2086 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Richard wrote: > 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 That's not a problem. A mudule can use any zsh internal function/variable etc. The important thing is that the main code should not use anything from the module. The main part of zsh does not use zle + completion as I know except the read builtin and the compctl builtin. The later should probably be moved into a separate file. Adding loadable modules on an elf system is trivial (I have already done that on linux) and it is probably not difficult on other systems which support dlopen/dlclose/dlsym. On systems modules cannot be statically linked to zsh as a compile-time option. The difficult part is to write configure tests about how to compile and link dynamic modules and figure out a consistent interface. > 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. Yes, it may be doable. The zsh code gradually becomes more and more object-orientated. > 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 Oh, I believe it. I've seen parts of it. > 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. That would be great. When you do that do not forget to use a profiler. Sometimes I think I understand most of exec.c but then I wake up. Zoltan