Re: compadd -r

Re: compadd -r

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Feb 8,  1:17pm, Sven Wischnowsky wrote:
> } Subject: Re: compadd -r
> }
> } Bart Schaefer wrote:
> } 
> } > How about this:  For the simple case (remove the whole suffix, which I
> } > suspect is the most common by far) stick with something like `-r <str>'.
> } > For complex cases, let the user give the name of a user-defined function
> } > that is called as a callback as if it were a ZLE widget, that is, with
> } > LBUFFER and RBUFFER etc. writable, and with the keystrokes that caused
> } > it to be called also available somewhere.
> } 
> } The easiest way to do this is to add a function-pointer-variable in
> } the zle module that will be called whenever zle thinks that a suffix
> } should be removed. The completion module sets this variable whenever
> } it needs it to the address of a function that calls the given shell
> } function.
> 
> Isn't this more complicated than necessary?  Why couldn't it be the same
> function pointer every time?  All it has to do is the equivalent of
> 
> 	zle user-defined-widget

Of course we could make the completion code set the pointer to the
function that removes the suffix when it's loaded and reset it to NULL 
when it is unloaded. But zle would have to call this function every
time a suffix might have to be removed, so I thought the code probably 
should save some time by calling a function only if there is a shell
function to be called to remove the suffix.

> } This is easy to implement, but somehow I think that we probably should
> } take this as an example for a more gerneral problem (calling functions 
> } in sub-modules from modules they depend upon), and solve that one.
> 
> Eh?  There isn't any such dependency here, is there?  The compctl module
> already depends on zle, and it's calling a function in zle.

I thought about placing the code to call the shell function in the
completion code (after all that's where the need for it is
detected). With this it would be zle calling a function in the
completion code.
What I didn't think about (and what you seem to mean) is to put the
code in zle and let the completion code just signal zle to call the
shell function. Indeed, yes, that would be even easier.

> } What I'm thinking about is some kind of hook-mechanism. Giving modules 
> } the possibility to register functions that should be called whenever
> } some event happens.
> 
> This is, in effect, what the "wrappers" already are.

For one such type of events, yes.

> } By making the description of the hooks contain a `char *name' this
> } could also easily exposed to user level to let users register shell
> } function to be executed when a hook is run. The builtin to control
> } this could be added in a separate module, of course.
> 
> Have you finished reimplementing emacs yet?

No, still working on this...

But yes, I like the comparison (and we had this discussion about hooks 
some years ago already, where it was me mentioning emacs).

Bye
 Sven


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

Re: compadd -r

[Bart Schaefer]

On Feb 8,  1:17pm, Sven Wischnowsky wrote:
} Subject: Re: compadd -r
}
} Bart Schaefer wrote:
} 
} > How about this:  For the simple case (remove the whole suffix, which I
} > suspect is the most common by far) stick with something like `-r <str>'.
} > For complex cases, let the user give the name of a user-defined function
} > that is called as a callback as if it were a ZLE widget, that is, with
} > LBUFFER and RBUFFER etc. writable, and with the keystrokes that caused
} > it to be called also available somewhere.
} 
} The easiest way to do this is to add a function-pointer-variable in
} the zle module that will be called whenever zle thinks that a suffix
} should be removed. The completion module sets this variable whenever
} it needs it to the address of a function that calls the given shell
} function.

Isn't this more complicated than necessary?  Why couldn't it be the same
function pointer every time?  All it has to do is the equivalent of

	zle user-defined-widget

} This is easy to implement, but somehow I think that we probably should
} take this as an example for a more gerneral problem (calling functions 
} in sub-modules from modules they depend upon), and solve that one.

Eh?  There isn't any such dependency here, is there?  The compctl module
already depends on zle, and it's calling a function in zle.

} What I'm thinking about is some kind of hook-mechanism. Giving modules 
} the possibility to register functions that should be called whenever
} some event happens.

This is, in effect, what the "wrappers" already are.

} By making the description of the hooks contain a `char *name' this
} could also easily exposed to user level to let users register shell
} function to be executed when a hook is run. The builtin to control
} this could be added in a separate module, of course.

Have you finished reimplementing emacs yet?

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

Re: compadd -r

[Sven Wischnowsky]

After I added the `-r' option to `compadd' (which specifies characters 
that have to be inserted to remove the inserted suffix), Bart and I
had some private discussion which ended with...

Bart Schaefer wrote:

> How about this:  For the simple case (remove the whole suffix, which I
> suspect is the most common by far) stick with something like `-r <str>'.
> For complex cases, let the user give the name of a user-defined function
> that is called as a callback as if it were a ZLE widget, that is, with
> LBUFFER and RBUFFER etc. writable, and with the keystrokes that caused
> it to be called also available somewhere.
> 
> (Come to think of it, it'd be nice to be able to re-implement stuff like
> self-insert-unmeta in user code, so the "input key sequence" would be a
> nice thing to have available in *all* ZLE widget functions.)

The patch below makes the characters typed available to widgets in the 
variable `keys (that may be too short a name to make is special in
the shell). The variable is an array containing one element per
character typed. The elements look like the stuff you always get back
from zle for key-sequences, i.e.: `a', `^A', `M-a', `M-^a', and so on.

What this patch does not do, however, is to implement the suggestion
for `-r ...' Bart made.

The easiest way to do this is to add a function-pointer-variable in
the zle module that will be called whenever zle thinks that a suffix
should be removed. The completion module sets this variable whenever
it needs it to the address of a function that calls the given shell
function.

This is easy to implement, bu somehow I think that we probably should
take this as an example for a more gerneral problem (calling functions 
in sub-modules from modules they depend upon), and solve that one.

What I'm thinking about is some kind of hook-mechanism. Giving modules 
the possibility to register functions that should be called whenever
some event happens. Other modules can define the hooks for the events
they generate and call a supplied function (runhooks() or whatever) to 
call all functions registered for this hook.

By making the description of the hooks contain a `char *name' this
could also easily exposed to user level to let users register shell
function to be executed when a hook is run. The builtin to control
this could be added in a separate module, of course.

Just to allow these suffix-removal functions, implementing such a
hook-mechanism would be overkill, of course, especially since there is 
already a lot of calling back and forth going on between zle and the
completion module. But somehow I have a feeling that this could be
interesting to have...

Having said that, I'll just wait a bit to see if I get any replies.

Bye
 Sven

diff -u os/Zle/zle_keymap.c Src/Zle/zle_keymap.c
--- os/Zle/zle_keymap.c	Fri Feb  5 20:39:30 1999
+++ Src/Zle/zle_keymap.c	Fri Feb  5 21:33:02 1999
@@ -108,7 +108,9 @@
 
 /* key sequence reading data */
 
-static char *keybuf;
+/**/
+char *keybuf;
+
 static int keybuflen, keybufsz = 20;
 
 /* last command executed with execute-named-command */
diff -u os/Zle/zle_params.c Src/Zle/zle_params.c
--- os/Zle/zle_params.c	Fri Feb  5 20:39:30 1999
+++ Src/Zle/zle_params.c	Fri Feb  5 22:07:09 1999
@@ -65,6 +65,8 @@
         zleunsetfn, NULL },
     { "LASTWIDGET", PM_SCALAR | PM_READONLY, NULL, FN(get_lwidget),
         zleunsetfn, NULL },
+    { "keys", PM_ARRAY | PM_READONLY, NULL, FN(get_keys),
+        zleunsetfn, NULL },
     { NULL, 0, NULL, NULL, NULL, NULL }
 };
 
@@ -215,4 +217,30 @@
 get_lwidget(Param pm)
 {
     return (lbindk ? lbindk->nam : "");
+}
+
+/**/
+static char **
+get_keys(Param pm)
+{
+    char **r, **q, *p, *k, c;
+
+    r = (char **) halloc((strlen(keybuf) + 1) * sizeof(char *));
+    for (q = r, p = keybuf; (c = *p); q++, p++) {
+	k = *q = (char *) halloc(5);
+	if (c & 0x80) {
+	    *k++ = 'M';
+	    *k++ = '-';
+	    c &= 0x7f;
+	}
+	if (c < 32 || c == 0x7f) {
+	    *k++ = '^';
+	    c ^= 64;
+	}
+	*k++ = c;
+	*k = '\0';
+    }
+    *q = NULL;
+
+    return r;
 }
--- od/Zsh/zle.yo	Mon Feb  8 12:14:54 1999
+++ Doc/Zsh/zle.yo	Mon Feb  8 12:49:25 1999
@@ -147,6 +147,13 @@
 item(tt(LASTWIDGET) (scalar))(
 The name of the last widget that was executed.
 )
+vindex(keys)
+item(tt(keys) (array))(
+The keys typed to invoke this widget, one element per
+key. Control-keys are reported with a leading `tt(^)', as in `tt(^A)',
+and meta-keys are repoted with a leading `tt(M-)', as in `tt(M-a)' and 
+`tt(M-^A)'.
+)
 enditem()
 sect(Standard Widgets)
 cindex(widgets, standard)

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