some notes on 3.1.6

some notes on 3.1.6

[Zefram]

Wow.

Those are some fairly dramatic changes in 3.1.6.  I very much like
the approximate completion.  Congratulations to all concerned.

Some problems/potential changes I note in passing:

----

When an autoloaded special parameter is not actually defined by the module
loaded, there is no error message (compare "autoload failed" when it's
a builtin).  Instead, the parameter remains in an autoloadable state.
Try, for example:

	zmodload -ap example foobar
	foobar=1
	foobar=2
	foobar=3

----

When autoloading of condition codes fails, there is a similar problem.
There is an error message ("unrecognized condition"), but the condition
code remains autoloadable.

----

Now that we have autoloadable parameters, the watch system (the watch
parameter and the log builtin) can be relegated to a loadable module
like sched.

getopts can probably go the same way.

----

We ought to have autoloadable builtin widgets (for the deltochar module).
This could be implemented in user space by defining the widget as a
user-defined widget which, when run, loads the module in question and
then calls the new definition.

----

#compdef -k tagged functions, when processed by compinit, add key bindings
to the current main keymap.  Unfortunately, all the key bindings are
appropriate for emacs, and cause real trouble if the vi key bindings
are being used.

----

zftp really ought to allow more than one concurrent open session.
One could refer to sessions by name, with a mechanism to generate unique
names; commands that don't specify which session they apply to use a
default name (either actually fixed or taken from a parameter).

----

The new parameters and condition codes in the example module are not
documented.

----

After doing a "compinit" (on a shell started with zsh -f), completion
of parameter names now adds a space suffix when it shouldn't (e.g.,
during menu completion).  AUTO_PARAM_SLASH then has no effect, and suffix
removal is partly broken; for example, after completing a parameter name
in braces, a typed close brace doesn't remove anything.

----

The documentation says that the parameter module provides a parameter
called "command".  Actually it's "commands".

----

-zefram (regular access but no spare time, for the moment)

Re: some notes on 3.1.6

[Peter Stephenson]

Zefram wrote:
> zftp really ought to allow more than one concurrent open session.
> One could refer to sessions by name, with a mechanism to generate unique
> names; commands that don't specify which session they apply to use a
> default name (either actually fixed or taken from a parameter).

I thought about this when I wrote zftp, but it didn't seem a particularly
necessary feature right at the start.  I think it ought to be done in such
a way that the $ZFTP_* parameters work without extra complexity.  Hence I
would probably implement it by having `zftp session SESS' change to a new
or existing session SESS (default `default') and set (or unset) the
parameters appropriately.  This will also allow the zf* function suite to
work completely transparently with multiple sessions without having to add
extra arguments.  It's no hassle writing something to switch sessions for
one command, that can be done with a function which saves and restores the
session.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

zftp suggestion (was Re: some notes on 3.1.6)

[Oliver Kiddle]

Zefram wrote:
> zftp really ought to allow more than one concurrent open session.

That would be really useful. If that is implemented, what would be
really useful is a combined get/put command which gets a file on one ftp
session and puts it on another. This would be useful in cases where
there is limited disc space on the machine I'm on and a firewall
prevents me doing a single ftp.

Oliver Kiddle