* Re: PATCH: collist v2.0
@ 1999-06-22 9:56 Sven Wischnowsky
0 siblings, 0 replies; 11+ messages in thread
From: Sven Wischnowsky @ 1999-06-22 9:56 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: collist v2.0
@ 1999-06-23 8:43 Sven Wischnowsky
1999-06-23 8:59 ` Andrej Borsenkow
0 siblings, 1 reply; 11+ messages in thread
From: Sven Wischnowsky @ 1999-06-23 8:43 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: PATCH: collist v2.0
1999-06-23 8:43 Sven Wischnowsky
@ 1999-06-23 8:59 ` Andrej Borsenkow
0 siblings, 0 replies; 11+ messages in thread
From: Andrej Borsenkow @ 1999-06-23 8:59 UTC (permalink / raw)
To: Sven Wischnowsky, zsh-workers
>
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: PATCH: collist v2.0
@ 1999-06-22 12:36 Sven Wischnowsky
0 siblings, 0 replies; 11+ messages in thread
From: Sven Wischnowsky @ 1999-06-22 12:36 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: collist v2.0
@ 1999-06-22 10:35 Sven Wischnowsky
0 siblings, 0 replies; 11+ messages in thread
From: Sven Wischnowsky @ 1999-06-22 10:35 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: collist v2.0
@ 1999-06-22 8:49 Sven Wischnowsky
0 siblings, 0 replies; 11+ messages in thread
From: Sven Wischnowsky @ 1999-06-22 8:49 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* PATCH: collist v2.0
@ 1999-06-22 8:25 Sven Wischnowsky
1999-06-22 8:51 ` Peter Stephenson
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Sven Wischnowsky @ 1999-06-22 8:25 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: collist v2.0
1999-06-22 8:25 Sven Wischnowsky
@ 1999-06-22 8:51 ` Peter Stephenson
1999-06-22 17:06 ` Bart Schaefer
1999-06-22 9:04 ` Peter Stephenson
1999-06-22 11:52 ` Andrej Borsenkow
2 siblings, 1 reply; 11+ messages in thread
From: Peter Stephenson @ 1999-06-22 8:51 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: collist v2.0
1999-06-22 8:51 ` Peter Stephenson
@ 1999-06-22 17:06 ` Bart Schaefer
0 siblings, 0 replies; 11+ messages in thread
From: Bart Schaefer @ 1999-06-22 17:06 UTC (permalink / raw)
To: Sven Wischnowsky, zsh-workers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: collist v2.0
1999-06-22 8:25 Sven Wischnowsky
1999-06-22 8:51 ` Peter Stephenson
@ 1999-06-22 9:04 ` Peter Stephenson
1999-06-22 11:52 ` Andrej Borsenkow
2 siblings, 0 replies; 11+ messages in thread
From: Peter Stephenson @ 1999-06-22 9:04 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: PATCH: collist v2.0
1999-06-22 8:25 Sven Wischnowsky
1999-06-22 8:51 ` Peter Stephenson
1999-06-22 9:04 ` Peter Stephenson
@ 1999-06-22 11:52 ` Andrej Borsenkow
2 siblings, 0 replies; 11+ messages in thread
From: Andrej Borsenkow @ 1999-06-22 11:52 UTC (permalink / raw)
To: Sven Wischnowsky, zsh-workers
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!
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~1999-06-23 8:59 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-06-22 9:56 PATCH: collist v2.0 Sven Wischnowsky
-- strict thread matches above, loose matches on Subject: below --
1999-06-23 8:43 Sven Wischnowsky
1999-06-23 8:59 ` Andrej Borsenkow
1999-06-22 12:36 Sven Wischnowsky
1999-06-22 10:35 Sven Wischnowsky
1999-06-22 8:49 Sven Wischnowsky
1999-06-22 8:25 Sven Wischnowsky
1999-06-22 8:51 ` Peter Stephenson
1999-06-22 17:06 ` Bart Schaefer
1999-06-22 9:04 ` Peter Stephenson
1999-06-22 11:52 ` Andrej Borsenkow
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).