Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: future of zsh
- X-seq: zsh-workers 2086
- From: Zoltan Hidvegi <hzoli@xxxxxxxxxx>
- To: coleman@xxxxxxxxxxxxxxx (Richard Coleman)
- Subject: Re: future of zsh
- Date: Tue, 27 Aug 1996 22:23:47 +0200 (MET DST)
- Cc: zsh-workers@xxxxxxxxxxxxxxx
- In-reply-to: <199608271953.PAA25249@xxxxxxxxxxxxxxxxxxxxxxxxx> 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
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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author