Re: A peep into the future.

[Zefram <A.Main@xxxxxxxxxxxxxxxxx>]

>1. Fully programmable aliasing (matching regexps, replacing selections).

Not really likely for 3.0.  Maybe in 4.0 there could be an execcmd
function that gets called before each command is executed.

>2. Regular Expression filename generation.

We're pretty close to that, though not using the usual regexp syntax.
It would be nice to add an option to use ksh's glob characters instead
of zsh's.

>3. Programmable key bindings (a key could be bound to a sequence of
>   actions, so now you can do things like: dynamic paren matching,
>   real-time indentation, etc.)  Some primitive functions have been
>   provided  (a small (but complete) subset of the EDITING functions 
>   of elisp).

It's been discussed a bit.  I have some ideas of what would be
required, but I don't expect anything to happen in this direction
before 3.0.

>4. Safer redirections: e.g.
>	if you say "foo > Important_file", zsh checks to see if there
>	is anything on the stdout of foo, if not (say foo is
>	non-existent), zsh leaves the Imp_file as it is.

That's probably better done using >>(command) redirection.  It could be
done as a global alias.

>5. setopt POSIX_COMPLIANT now makes zsh what?

We should have an "emulate posix" mode, that turns on all POSIX
features.  We have a long way to go before zsh is fully POSIX
conformant.

>6. Hierarchical option settings.  E.g. unsetopt zle automatically
>   unsetopts's the options dependant on its being set.  It itself also
>   is an option.  It's there to make understanding the plethora of
>   options easier for new users.

That's rather pointless.  If an option has no effect due to the state
of another option, I'd rather it stayed the way it is, rather than get
unset.

>zsh 4.0:
>
>1.  wzsh (windowing zsh) is now available.  Also, zsh now has colour
>    and menu capabilities on text only terminals.  

It has colour capabilities to some extent: you can put colour sequences
into prompts quite easily.  I don't see any advantage in having zsh use
windows in any way.

>2.  mount/umount is a shell builtin which simulates working with
>    virtual filesystems e.g. ftpfs, tarfs, libfs, memfs.

I'd like to see quite a lot of basic administration commands added as
optional builtins, to make a sysadmin's shell.  There would be a
configuration option to strip out ZLE, and to add builtins for cp, mv,
rm, link, sln and so on.  That sort of shell would be very useful if
statically linked and stashed away in /sbin.  Virtual filesystems, of
course, should be done in the kernel (for example, userfs under
Linux).

>3.  zsh can now byte-code its scripts.

I never tried this, but I think it used to be possible, if you just put
the token control characters into a script.  Now zsh handles those
properly, metafying them.  But an option to bypass metafication and
tokenisation would potentially be fairly usable and easy to implement.

>4.  zsh now supports dynamic files.  If a file has a specific magic no,
>    it can be handled like a normal file of the *output* of that file.

Another virtual filesystem?

>zsh 10.0:
>
>OS_TYPE is a shell variables which can be changed.  zsh simulates the
>given OS.  Everything is a shell builtin.

I have a vision of being able to assign to $ZSH_VERSION, to make zsh
emulate an arbitrary version of itself.  It would be rather silly.

-zefram