Re: some notes on 3.1.6

Re: some notes on 3.1.6

[Sven Wischnowsky]

Peter Stephenson wrote:

> Sven Wischnowsky wrote:
> > .. but requiring that all
> > widgets they want to bind have to be defined by the user first is a
> > bit too much, I think
> 
> But they don't have to be defined first.
> 
> % bindkey '^[OS' foobar
> % bindkey '^[OR' whatever
> % foobar() { whatever() { LBUFFER="${LBUFFER}x" }; zle -N whatever; }
> % zle -N foobar
> 
> works as expected (S-F12 then S-F11 on my keyboard adds an 'x', without
> `whatever' being defined when I bound it.  Unless I've missed the point.

Oh. Stupid me... I thought I had tried this once and it didn't
work. Seems like I made some other mistake then. Sorry.

> > The
> > AUTO_PARAM_SLASH problem was already mentioned (the problem is that we 
> > made such parameter completions be handled almost completely in shell
> > code, so we would have to add the slashes there, too, which is a bit
> > slowish).
> 
> I've actually been doing the following and it's not so bad (it doesn't
> actually use the option).  Maybe it could just blindly use the option, as
> long as we mention the fact that it may be slow.  Maybe there's a way of
> enhancing compadd to get it to work easily: some form of the -f option
> which takes an array argument giving to the actual files to test instead
> of using the normal arguments?

Ah. I hadn't thought of something comparable to `-f'. That just says
`this is a filename, do the file-tests if needed (in do_single())'. We
could add an option that says `this is a parameter name, do the
file-tests for it if AUTO_PARAM_SLASH is set'. We would have to get
all the prefix/suffix stuff right then (and define how they work in
that case), but it should be possible... I just don't know if this is
probably to special a case.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: some notes on 3.1.6

[Peter Stephenson]

Sven Wischnowsky wrote:
> .. but requiring that all
> widgets they want to bind have to be defined by the user first is a
> bit too much, I think

But they don't have to be defined first.

% bindkey '^[OS' foobar
% bindkey '^[OR' whatever
% foobar() { whatever() { LBUFFER="${LBUFFER}x" }; zle -N whatever; }
% zle -N foobar

works as expected (S-F12 then S-F11 on my keyboard adds an 'x', without
`whatever' being defined when I bound it.  Unless I've missed the point.

> The
> AUTO_PARAM_SLASH problem was already mentioned (the problem is that we 
> made such parameter completions be handled almost completely in shell
> code, so we would have to add the slashes there, too, which is a bit
> slowish).

I've actually been doing the following and it's not so bad (it doesn't
actually use the option).  Maybe it could just blindly use the option, as
long as we mention the fact that it may be slow.  Maybe there's a way of
enhancing compadd to get it to work easily: some form of the -f option
which takes an array argument giving to the actual files to test instead
of using the normal arguments?


#compdef -parameter-

setopt localoptions extendedglob

local p pms dirlist normlist
#pms=(${${${${(f)"$(typeset +)"}:#*local *\=*}##* }:/^$PREFIX*$SUFFIX})
_parameters -O pms

for p in $pms; do
  if [[ -d ${(P)p} ]]; then
    dirlist=($dirlist $p)
  else
    normlist=($normlist $p)
  fi
done

(( #dirlist )) && compadd -S / -q $dirlist
(( #normlist )) && compadd $normlist

-- 
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

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

Re: some notes on 3.1.6

[Sven Wischnowsky]

[Hi, Zefram!]

Zefram wrote:

> 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

Oops. This should be fixed by the patch below.

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

The patch should also fix this.

> 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.

Yes, maybe.

> 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.

I've wished that, too (menu-select!). Hadn't thought about doing it in 
user-code, and we can't do it in C because all the widget stuff is
itself in a module (unless we add something that lets modules define
things that can be autoloaded -- which is probably not possible or
extremly hard or something).

However, one of the things I really want to do before the next
official stable release is to change the auto-autoloading stuff we now 
have for completion to something like a generic package system -- with 
autoloading, dumping and configuration which can then also be used for 
widgets (and I was already thinking about widgets and probably about
zftp). Zsh packages could then contain a module and some shell code
and the package system should ensure that all this can be easily used
-- doing most things automatically.

> #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.

The widget and keymap stuff is on our list anyway. Since widget shell
functions have already become more useful (and no doubt we will make
them even more powerful) we've been discussing all this lately
anyway. Especially the keymap stuff should be changed to allow real
overlay keymaps, to allow shell-function widgets to define local
keymaps more easily (NB: this is the place where I don't like the
concept of a widget: if a autoloadable shell function widget which is
not yet loaded uses a overlay keymap, users should be able to bind
keys in that map without first loading the function; I think requiring 
that they first define the keymap may be ok, but requiring that all
widgets they want to bind have to be defined by the user first is a
bit too much, I think), to change function like menu-select and
execute-named-command to use overlay maps with `pseudo' widgets (like
`menu-select-next'), and other things I may have forgotten now.

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

Right, but it is documented in the zsh-development-guide (which
really, really should be moved into another directory -- Etc?). That's 
the place where someone else forgot to describe all the basic module
stuff so that I had to describe it, too (ahem ;-).

> 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.

7448 at least should fix the space-with-menu problem. The
AUTO_PARAM_SLASH problem was already mentioned (the problem is that we 
made such parameter completions be handled almost completely in shell
code, so we would have to add the slashes there, too, which is a bit
slowish). The suffix removal is just the way I want it -- and noone
complained so far (btw. after a brace-parameter the closing brace
removes the space for me (well, ok, it removes the `} ' and then
inserts the closing brace)).

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

This is hidden in 7448, too.


Bye
 Sven

diff -u os/module.c Src/module.c
--- os/module.c	Mon Aug  9 10:40:42 1999
+++ Src/module.c	Thu Aug 19 12:57:14 1999
@@ -1228,8 +1228,10 @@
 		load_module(p->module);
 		f = 0;
 		p = NULL;
-	    } else
-		break;
+	    } else {
+		deleteconddef(p);
+		return NULL;
+	    }
 	} else
 #endif
 	    break;
diff -u os/params.c Src/params.c
--- os/params.c	Mon Aug  9 10:40:42 1999
+++ Src/params.c	Thu Aug 19 12:51:30 1999
@@ -292,6 +292,10 @@
 	if (!load_module(mn))
 	    return NULL;
 	hn = gethashnode2(ht, nam);
+	if (((Param) hn) == pm) {
+	    pm->flags &= ~PM_AUTOLOAD;
+	    zwarnnam(nam, "autoload failed", NULL, 0);
+	}
     }
     return hn;
 }

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

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)