Re: PATCH: collist v2.0

Re: PATCH: collist v2.0

[Sven Wischnowsky]

I wrote:

> Here is an improved version:

Sorry, the change to `compinit' wasn't right (because collist may not
be loaded and then menu-select is unknown).
For now I'll just take it out -- there isn't a way to find out if a
widget is defined, is there? And we can't just look at the output of
`zmodload' because it doesn't report linked-in modules.

Also, a fix for `_path_files' slipped in which I meant to send
separately but...

Bye
 Sven

diff -u oc/Core/compinit Completion/Core/compinit
--- oc/Core/compinit	Tue Jun 22 10:44:19 1999
+++ Completion/Core/compinit	Tue Jun 22 10:44:28 1999
@@ -343,7 +343,7 @@
 # Rebind the standard widgets
 for _i_line in complete-word delete-char-or-list expand-or-complete \
   expand-or-complete-prefix list-choices menu-complete \
-  menu-expand-or-complete reverse-menu-complete menu-select; do
+  menu-expand-or-complete reverse-menu-complete; do
   zle -C $_i_line .$_i_line _main_complete
 done
 

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

RE: PATCH: collist v2.0

[Andrej Borsenkow]

>
> Hm. Autoloaded parameters are intended for modules that *define*
> parameters instead of just using them. But then, complist does nothing
> if `ZLS_COLO(|U)RS' isn't set. Hm. Maybe.
>

Thinking more about it - no. It is O.K. for ZLS_COLORS to define used colors.
But I think, it complist should not depend on it being set.

If you have to test parameter to decide, if run color list/menu selection - does
it matter, which parameter? I prefer that completion configuration be kept in
one place - and this is compconfig. what about

compconf list_handler=color
compconf menu_handler=select

This has an advantage, that if new handler is ever added, it can easily be
activated. And it can even be used to autoload modules  ...

/andrej

Re: PATCH: collist v2.0

[Sven Wischnowsky]

Bart Schaefer wrote:

> }   [...] Could someone who actually uses coulured lists
> }   please check if the default values are correct? (They look very bad.)
> 
> I agree that they're pretty icky.  Here's what I get (no LS_COLORS set,
> ZLS_COLORS set but empty):
> 
> 	ls --color	Zsh
> 	----------	----------
> 	blue		green		directories
> 	green		magenta		executables
> 	cyan		cyan		symlinks
> 	magenta		goldenrod?	sockets
> 	yellow		reverse-blue	devices
> 
> I get this even if I move /etc/DIR_COLORS out of the way.

...and some of the bold, right? But these colours don't look very good 
either. The patch below gives complist what I get as the default for
`ls --colour'. Dunno if they are better...

> (Aren't you glad that I didn't let you use the name "complist" before?)

;-) I was thinking about this, too.

> I just rebuilt with all the latest patches, and now I can't get menu-select
> to start.  I did 
>     bindkey \\t menu-select
> and confirmed with bindkey -L that tab was indeed re-bound, but when I try
>     zsh% ls <TAB>
> it simply starts normal menu completion.  Oh, I see -- menu-select depends
> on ZLS_COLORS being set!  That seems odd.

Maybe, but what if you have a terminal that doesn't understand the
codes used for highlighting? Setting `ZLS_COLO(|U)RS' is a bit like
saying: `I know that my terminal can understand these codes'.


Andrej Borsenkow wrote:

> Collist still is not autoloaded. As I understand, xmods.conf adds to the list of
> autoloaded modules ... but collist does not have anything that can trigger it's
> load. May be, ZLS_* should be added to autoparams for collist? This would
> trigger loading as soon as anything from ZLS_* is defined.

Hm. Autoloaded parameters are intended for modules that *define*
parameters instead of just using them. But then, complist does nothing 
if `ZLS_COLO(|U)RS' isn't set. Hm. Maybe.

Bye
 Sven

diff -u os/Zle/complist.c Src/Zle/complist.c
--- os/Zle/complist.c	Wed Jun 23 10:33:37 1999
+++ Src/Zle/complist.c	Wed Jun 23 10:35:31 1999
@@ -67,7 +67,7 @@
 /* Default values. */
 
 static char *defcols[] = {
-    "0", "0", "32", "36", "31", "33", "44;37", "44;37", "35", NULL,
+    "0", "0", "1;34", "1;36", "33", "1;35", "1;33", "1;33", "1;32", NULL,
     "\033[", "m", NULL, "7"
 };
 

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

Re: PATCH: collist v2.0

[Bart Schaefer]

On Jun 22, 10:25am, Sven Wischnowsky wrote:
} Subject: PATCH: collist v2.0
}
} - Keys used:
}   - accept-line and send-break will leave selection. There is visual
}     feedback because then there is no highlighted match any more.

This is probably what was confusing me -- I tried accept-line but the
hightlight was still in the listing so I didn't realize I'd escaped.

}   [...] Could someone who actually uses coulured lists
}   please check if the default values are correct? (They look very bad.)

I agree that they're pretty icky.  Here's what I get (no LS_COLORS set,
ZLS_COLORS set but empty):

	ls --color	Zsh
	----------	----------
	blue		green		directories
	green		magenta		executables
	cyan		cyan		symlinks
	magenta		goldenrod?	sockets
	yellow		reverse-blue	devices

I get this even if I move /etc/DIR_COLORS out of the way.

} - If you read the manual or the collist.c file you'll notice that I've 
}   changed `collist' to `complist'

I changed collistmatches() to complistmatches() as well.

(Aren't you glad that I didn't let you use the name "complist" before?)

} > Finally, I wanted to mention that I got it into a state where the highlight
} > was not visible -- I could only tell where I was because the word on the
} > command line kept changing as I pressed the arrow keys.  Eventually I think
} > I crossed back over the word that had been offered as the initial choice
} > (which was in the middle of the list somewhere -- I think it restarted an
} > old menu completion after I thought I'd broken out) and then the hightlight
} > came back.
} 
} Maybe part of this is: when you start a normal menu completion and then
} invoke menu-select and then leave it again, you are in menu completion 
} again. That's intentional. Otherwise I haven't seen such a behavior,
} could you try with the patch?

No, I never started a normal menu-completion.  As best I recall, I started
a menu-select, left it somehow without selecting anything (possibly by ^G)
and then immediately attempted the same menu-select again.

I just rebuilt with all the latest patches, and now I can't get menu-select
to start.  I did 
    bindkey \\t menu-select
and confirmed with bindkey -L that tab was indeed re-bound, but when I try
    zsh% ls <TAB>
it simply starts normal menu completion.  Oh, I see -- menu-select depends
on ZLS_COLORS being set!  That seems odd.

Anyway, at the moment I can't manage to repeat the highlighting problem.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

RE: PATCH: collist v2.0

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> > Here is an improved version:
> >
> > - No more highlighting in normal menu completion.
> 
> Is it still possible to switch hihglighting on if desired?

Hm, no. I could add it again, using a different ZLS_COLOURS-capability 
-- should I? (Didn't someone say that this is irritating?)

> > - There is now another hook which is caught by the module which allows
> >   one to replace menu-completion with selection by setting the
> >   parameter `ZLS_SELECT'. If it is set, you get into menu-selection
> >   whenever menucompletion would be used.
> >   This is ugly, it should be an option...
> 
> This is basically what I thought about last evening. Completion has three
> largely independent parts - building list of matches, displaying list and
> selecting match. Completion widgets provide hook for the first; as I uderstand,
> with complist Sven added hooks to display lists. It is natural to have hook to
> select match. I don't think, the parameter is ugly. But I think, it is better
> fitted in compconfig/compstate - user defined key to install menu hook.
> 'compconf menu_handler=menu_select" or like.

The hooks I added are C-hooks, not visible to shell code. So
supporting a configuration key for this is a completely different
thing, and completely independent.

It would be easy to add something like

  if [[ -n "$compconfig[menu_select]" ]]; then
    ZLS_SELECT=''
  else
    unset ZLS_SELECT
  fi

to _main_complete, or, probably better

  [[ -n "$compconfig[menu_select]" ]] && ZLS_SELECT=''

in a completer named _menu_select or something.

> >     There is a problem: I had to strcmp() the name of the widget read
> >     with strings like `complete-word' to allow this to work with new
> >     style completion widgets. This is ugly -- and a good reason to
> >     implement local keymaps.
> 
> I don't like it. Users are free to redefine key bindings - I can well imagine
> somebody, having complete keymap to mimic TED, Pico or anything he likes. And
> then suddenly he finds, that he needs completely different keys to navigate in
> e.g. menu selection.

This is why I said that it's a good reason for local keymaps. In this
case I would create a local keymap by copying the one currently being
used and change some of the keys that should be expected to work
(cursor, return, tab, probably undo). We could avoid that copying if
we were able to define sparse keymaps and use them as override-maps
(i.e. if one of the keys defined in the sparse map is used, you get
the definition from it, otherwise you get the definition of the normal 
keymap). With that creating and installing such a local keymap would
be very cheap.

> This is the second idea - what about additional hook in key dispatcher? In this
> way module could have it's private widget table to do the work. The handler
> should return indication, if widget was consumed by it and when it decides, it
> should exit, it simply removes the handler. Alternatively, module could install
> it's own widget table while it's active - but having the function would probably
> spare building the whole table. In this way you won't have any (additional)
> overhead at all.

Functions like menu-select (or execute-named-command and so on) do the 
key-dispatch directly, they don't use the global key-loop. In these
cases I really think that local keymaps are the easier way.
Nonetheless the key-loop is one of the places where I would like to
have hooks for modules (remember me saying that there are other places 
where we might want to add hooks?).
And another thing: when we started this programming widget discussion
you suggested a command that reads something from the minibuffer
(which, of course, we don't have either, we only have a statusline
which is used by some functions to display something prompt-like --
functions with their own command loops of course). I would like to
have that, too, but I would prefer to bring `zle' and friends to a
state where we can implement that in shell code. That should give us
more freedom for configuration, I think (and it would also be a good
test for the widget-programming stuff).

> I have nothing against additional keys mapped - but if user has mapped key
> sequence to backward-char, he probably expects it to work as such in all places?

See above.

> > - There shouldn't be any flickering any more when moving around in the
> >   menu.
> 
> There is. Running under dtterm with empty ZLS_COLORS and having large (ca.
> screenfull) list. Moving around gives very visible flickering.

Grunz. Yes, you're right, but unless someone modifies collistmatches() 
so that it only redisplays the old and the new line where the
highlighted match was/is, that can't be helped (and such a change is
not entirely trivial). I was referring to xterm which is faster.


Bye
 Sven


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

RE: PATCH: collist v2.0

[Andrej Borsenkow]

First of all, yes, this is incredible. It beats any other command line interface
I've seen so far.

>
> Here is an improved version:
>
> - No more highlighting in normal menu completion.

Is it still possible to switch hihglighting on if desired?

> - There is now another hook which is caught by the module which allows
>   one to replace menu-completion with selection by setting the
>   parameter `ZLS_SELECT'. If it is set, you get into menu-selection
>   whenever menucompletion would be used.
>   This is ugly, it should be an option...

This is basically what I thought about last evening. Completion has three
largely independent parts - building list of matches, displaying list and
selecting match. Completion widgets provide hook for the first; as I uderstand,
with complist Sven added hooks to display lists. It is natural to have hook to
select match. I don't think, the parameter is ugly. But I think, it is better
fitted in compconfig/compstate - user defined key to install menu hook.
'compconf menu_handler=menu_select" or like.

>     There is a problem: I had to strcmp() the name of the widget read
>     with strings like `complete-word' to allow this to work with new
>     style completion widgets. This is ugly -- and a good reason to
>     implement local keymaps.

I don't like it. Users are free to redefine key bindings - I can well imagine
somebody, having complete keymap to mimic TED, Pico or anything he likes. And
then suddenly he finds, that he needs completely different keys to navigate in
e.g. menu selection.

This is the second idea - what about additional hook in key dispatcher? In this
way module could have it's private widget table to do the work. The handler
should return indication, if widget was consumed by it and when it decides, it
should exit, it simply removes the handler. Alternatively, module could install
it's own widget table while it's active - but having the function would probably
spare building the whole table. In this way you won't have any (additional)
overhead at all.

I have nothing against additional keys mapped - but if user has mapped key
sequence to backward-char, he probably expects it to work as such in all places?

> - There shouldn't be any flickering any more when moving around in the
>   menu.

There is. Running under dtterm with empty ZLS_COLORS and having large (ca.
screenfull) list. Moving around gives very visible flickering.

> - One problem with the default colours: I've taken the values from the
>   manual, but without setting LS_* my `ls --colour' seems to use
>   different values. Could someone who actually uses coulured lists
>   please check if the default values are correct? (They look very bad.)

At least the color for executables is bad.

/andrej

P.S. Thank you, Sven!

Re: PATCH: collist v2.0

[Sven Wischnowsky]

Peter Stephenson wrote:

> It's hard to know what to do.  You don't expect to be able to set an option
> only when a module is loaded, so I don't think we can have module-dependent
> options.  But zle related options are in the main shell even if zle isn't
> loaded.  Maybe we just have to make it an option (menuselect, obviously)
> anyway and make a bigger effort to load complist when necessary, so you
> would get an error from completion the first time if it's not available.

We can make modules autoloadable on options -- triggered by
(|un)setopt. But then there is still the problem with local options
and all that...


> - some new options will list all modules or builtin modules.  This is
>   probably better but the problem is that with a non-dynamically-linked
>   shell you always get no output from running `zmodload' on its own which
>   is a little Zen-like.  Maybe it should return status 1 in that case as a
>   test for dynamic loading, but status 0 when the list includes builtin
>   modules.

I'd vote for using the exit status and even let these list-options
accept optional arguments. With arguments they just check if the
modules named are loaded (or can be loaded?).

> And I still think the zle command needs the ability to list builtin
> widgets, too.

Definitely, yes -- see 6775.

> One other thing:  I'm still a bit worried about the way undo works, where
> the first time nothing happens if there isn't a suffix to undo.  It's fine
> if there is a suffix which you can undo separately, but I'd be tempted to
> make it skip over that if it does nothing.  That would make it harder if
> you used undo in programming, however, but I don't think people do.

Maybe an option to undo saying if you want to skip `invisible' undos
or not?

> I've done this and I'll try and get pws-$((N+1)) out at the end of the
> week, particularly since I'm busy next week.  There were some other minor
> changes:  a tt(no) in the manual was missing a close parenthesis, some
> dependencies for mod_complist.yo needed adding in the Makefile, a nodref
> referred to `The complist module' instead of `The complist Module'.  These
> are appended below, but it assmues the name changes.

Oh, yes. I forgot to test-make the docs, sorry.

And thanks!

Bye
 Sven


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

Re: PATCH: collist v2.0

[Sven Wischnowsky]

Peter Stephenson wrote:

> - go somewhere with too many files
> - type `echo <menu-select key>'  (without the quotes, of course)
> - answer n to the message
> - the first menucompletion match is inserted; hit TAB to go to the next

Forgot to clear showinglist...

Btw.: If you start with menu-select you can't `continue'
menu-completion with a different widget. That's caused by the test at
zle_tricky.c:809 that was changed when we were working on _oldlist.

However, you can continue menu-completion by repeatedly invoking
menu-select (it degenerates into normal menu-completion when it
doesn't get its list).

Bye
 Sven

diff -u os/Zle/collist.c Src/Zle/collist.c
--- os/Zle/collist.c	Tue Jun 22 11:51:28 1999
+++ Src/Zle/collist.c	Tue Jun 22 11:52:03 1999
@@ -292,9 +292,10 @@
     int mc, ml = 0, cc, hasm = 0;
     struct listcols col;
 
-    if (minfo.asked == 2)
+    if (minfo.asked == 2) {
+	showinglist = 0;
 	return (noselect = 1);
-
+    }
     getcols(&col);
 
     /* Set the cursor below the prompt. */

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

Re: PATCH: collist v2.0

[Peter Stephenson]

Sven Wischnowsky wrote:
> - The behavior when asking if the list should be shown should be ok
>   now (I hope).

Just as soon as I finished the last prompt I had a problem.  With
menucomplete set,

- go somewhere with too many files
- type `echo <menu-select key>'  (without the quotes, of course)
- answer n to the message
- the first menucompletion match is inserted; hit TAB to go to the next
- I don't know if this is significant, but the match was a directory
  with a slash; when I hit TAB, the next one wasn't a directory but
  appeared with a space after it
- at that point everything freezes up and after some seconds the shell
  exits with the message `killed', maybe due to memory exhaustion?

I almost reproduced the behaviour with zsh -f, menucomplete, and the
standard set of new completions: in this case, the directory (it was
Builtins) stayed in place, tab started menucompletion in the subdirectory,
and again the shell froze and then exited after the first item.

-- 
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: PATCH: collist v2.0

[Peter Stephenson]

Sven Wischnowsky wrote:
> Here is an improved version:

Magic

> - There is now another hook which is caught by the module which allows 
>   one to replace menu-completion with selection by setting the
>   parameter `ZLS_SELECT'. If it is set, you get into menu-selection
>   whenever menucompletion would be used.
>   This is ugly, it should be an option...

It's hard to know what to do.  You don't expect to be able to set an option
only when a module is loaded, so I don't think we can have module-dependent
options.  But zle related options are in the main shell even if zle isn't
loaded.  Maybe we just have to make it an option (menuselect, obviously)
anyway and make a bigger effort to load complist when necessary, so you
would get an error from completion the first time if it's not available.

Also, we should definitely change zmodload to be able to list builtin
modules, which means adding a reduced version of zmodload even for shells
without dynamic linking.  It's getting too inconvenient not to have the
information available in functions.  Two possibilities are

- zmodload lists all modules, whether builtin or not, but marks the builtin
  one differently -- this makes it harder if you want to check $(zmodload)
- some new options will list all modules or builtin modules.  This is
  probably better but the problem is that with a non-dynamically-linked
  shell you always get no output from running `zmodload' on its own which
  is a little Zen-like.  Maybe it should return status 1 in that case as a
  test for dynamic loading, but status 0 when the list includes builtin
  modules.

And I still think the zle command needs the ability to list builtin
widgets, too.

One other thing:  I'm still a bit worried about the way undo works, where
the first time nothing happens if there isn't a suffix to undo.  It's fine
if there is a suffix which you can undo separately, but I'd be tempted to
make it skip over that if it does nothing.  That would make it harder if
you used undo in programming, however, but I don't think people do.

> - If you read the manual or the collist.c file you'll notice that I've 
>   changed `collist' to `complist' because the more interesting part
>   doesn't have anything to do with colouring lists. But of course I
>   can't build a patch that renames your files.
>   Peter, could you rename collist.{c,mdd}, mod_collist.yo, and change
>   the xmods.conf entry? (Including changing the names of the
>   setup/cleanup-functions in collist.c?) Should I send you a patch for 
>   as much as I can?

I've done this and I'll try and get pws-$((N+1)) out at the end of the
week, particularly since I'm busy next week.  There were some other minor
changes:  a tt(no) in the manual was missing a close parenthesis, some
dependencies for mod_complist.yo needed adding in the Makefile, a nodref
referred to `The complist module' instead of `The complist Module'.  These
are appended below, but it assmues the name changes.

--- Doc/Makefile.in~	Thu Jun 10 17:28:45 1999
+++ Doc/Makefile.in	Tue Jun 22 10:16:22 1999
@@ -56,9 +56,9 @@
 Zsh/filelist.yo Zsh/files.yo Zsh/func.yo Zsh/grammar.yo Zsh/guide.yo \
 Zsh/index.yo Zsh/intro.yo Zsh/invoke.yo Zsh/jobs.yo Zsh/metafaq.yo \
 Zsh/modules.yo Zsh/mod_cap.yo Zsh/compwid.yo Zsh/compsys.yo \
-Zsh/mod_clone.yo Zsh/mod_comp1.yo Zsh/mod_compctl.yo Zsh/mod_deltochar.yo \
-Zsh/mod_example.yo Zsh/mod_files.yo Zsh/mod_mapfile.yo Zsh/mod_stat.yo \
-Zsh/mod_zle.yo Zsh/options.yo \
+Zsh/mod_clone.yo Zsh/mod_comp1.yo Zsh/mod_compctl.yo Zsh/mod_complist.yo \
+Zsh/mod_deltochar.yo Zsh/mod_example.yo Zsh/mod_files.yo \
+Zsh/mod_mapfile.yo Zsh/mod_stat.yo Zsh/mod_zle.yo Zsh/options.yo \
 Zsh/params.yo Zsh/prompt.yo Zsh/redirect.yo Zsh/restricted.yo \
 Zsh/seealso.yo Zsh/zftpsys.yo Zsh/zle.yo
 
@@ -131,9 +131,10 @@
            Zsh/prompt.yo Zsh/restricted.yo
 
 zshmodules.1: Zsh/modules.yo Zsh/mod_cap.yo Zsh/mod_clone.yo \
-              Zsh/mod_comp1.yo Zsh/mod_compctl.yo Zsh/mod_deltochar.yo \
-              Zsh/mod_example.yo Zsh/mod_files.yo Zsh/mod_mapfile.yo \
-              Zsh/mod_sched.yo Zsh/mod_stat.yo Zsh/mod_zftp.yo Zsh/mod_zle.yo
+              Zsh/mod_comp1.yo Zsh/mod_complist.yo Zsh/mod_compctl.yo \
+              Zsh/mod_deltochar.yo Zsh/mod_example.yo Zsh/mod_files.yo \
+              Zsh/mod_mapfile.yo Zsh/mod_sched.yo Zsh/mod_stat.yo \
+              Zsh/mod_zftp.yo Zsh/mod_zle.yo
 
 zshoptions.1: Zsh/options.yo
 
--- Doc/Zsh/compsys.yo~	Tue Jun 22 10:02:48 1999
+++ Doc/Zsh/compsys.yo	Tue Jun 22 10:18:24 1999
@@ -168,7 +168,7 @@
 tt(menu-expand-or-complete), or tt(reverse-menu-complete). If the
 tt(complist) module is loaded (see
 ifzman(zmanref(zshmodules))\
-ifnzman(noderef(The complist module))\
+ifnzman(noderef(The complist Module))\
 ), the tt(menu-select) widget can be used, too.
 
 The widget is then bound to all the var(key-sequences) given, if any: when
--- Doc/Zsh/mod_complist.yo~	Tue Jun 22 10:02:48 1999
+++ Doc/Zsh/mod_complist.yo	Tue Jun 22 10:14:05 1999
@@ -65,7 +65,7 @@
 for the file-type or the last matching specification with a `tt(*)',
 the value of tt(rc), the string to display for the match itself, and
 then the value of tt(ec) if that is defined or the values of tt(lc),
-tt(no, and tt(rc) if tt(ec) is not defined.
+tt(no), and tt(rc) if tt(ec) is not defined.
 
 The default values are ISO 6429 (ANSI) compliant and can be used on
 vt100 compatible terminals such as tt(xterm)s. On monochrome terminals


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

PATCH: collist v2.0

[Sven Wischnowsky]

Here is an improved version:

- No more highlighting in normal menu completion.
- There is now another hook which is caught by the module which allows 
  one to replace menu-completion with selection by setting the
  parameter `ZLS_SELECT'. If it is set, you get into menu-selection
  whenever menucompletion would be used.
  This is ugly, it should be an option...
- There is a manual.
- Keys used:
  - accept-line and send-break will leave selection. There is visual
    feedback because then there is no highlighted match any more.
  - accept-and-hold and accept-and-menu-complete work like the latter
    in normal operation.
  - undo removes the last match inserted by accept-and-*.
  - completion widgets move to the next (or previous with
    reverse-menu-complete) match. Because of this I could convince
    myself to implement the `ZLS_SELECT' thing.
    There is a problem: I had to strcmp() the name of the widget read
    with strings like `complete-word' to allow this to work with new
    style completion widgets. This is ugly -- and a good reason to
    implement local keymaps.
  - Movement functions, redisplay, and clear-screen work as before.
  - Any other function leaves menu selection and then behaves as if
    menu-selection weren't active.
- The behavior when asking if the list should be shown should be ok
  now (I hope).
- The menu-select widget is mentioned in the compsys-manual and
  recognized by compinit.
- There shouldn't be any flickering any more when moving around in the 
  menu.
- One problem with the default colours: I've taken the values from the 
  manual, but without setting LS_* my `ls --colour' seems to use
  different values. Could someone who actually uses coulured lists
  please check if the default values are correct? (They look very bad.)
  Oh, and yes, standout is still the default for highlighting in
  menu-select.
- And another thing about this highlighting stuff: currently
  ZLS_COLO(|U)RS is only used for filenames. We could make the code
  use at least the `*foo=...' patterns for all matches. (And if a
  function is invoked when generating the matches we can set ZLS_* in
  it and have highlighting based on the type of matches generated.)
- If you read the manual or the collist.c file you'll notice that I've 
  changed `collist' to `complist' because the more interesting part
  doesn't have anything to do with colouring lists. But of course I
  can't build a patch that renames your files.
  Peter, could you rename collist.{c,mdd}, mod_collist.yo, and change
  the xmods.conf entry? (Including changing the names of the
  setup/cleanup-functions in collist.c?) Should I send you a patch for 
  as much as I can?
- Final remark: I rely even more than usual on you all to check and
  improve this.


Andrej Borsenkow wrote:

> After all patches I started zsh and found this ma capability working :-) A small
> comment - I think, it is better to highlight just the current item. Currently,
> the highlighted area corresponds to the longest item possible. Example:
> 
> bor@itsrm2:/tools/var%> l /var/adm/log/messages
> memory_messages   messages
>                   ^^^^^^^^^^^^^^^
>                   Highlighted area
> 
> Looks a bit confusing.

This is intentional. 1) The only reason why I would use highlighting at
all would be to visually separate completion lists as a whole by using 
a different background colour. And to make that look good I needed to
use the colour code in the way you described. 2) I also prefer it with 
menu-selection because it looks much more menuish.
Any comments from others? (Btw. this is one case where collist differs 
from GNU-ls.)

Bart Schaefer wrote:

> gcc -g   -o zsh main.o `cat stamp-modobjs`   -lnsl -ltermcap -lc 
> init.o: In function `init_bltinmods':
> /usr/src/local/zsh/zsh-3.1.5-build/Src/bltinmods.list:20: undefined reference to `setup_collist'

I forgot rename `example_*()' to `collist_*()'. I saw this yesterday
evening and it is now fixed.


Bart Schaefer wrote:

> It looks pretty nice, but how do you accept a selection and get on with
> it?  I get in there and can cursor happily around, but I never seem to
> be able to make it take one of the choices and let me go on with the rest
> of the command line.  Sometimes a space will do it, other times I have to
> hit ^G, which may or may not abort the whole command line.

What have you bound to return?
(I guess these are more reasons for using a local keymap...)

> And the listing doesn't always get erased once I've managed to get it to
> make a choice, though it always is upon accept-line or repeated send-break.

It shouldn't get erased immediatly. No completion does that once it is 
finished. But with the patch below the highlight should be removed.

> Finally, I wanted to mention that I got it into a state where the highlight
> was not visible -- I could only tell where I was because the word on the
> command line kept changing as I pressed the arrow keys.  Eventually I think
> I crossed back over the word that had been offered as the initial choice
> (which was in the middle of the list somewhere -- I think it restarted an
> old menu completion after I thought I'd broken out) and then the hightlight
> came back.

Maybe part of this is: when you start a normal menu completion and then
invoke menu-select and then leave it again, you are in menu completion 
again. That's intentional. Otherwise I haven't seen such a behavior,
could you try with the patch?

Bye
 Sven

begin 600 p-collist-v2.gz
M'XL("#TY;S<``W`M8V]L;&ES="UV,@"\/&M7W,BQGX=?T9`3D&8D/"]@@(NS
MA!W'9,'X\,@FZ]W#%9J>&5WT&$L:8[S+?[]5U4]IA(US<R[)@M2J;E77NZI+
MGD33*?.7S,]95KSZ)>:OPBR.HZ+<#ME5'E9'UGS?7P%K72\Y^_LR9?T^ZXX.
M=O8/^@/6V]_?7^MT.JMK5,#W#[K=@QT)_L,/S.]Y.ZR#OW[X88V]:J_YK,T,
M0CY>9WGTA<-%LHAY&64IPX?%6H<@8="`5B"B=,9X.@_2D"<\A0F,M?$_=CV/
M"C:-8L[@[R+(2Y9-V9=B[K%RSMDOK)CS.-XF<,1PT/5Z`];!/P++/T5I&"\G
MG&TH1)/)?*-I?)%G,+[F%V501B'[.9K,>,D>;@&?9<%C'I:'\!BVS7[F#$8(
M`<`H2'C)\X+]<G9U>W)Q=G%YQ8)THF]OX#Y*";@`4/80/+*`]D=C1#(6%VR2
M\6*;G99;!?N?95'"PP#>SF$\W2I9L5PLLKRD*?^=Y5M$$K'(XX)OL_8KQ&VM
MTXAU!_Z'>)^FD^@S+P"=,J.5`.\D2H.8%66.'`CR/'@LU&I_FO!IE'(&N[A]
M=\%8ERC<[PZ]7I]U^MU=K[=+-`8\X">:,F?=*=@1`PP*(HRS88BRX;IL<W.-
MM9Z%N2$@E_V^UFG18J$+5[ATSLMEGK(>,*`U!7(Y$:S0/601^R_V[N8<9U_!
M7:?C`@!."/W70-CB0_0;`&YLX#SX/XSRSR6^_=W-V1D.6@OCSQ/(J=H)O5P^
M[\KG@O?SX!-G&1`&)+$J`Q[)150*"N)/PI."ET[HL:['"E"-;.JT0]>5"R(N
MD^5"D-\I8)A(O-?U^GM`XKU=;]"7)";^P>:3@)0FN,N60AQ0>$$-LH=4,DY)
M,+"9I9D0`H\E^@(H`[]C8*VX*>1=`9+R]:E1^I)%F%SD!%`-YZR=T%^/M=M)
M&=S9SV=YMEPP\0>>)S/QG#9[%A5B?S0;=>,\*TI!<S`%D5*3X)ZG;)IG"8N0
M$A+:<3W2#@`/LV5>\!IM/F719,V/I.ZK20JC0`YX1(@DR.]=FS1KG=J\MUEV
M#\H"K$R21X_5EP&I_%WP6SV9':I[02+8?:*&^.=%S-I<WA(GB+`H\AY+!:U3
MXCJ-Q%DZXW33\]@BC<5HMJ`+:Q4@Q1&0#<7Q[/3J^OI?[\=7('"^>IZ$R$(Q
M.PP/I2JL//!`_HO$6AN$=QF6)(:(&UHTY*'6)+`PTVP[*.[YA!T=L;ZE5XZ2
M,43>14-%*X)MP)6<3?CM'BK[`C)QQ85(A,!1,`-W/,X>A`H"_Q="[?1[E;#B
M^\*8!_DT#F86WF4>%/,O,7>T,H(.@1I*RI+?0JV24X1[V0/CUP7_,MK!OZB9
MPFX8',^#QSN.AIO,!!A:V#GB@VB"=<C!`8!_PP<%YUJ!"75?H>XH5YD$G\%H
M2FZ_9M:PR_[X8\UO@9U:`459>8T;@`MA3O6ZZX(90#^8SM8MUI!Q[K1>_&HP
MS-]^-[Z<M5"&/BX7(&HMF]]H?[^`-*(3(AZT``@>+,`6EM.D=#;`S1^`_V./
MV9(]1,5<$2V(8_;GE"VRHHCN0.O+B!=_81M2*SP2)7`4TWA9S!W@X;*4AG6P
MW_7`K@Z[/<6]5JL,DV5<`HQS?7+SWF/7)^<W9]=XE<9I6-)2Q&/&XX+CC,6R
M#)VM7],MCZG%?<M-'4JG5=VK&#/Z`"Q`P6Q5M(/U#QL\WA/2$"9J(19D13")
M2FZA@OL<=B'^Z<%&>^2K::,:?VN>O0760EX\(CK.9C&7EZB4K16LR;-5$#<>
M5,<"TFN@.'2-($2H2GX+;2I,2W1@U4*73L8-K':J/$EKFG/NH-L@#/$"P!QE
M-MLN^P+"D(40$+25>S4/%37V1T2-G=Y`4Z/5F@(-"I#V>)LB!0QRQB>_V?1H
MM>YR'MS3I8P.Q(4T@#W]I'F[+<+W0Q*R#E@ZN;4D=C$F^2A>0!ZO&6)FO=>W
M7N._GJ7+!"TI^26*EAJ?2NNG4('5D>"A?#%2&.]C>2^(1H@AS79&(V\(4=XN
M1'N#D:`9!5:V(?4:Y:BB+`T`)L0B.H(=JML-V%%->2R54$_@34_58&?-_UZW
M[/\N;6YMHO'_#L;1:"[_PIRVO'8ED0\@(7*5!S61H@]R@D$YOEGZ1@K&RR"\
M9^US=7E81Q[9^?4-8-""492%.)#1."HPP0I%$)GZIAP5WK@L^=#]S87-25W!
M@=YO<EO-&UK9B/0J>CM@MODGR:EP'N2LC;RTHHBPD#?64FA"&/Z"1T_DZ"L$
MT2F,(U9L!_D,I6.268^^(_:2=F%Q6`W&V@L5CD&RF<X>69A,#NO;6YJL0>TH
M4I&!9L6Z17ZZ%$DN=PAQH&03J-8'%?;@:]#',H?VA&Q=KZ5+5^.S\<DU9DO5
M)$8@9RE/5W(ST2-U,98[M0$L8Z^!:&'*O0X/A4VIADM^G_QYSL%B@]<5?B.M
M>GO<I,)-96K:Q!)1(EP:[<_N8`^SR\[N<%_;'_2#&""0%^A0UH%V4YBRMLA"
MR'`OT#J1:?T*F.00J/81:R_4_2Q?T/T,\3?!D@!1(T)L)!C3,>O]`=Z(C3@@
M0R++O>>/<.VXQ%$:/0(Y<[[<%CR=T.XIGI+FU7H>A"%?E(BU6R.6WT+K2C*S
M.B%()_,LGL@\^@6`(IIK-;P;(&PIEDM6]0+3$D??@C^>"X>L<MW"I;A>3"O\
MUV@F8,I2!3JH5\6A>2[]DDF*I>Z[Y!M<"S+$5X=Z+F3:X>+1V73@$44N'MLD
M=NF\NV9X7!W:24H'12GD5GBO%;(MTTEFT0!-0&SV1FQ?4DPWRR!01=:;IX1L
M5^$*>@3N(7;BV&QH$80\(D_HH*,&9&.>.DM!$=?`E7F*^ZR0Q6,2#K)!#4FO
M7"*=ZB229-G$U26IGB>1F(KBOFG9!9M]2\'50QUDKE`.=AL5BSAX=$WHJL<<
MR,'23%I(J0996D;IDHM89&]GZ/7W66</8I*]'1F_$5(SYA\)A:8HYDF'Z@]S
MK!@ZH/GK1Z(N@5;4::-E`*VDY`=NR'NKR%C$\!;O_.=%0:G$0Y8;!:JJ+Z3Q
MH#]9KK7G96!`R6GT^1G@BC8^#_*55Z\#A\-D@9OQ7Z=!XK$-G.$+H[SQ=4BU
MGH_;_@:LP,'/<E_-^NX)OJ#%-^81^B]\!\$V86:T>I()*L/$KI;R;SG'3DUJ
MGY4;4!.>%_P9/C9@+"?XM5T:?!M6K"C4_W$#ZC7+U')E"EZZHPXI'A"NP'"`
M.Q!AB6S->BD,52()F2<:$%^%^5;0T+63!1TX$$ZKP4>G&GR(ES0G#ITGM,NO
M\'"!LP=1,9\N(=F/,E%#[52K?<\&HK^;\'8B\;4P-G0FE)L"0I%;&XY0"%^O
MEZ&U>B[^JY8+R,%,K)SIJ5Z&D^]8*<KA.RIA-0:A'D6\5+=GZQ/WN3T(5EJE
M\B=1PL6"*P7R!3Q:@*4+<*)SGDV68)P3+*G2`YFG6`]4R/Z5->^RK&Q:DL:?
M7U%6$$0D+P+?F3WT,JF4,9]]R@(/@LD$-$\)DE,QK!XSH)Z8_:V?7\[&M^?C
M=S<GY^__P.N?QN/W5S=OWIS^DVY/KTXNSM_+$L?>:!<+6Z-=_$,.4I+.KQ5F
M`,<Y)$R(I+.!-+J5>1)@2*G4-'59-7%4"6%E*M(CEY/MJ:M)K%+&RG0DQBVH
M6%[:DVT!5)6$F@C09O>'7@_B@=$>Q`5=?3RB10-K%&FSP*E'SPN(77#JF(&9
M+$$)((C=0`%L9MNBH%`74/\NN>NSOY_B]17^;:+;Q)U&:53,FV@KG[Q0FR<-
M)]O)8GMN'4GC;?5,&T=>>J"]`KM_T.UI6*H&[WJ080Z4RM1J-J&@9LY8^T1>
M'C8`D0=B!(27#2"+`$O<*8+(R\/&`A$50T2!2)1$Q#E8FDTX)=ZXI;",L?HX
M9R".&.#*,11.<;Y%QX>[.[BQ/A@#4!.A'OHL]\V[VS>GEU?7@'*O.OSC^,WQ
MS=DUZTOGN'K::%E_'"S*Y71J_&5U(](UZ@,O_'W8:L&ZBZR(:+X\%1<`1$=U
M?*-*->"MQ!QQ#[<Y3\OXD0EE`-^E#WS`!</"`(W@=WP&BU-K`>;\%@Q$1A(&
MKF;E'$_%]&+R%-R&AQQ=PL,5KB@.;&JK/G`)E&:I_X7GF3KPD0=5#T'!`G%T
MA<O84^'EX0I&!1`V^MR\2_+9<L8#%[?J=>HH>!E/@`;B4)@F/REI>A,'LT*+
M$]ADZE6`O_K<5!Z4KNHGF#M+/>G.UDX::%#.X:IRKH*";@X/!EVKTV0X\`:L
M@W^$"&M)O;G^*SC!\>7MV>F[,>LQ.G3##7V*#M@=$([G%,@&0#W(`[-8\*M`
MNDZ",J@U-_QT>?KN;R?7;"06@@CU#A8`6+%4H:3T/HICIL6#%.0D2S_Q-.)I
MB(?489X)PB(T&MU"0JHWX:'K^?'UR=OQU=N+BY\8AND"KL.ZKH$[?7<UOA20
M*W`]"PYC@ZOKX\MK@F(5N+[;S$!P'U%J]0Z9H1HKY>B+^=D$#TP='`R&AJG[
M.[MT>DI_A_KT]*\WIV?7I^^<#5@'/!/^=#UV%Z6W,*#O_1[U4&S$/QZ_.SE+
MSF=_"R\1FD)4"*E(Q%50#_FIX*)0.=!K+CD9%=)V@AG%\T1A61"LC72D1B7)
M3(`7,D]\E$Y0VKFYK#HKFG_`(QOIYW`=,*8K#M_N3X"]N%X-O.;A102.3]_<
M'M,>.Q7PBCM?!69*YP'K9ED`JH3WCS5I4(-U>5#C#1*QTRP1C3-`)D8'PY&E
MZ+VNUT=-A[\]%<Q972@R&:<R.S#W?0:#J):R@TFZA&:G4@B#B!9.#E-(3NY:
M]JYI9T:M3\Q!(&SM$=U7("*+9:DF`W2":Y'YQVHAV$KQ@P+R`H^I&JN()[YN
M?Q%E9SH=4$]DXXPH4,LG!+C(J/6%>AZ0%-CFL(*<"W:/Y]SLV-JGVKKP=>"6
M`$[YF6U&X."'U#N,2Z+^->$?-6WT8MI1(57D*NCHY"IXJ1FD&GCD8A)]5F&*
MWHE<ZX&Z_U[F7"6N<C&L5.$A7I!JS(5S!7L@'>4L`U^)%5EK45>^&+TSOEHL
M5J5(D#XJ1TWKHD&YXT"[DB>++`_R"`(5\*Q$5_L'65QITI*,]13U/45`3^[>
MT\@<KD9:B1TM7LO>*.7A)==A:@1A9,#N\@"\%97`"I+(NQR")5*1NQS)AT<"
MJO=2R8AL140*65O+>9)]`IY3[Y4M'IEZ,]^6;*53^.&^-V*=(<3;XCP'TPF9
MHV!5)<LI;:@46)@\YC2=8GBPH_7%#A634#XBA>FLSC(G-X?5(%/,5-41ZWP/
M\A6=\2U%B0T@U]=%#Q6EYI"!GXVOQZK18+='6QR.Y!8I\59'X;`<'FQDNGZ"
MLV\Q*KBUUI&GB>9L"D_L]9`XGDIFJG9A'5`E8650G5$ELVI.)S:E4NF=_@X=
ML^WT^JJ94U4.FDH]DAAOQ\?OP<E<G"!_1'>(0E>SQW^MLE'=SVEA>Z3NQ(%T
M!9C).BPM+D_3K+VKY?'(P755:X0!B.52JBE''P:L&\S";)F:MAV+UC7<\?BP
M.HGYHIE'X56A=6U/$D/9GE$%-5AV:EC6":-PM;MN!+;-)*2SSH8E!.:L>MHA
MM^[[*^OC$&LEO`RFC[=T*D7TLJJ\ZAB9:HYFV"XOXQ++M+:(U(JS8PA>48A6
M:@XDF*!*V,B]`[H$?TDPR51]B#'2VO*V#LT(!L8T^FMWJ]*`0B)$YV#*=W:T
MA^O8-E4"$>82C*XE(%T+4-:*A.$3IM_9`EQ$PQDU.!6E/+C;P'ZTGG@DCI;)
MEQSI]XNS^99"3!QEBOL'KGK&S)LU>GJN>FIFJQ$U7U#":/NHU\,JX=[^2)8\
M+&-$R7%1FFJ-,,3@E-K8SZF[1+-8=$=BGUTXEUVA=&2;9CS'%N@LA%_"V'4/
MK0:0[YL)=\:DB_A/&&;0.\QK@QDD'%B8_A3$T01=A]O8DT`Q9G>72CV][L[`
M;MM<9(LY#Q9:*+\45.S[2*=Z<FQ%?*T*O\2-RN.`+36V+E.9&CB5_,QCCNC>
M<4UG2KUT7C7-O>[>#G*+D!?LTI$6N=N4?RZ9'5Q^UX\=B=H]T1WZ;1^#K4@&
MA!E_Q];KN-:A7:E"8%26\X]+7E!@":\1FQH)AP.[TY\/2"F52U_`$OE#!,H+
M@9F,\FFKPEW+>)'"]>UMTVB_ZI/6VYV.LE'FFP(8M"W4R_T-XM#D;X+_H+]Y
MJ6>1N#1ZEN`_X%DL0`LWT8$#+$*ZBZ2*A#$JS1<EU>`=F?/_Y4.>1`@V&`VI
MQ7<`VC.2Z62KI5FBMZUZ"+"1,Q$41=RLIB!Y1M2JM`'5!E7[:Y?Z#\P.$DTV
M[+2CAU%*EBHH.<6YIJ]8AH[#+L6.NX.^9_5;JIYCU'.(S*5AVWCDQ89:X!ZB
M4?;'$3MY?WMQ]B/&DTK0K,C,%=)=B.9JYVXY]=C&GR=X$%#K!],"4>WZ%7VF
MC?-7#Y3%CB7.6(<[PG(:#5:Q/7UW5>NO)F+L]?O$Q+W>4)UG$:_`[9899BG4
M*8V<-31Q(/]:\#Q!:VQ3"XVS.E<WPX#]/>>+#=$!HK&T%U&20'WQS1#6D:J0
M)VO+J^^%4?NUB/X7<CCX/%\D\!2H<CD^/GM_?'E\?F5:FM_CR:]J9][=[>\C
M=>!OS\HSD%T57XA+ZZJN5!G,SX/D+IH9SPI7>AKV'54\*.9VB)W=25A7D+KQ
M6!FVE80B"UA0GKKK8U=]MC?LDM?;&^@@1;@K2$P?V.7XY';\S^.3:_KLIV!\
M.N4A%AQ^YO(Z^L0A-25W2FX"][K,EEBK:.NE*HDQ?J&1@ILWH%G*O^%,E=-!
MF@>4A`.WZ0*_,`OP-!@",!R$O%$,H#@XFIR;[,T)%;!=H9BK5F>5HG:+A?TN
MH6U-YD5]CR`(VQ\188=::J@?'R:0/CD8`1]!EN]"Y!5C=!;''LB+Q_A'CY4A
MV?]_@%Q>7E*.CE"BX4Q\HO.R/70:[*;P*2?9XM$<KL@Z?HFE&4;E6KCD08%U
MAQ(_=@+*@]L!1-*9#"_0T5![F\++8">:R`9=;X!=9#O](5Z8#Q<AC)?!O,F_
M*RVZ]B<TU:X.0OUG3E4T<SJ59E0S#.K%-P]EL(5JC=^QE+**)^MBGX(\PIT6
MVW51LY.$A[M*DN`8D_A:=G%80TH(UZ6JNSH7$3Q_X/4L`I>O9!'?_P(UW;RB
M%N"=3NG<*L?O>'(>3!X;:<6R'.FMOJ.:8%$VL'1X%F=WS":M]<65*"H!E1-N
M2I?`875^5[$$=JWQNW[L#[:LON_8RO$J.::&M;^DB2MY72W5Q!\9`,1$2\CA
M'^XJ-2*9&BKC;.>Z%1MLX#H&3C'>='>+KM3*-W?'0!X@6HJOKV0?#[+@9SY=
M,ZDM)L+D>YS$8YM%J+L:C/!1NEO'V>3G%>R?7]0",LLV;-'.Z"NY)$1JH/Q"
MEU%^T!*([+F2M7\16;V$5@\1+__(8K*IAH$A)<MN;[IS5*DY5#A3?X%ZK%YA
MR85=31.OL2-X]:)*S<+:[91.@#?9R?D;B#7.+_XQEK%A@BZ5["#P%2%SGD"4
M)RX*4X*FW>M]"O2/Z&3R!6MHK%R=Z]ADH'5D9"[6@?U_N+J^N#F1I,%X^C?U
M08$T+*TG:>+WQ(=><-''"_/54H$DX8L@_ZBFT:<,BX^P$HVR!?WG^ZZ(U4T=
MY]<-NY!3T;N.G%RA?_6))+VUWM-SRW4Z];@=F*M2D@;QJ;X29]?C=IRO4Y5&
MN5"?%M8%X\WIV5A\@H*LBQ8Y]4^+PO?QS?6%"%`A_7KK6CFT-NYDB`/Z-PI2
M_#</\)1&_Z,0X/@#\\T\(P!A4`47=WLC.B6&B[[Y3!/7+O%D(V"3*(=(+\L?
M/72DV,-`%AYBV[F,!&J:7./H*YL#K2KY6S7:6^IK`2A_AQ0RRJY);?C16F%&
M15$MH,J2EFJSRL=]J$X$(13*%=_N?4/IQ.>P.IT4'T=K5@H;('DIO[[9VQW0
M2<;>;E]ET59W/<F-;[`F=9:B^ZPQ;UG!DYA@?:7PG)F6KS.RI1R^.#A</<ZR
M"D+X/JH/FTT-1QX&@+O#OFPJ,1@4(L#%^[KLU!78^YH"-ZFE3%XUEQPS57Z4
MO2I-J]KVT_A?5[K?=W6>%IEG9P(+C4G=\K;0BEH#3UO_V]ZQ-C>1'"L?3[]B
M,-19B[1&1@9C$RKG$$BY+L`%0R5UAN)6TAIO(>T:[<JVX/COZ=?,]LRNA,V1
M?,K5W4F>9\_T8WJZIUM.K'[Q;.@2JBF;@H^';ZP4%S?*N2*B>WO](3'RO2%^
MX1V_K7V%F/0$TYN0$(!K6'HIN6!0=#048995,'>RJ(J/#`K\E0%@PA09GQ`4
M]2'-E'Q26/S1#1-=&YM6:#JMMVT"W_[_=3E_57EN-+]WF;4MOGQ]]()D]AKY
M+701TX`DD&74QG$`S?_Z,C)_`6U_'Q^NU$=@3.=<U%!OKSIY[ULFK\]9-[VZ
MMGEF><M/E.W`WELB[17"%WXJ0X+7V3%5T-WS%]$`A``D`[;RXT.SX[MO$='6
MS5S,/`=U4*[<SY;,A;@:1N,?9SYAUJ7F!YIW@(S<<#>XZFVO>H8P*J^%?FRF
MG!;8,PB:+`@.U35XN-;L[5L$"A4+XLP_N]O#_@[*C-W!+@:@^^F%K!<>V'O(
M7%<;L;9]Z-;8491L^RR;+59!Q<E<"$1&+.='"+8[4=6D(7+TQ/5J8'")Q_[,
MOD,.W:=#[MVLF'2EJ&_0X&ACLSD!TFK_@W--B`F3G1<P\`VZ0=$</=XMKWGH
MZGBHCWAL0#P0N#2\*XZ_!PSF6M>$Y[FHHU*<EZ,%Z):.[=Z10.7@IKB$=B](
M<(E:A4[/WH_%UL0F*E%>SIHXG!$.F]Z@WMKVJ[PU#?+%V/K:E+9N2"2CV3>0
M47=L[QX>[O],N)E14-=7B,D>>`)<W!@MI+;O35FT@A6HU^NX,GVY(&"WHM;1
MV\CPNQ";/O&=HSQXNU*ORK5:^6;$M:6!M8MNK&TWK6^-ZD(;+F)>ILX&[[\A
M1(M;D1L.[:2W[N1*K)R+>/?!WI`,U0\>["D/``Q\$T[:[,0>]2UGU@HG>]`Z
M>(?=WDG%O7#(T1ZYYW;W'MR7NX,`]?^\3U_/^_3?S/-$[UH&`XIX@4_G//T^
M>9VNG+5),R@S;&O6)H9V6Z#=WK'0_L^2,SER?5Y<,`;\''OJL7@QN?-K>4J1
M5.6RW%H6YF_%."CB5^)APY8WXGOU&_'F*,$+\>T'?BC(?7X'`Q]BTSM/YMVR
M6D[15W5QFH$6/</W*".5E;$HY0TWG'GX*-MS%>!M<[KLF*KJ>B'M,!P4L?<@
M1B<7!HF37D@5S<!Q?&;?6B&AZ]P/1X#ABFP,O$$EVM>!@\2VK&T*M)Y!?6LD
M>+35Z7U[7[2H`/9I",O2<"/@P+VL--,BF0`!=8$7.[WLY-,LR;OXOSG*W/*4
M&P*[O\':G*HQ6@VK7YVF3G3(B-0NXKRM%F8;TBWNX'&2(Q9!7$Z@75%L(<&J
M(&U^3PYMX&B=D(P%"8'C(45\2)<PWL<%QN.4D7F?G>-+ZHP>:N_CB_B\H[-V
MMG3!X3$NCV&TL9WVR1$EH;W(IM.00V!Y-NI1<XE?K#G%KVERRW"[R2UK^G!@
MXXY.T[N':7JW!Q1C$U?I989X$:30&(;#,R,J`XJO"GKOITMMO*$M`RCD.V;.
M*C%(O&7`3OR*\2OECI[(:M%(#(SHMEF#790&Y<GMQ)@I%__\^_/7Q$9EY/QU
M:#?B,`+$*^/:$E8<TX``27'&#^->V3R[)9&6&2VYKT`F5#<&&5+,"`YH@/(6
M-"#8/9WA%<=W*6TCX:ZZ@*<Z3Z8+CC>#OGA+I.X4M2(A!ZPBV)5RT(A)2KN"
M>@)8*PD'ER$WTAF',=DL@%KO#W%TGF;XA$[FGR%5PV+ZG;BQ]TC,Y*S62$")
MXA.,</$?I)B>HAA_Q$YOG.63]+*K9;0DA89*1T^!@"HX/J^Z*`PHY"D9@$L5
M?:!22Y?[L"AVMHLFL<2&I]G[TRG\5]4O&'-3+N`\2>K((?0WX$PI9H*@4P=W
M-O!6;U$([&)$:_S%80B@?XIY2@O0?Q6,*(4D_&R2EN-Y-DKI>8N%`GWC#C8F
M1\J50);1UL3#'AD>A83Y&HJ(-#L]H34G`X%2':'J\21RA^@ST6Q#[-CIX7GB
MHGG2@#WW8=.0GG*0$C@F109EE+P7UG&6CK.3;$QA4I9+B`?,;RB3\7".'N$W
M@B[:M$PE59W>#.3"R,O`?`*RAIXMV9`5N&Y+LF#6#WC2)<GP&&5\25LAM?8X
MX`F9+>08XLE=L!3[PK,YX.TD`?42-H*9'5"V+VE#YE56I:#IPJ&(G[`U>6$&
M4=3E*7/$`)Q:^*2UB\RGS>&<$0F#:J!EP@0!`ZFQ3C(UUCQ]OY@"$^*R2J_9
M)#/#NZZ=]9AE0:MI;H;W7:MR.1L5TVR,6OP'O^$9#+==+P'P,#%G&6RCZ3X]
M?/JB]&$L"S,<UL,6XP]IY8\WFIB=G8?#7==H-(56L*OGJ"1Y3<=A4Q0[R1B%
M<5OS]-(,[[FVZ64Z7G"\9W./9EG$9%5@@BVUMI*$(GRCG.A\\'<%XY8SF'4X
M%)?11<B)_)V8CLV;]-@-SM?A$WRV/4E)K^(<QGZG^=C,O"YSDE'8QU_JN`5^
M&P;G6N.E6>BQTSN@#/HV8JM,:WZI-(\99+%D6O+SJQPD`&QW5G[H]+J_P<2W
MH\U(>([%`H7"R6.05SXS\=%,=$""E>+7<%\UES&YP]^$)(S:!M#()P30XSE5
MG2HV(6'[+SSWZ0+#2)(<XVQBF*1<5092#A$2]>O">LN<8#`634DIQP*)%2VT
M&)[$R%;T^6S1L\SM+'5(G+"VBQ"7U^P5:,`G?3KG>Z3:AD,ADLF*D!#I68*3
M492JP6LC73XO^BRJ"!+J+@,Q9<L@M(]\FC-IU[+,'!Z],/=WX-K6/7A^=!C)
MF9WD?"8J/1W$,`C!:GLPX(P"54:O]>2'!4K!.AU0EU@:P27S10[B.0?]88XO
MM%Q;WL<`&"(3TI=`BIYGY0)DISS[M&2`EYMO/19%.X+S561[JZI1WX7PMQI`
M.I*N*D_>Z1<H^I@3ODV]LJJ5;+?5$9ZA&X-O/]!AC99#7"BJCE)%C--$9!!0
M57M6?R#^%A5F#&P%T*K;%JG$A^ZRE>7GQ0=FXT5)PU3UA2N\IUGR$U7`:F)S
MI3'SC;*A,7/&*M10Q2I(J5``B#(-@,/=1LKJ]"XL<L.W@10^G%#$<7>4CA-4
MA!,+LU!<?3&N,ZU=6%6&DL=S/^8=]$M2MJ4(*HCCTRHBC!V<5!8"#T0!H.]%
MP%B4X]:+\E"CI2I<Q$1;N(1%",]2!]9FL!0V%=JM(U4J=S*D])1%0J(2(W(T
MS1),T6-#=;_.%PZ!+-%]?4>D&(8:5R0&=Z--:XFA:Q[QA5T'@SF"G6C"66*2
M48J41Z&-<?-FI3`A=!Q9<J]U]I)?AP()SHISNWA*,)[,R5!0;\FG*>*C.*<?
MF7$W_)+7^&E:7_I)=&"&UEA2M+*$KKKL"8PYS%[+0<#H-$4YY9-*GTIKJ'`K
M0%8T,]DXFB!:@(L('!?CE"%S4&D0T-C#"5Q%UJOR@.Y].$'644L%40L\).<E
M(:"4JEV',8@O\%S:,L_<]4DZ\]4<CCN9V<:*CY8L;YR<`+`IK:K*O_=SNBQK
M"X^2ZTH`U&A">F.114%BW6*./]K!<D4.XU;C5U]^-P)4R&)11L*E+!#5#@BS
MU`E,[6:363>&RUN:YI&"!Z16@92'@@;/*M05D+XM%82"^`!4IX+NZYK\@..1
MELI0[N#DEL.2FH`1;%9U\9AI-4_1S;QIGK+%3?.4K;F.>:JU3XMY:@?-4ZW&
M*=^`L,I@A>VV5Y@9KC!@BT%CS8C&,URHT=@T*8<VE`>FKN0\R:9T]2B1`H$6
M1HML6B%QLM0'L:,Z]SONTHTR,9E/B('(GI%7\V*JZ)_S._SZCR=;QARE:1O&
MG84FQ+FN"+&NZUKP?K<=[RM[70/S[08ER3*WEA[68/\Z@P8TL8("&B,Z&G`U
M*ZD`)1F@S#'MOLJR5>,`9PQ0)D4!LJ3TRFAJ:]]`T%WTG_7N6B]:2-^6@#F[
M"%'E%(6:SJ,C0E.:$J5V=`/6TLJMCHDZL;ODB[$8;K'Q8V<.#C7J+645L'HR
MWGL?M_R6G+.VT43&V44<FJ"C.?`0@DG'IW3'@P&>/#MX?+2)J_^4G,550?X@
MT`CYQS'0(77/!JBAC&8JFB*.'674Y5JX!.5:GL2JQC>J][P^7E4]7`MQNKJ`
MZ%4-7[EM.3F[V?\^E.7)#^5ANZX3];A2H*;H3ROJ<<5?J>>C`EK$[2VLKP-:
M]%:-43=IG49+IE5M9&?6M*`=XGK'K^,[C^%.=^<=Z*BGW,#45-BH8]9M]OGA
M&5`=,2,<J0/,@3=0CM(U`WH==T*/Z7!W%SU`_($H3"_/L&_YJ&LV;GWN_A39
M@OV;MX#7WG_90![IH*7@^-C$.;0B#!7Y2?;^F*9E[^+;#7PN0.\5C+EUTPX#
M75(SH*<`,Q.G'XE*,:M`>IR+POC6O'W[D+QWV-TF'XQ?F_C(;&["A/0DY?@G
MF&'C%OX$&GV-,_CK\)>73YX>_AO^.L2_.`?NAGECX<!_XC.H0LT9X8&6P3J_
M;/!C"!]H`/3*0/<4T/_\0U#W%-3/S.9\__<[CVX;^'AT>_,*ZP"&150!GM:"
MW2!5;);E<%\+R<I6>$1J"Z]'H:Y7X-"'?W7>U1T2,/Q!N1W-RW24R<%1:S]\
M4'3HM'F7O;/W(L]E;UJ\]:;I"8=MA^U>Z:<WVD7O61M2)K,5#G;3>K=X"/=1
JQ/*U.FE-GP8`>/%&$#\VM^SBM]PW2K?H?H6@0Q=@H(K_`)T9$'4O=@``
`
end

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