zsh-workers
 help / color / mirror / code / Atom feed
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: compadd -r
Date: Mon, 8 Feb 1999 13:17:20 +0100 (MET)	[thread overview]
Message-ID: <199902081217.NAA27404@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: "Bart Schaefer"'s message of Tue, 2 Feb 1999 01:59:16 -0800


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


             reply	other threads:[~1999-02-08 12:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-02-08 12:17 Sven Wischnowsky [this message]
1999-02-08 17:37 ` Bart Schaefer
1999-02-09  8:20 Sven Wischnowsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199902081217.NAA27404@beta.informatik.hu-berlin.de \
    --to=wischnow@informatik.hu-berlin.de \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).