New compinstall and bindkey

New compinstall and bindkey

[Oliver Kiddle]

Firstly, the new compinstall doesn't seem to work very will when the
functions have been installed in subdirectories: It refuses to accepy
/usr/local/share/zsh/functions as the directory containing the
functions. I don't quite understand the reasoning behind making compinit
an autoloaded function which is unloaded. I'd prefer to have it in
/usr/local/share/zsh/functions and not in my fpath. Is it faster as a
function?

How do I bind a key to insert a new-line without doing an accept-line.
In the zed function it is done with bindkey "^M" self-insert-unmeta but
this binds it to return. I was hoping to bind it to Alt-Return.

Thanks

Oliver Kiddle

RE: New compinstall and bindkey

[Andrej Borsenkow]

>
> Firstly, the new compinstall doesn't seem to work very will when the
> functions have been installed in subdirectories: It refuses to accepy
> /usr/local/share/zsh/functions as the directory containing the
> functions. I don't quite understand the reasoning behind making compinit
> an autoloaded function which is unloaded. I'd prefer to have it in
> /usr/local/share/zsh/functions and not in my fpath. Is it faster as a
> function?
>

The reason I  didn't like sourcing compinit was that I hate to have any
dependencies on local installation place. Making it autoloaded function makes it
invariant:

autoload compinit; compinit

As I finally pointed out, there are other ways. One possibility is to define
parameter (say, COMPINIT) that holds full pathname of compinit (if it was
installed). In this case you could use

[[ -n "$COMPINIT" ]] && source "$COMPINIT"

I don't actualy care which one is used.

> How do I bind a key to insert a new-line without doing an accept-line.
> In the zed function it is done with bindkey "^M" self-insert-unmeta but
> this binds it to return. I was hoping to bind it to Alt-Return.
>

Hmmm ... in command line editing multiline input I can insert new line by
pressing ^V^J.

/andrej

new menu selection and Re: New compinstall and bindkey

[Oliver Kiddle]

I've now looked at the new selection for menu completion. Firstly,
thanks Sven: it's great. There is one thing I don't like. When I move
the cursors to highlight the string I want to complete to and press
return, the highlighting is removed but menu-completion continues so if
I press tab again, it cycles through the selections as opposed to
accepting my selection and going on to complete whatever is next.
 
I also have problems with an aixterm where the next item on the left is
highlighted in addition to the one on the right in some circumstances.

Andrej Borsenkow wrote:

> The reason I  didn't like sourcing compinit was that I hate to have any
> dependencies on local installation place. Making it autoloaded function makes it
> invariant:

That makes more sense now - thanks.

> Hmmm ... in command line editing multiline input I can insert new line by
> pressing ^V^J.

Thanks, bindkey -s "^[[100q" "^V^J" works very nicely.

Oliver Kiddle

Re: New compinstall and bindkey

[Bart Schaefer]

On Jun 29,  3:26pm, Andrej Borsenkow wrote:
} Subject: RE: New compinstall and bindkey
}
} > Firstly, the new compinstall doesn't seem to work very will when the
} > functions have been installed in subdirectories: It refuses to accepy
} > /usr/local/share/zsh/functions as the directory containing the
} > functions.

I was going to complain about this myself.  Not only that, but I somehow
managed to get it to set FPATH to a string consisting of a space-separated
list of the dirs in which the functions were installed.  (That made it as
easy as "vared fpath<RET><RET>" to get the path set correctly, but it sure
was confusing.)

} > How do I bind a key to insert a new-line without doing an accept-line.
} > In the zed function it is done with bindkey "^M" self-insert-unmeta but
} > this binds it to return. I was hoping to bind it to Alt-Return.
} >
} 
} Hmmm ... in command line editing multiline input I can insert new line by
} pressing ^V^J.

I can insert one with ESC-return, and though "bindkey -m" doesn't make that
equivalent to alt-return, "bindkey '\M-\C-M' self-insert-unmeta" does so.

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

Re: new menu selection and Re: New compinstall and bindkey

[Sven Wischnowsky]

I wrote:

> Oliver Kiddle wrote:
> 
> > I've now looked at the new selection for menu completion. Firstly,
> > thanks Sven: it's great. There is one thing I don't like. When I move
> > the cursors to highlight the string I want to complete to and press
> > return, the highlighting is removed but menu-completion continues so if
> > I press tab again, it cycles through the selections as opposed to
> > accepting my selection and going on to complete whatever is next.
> 
> This once was intentional, when menu-select was intended as a
> menu-completion add-on. Now that it is more of a replacement we should 
> probably change this.

I've just taken send-break for it. So: send-break leaves selection
and you'll be in normal menu-completion and accept-line leaves
selection and accepts the current match. Accepting is done as for a
completion with only one match.

With that you can do

  bindkey -M menuselect '^J' send-break

to have return continue with menu-completion

Ok? Or should the meaning of send-break and accept-line be changed
(meaning: should the default for return be changed)?


Andrej Borsenkow wrote:

> I wanted to write about this anyway. Unfortunately, current widget system is not
> well suited for programming (in user-defined widgets). Currently widgets mostly
> are "high-level" ones, that do fairly complex tasks. That was fine when all
> widgets were builtin ones. But now more of a low-level, primitive widgets are
> needed - that do some well defined atomic action. Good example is completion.
> What is needed is probably such primitives as next-match, previous-match,
> insert-match, exit-menu etc. Using these most of other tasks could be easily
> porgrammed with user-defined widgets - and if some prove universally useful,
> they could be implemented as builtin.

That's what I suggested when I sent my first widget-args-patch. The
problem is to find out the generic functions behind all the
widgets. Also I was mainly thinking about (and still prefer in some
cases) changing more builtin widgets to accept options to get a
specific behavior, e.g. by changing complete-word to be able to do
everything the other completion widgets can (and probably more) by
giving it the right options. I hadn't thought about splitting the
completion stuff -- probably because I know too much about the
completion code ;-)

Bye
 Sven

diff -u od/Zsh/mod_complist.yo Doc/Zsh/mod_complist.yo
--- od/Zsh/mod_complist.yo	Tue Jun 29 12:51:32 1999
+++ Doc/Zsh/mod_complist.yo	Thu Jul  1 11:21:53 1999
@@ -99,7 +99,10 @@
 Selecting matches is done by moving the mark around using the zle movement
 functions. The zle functions tt(send-break) and tt(accept-line) can be used
 to leave menu-selection, leaving the match currently inserted into the line
-in place. The functions tt(accept-and-hold) and
+in place. In the case of tt(accept-line), the match currently inserted
+will be accepted and the immediatly trying completion again will
+complete after it. Using tt(send-break) leaves menu-selection and
+continues with normal menu-completion. The functions tt(accept-and-hold) and
 tt(accept-and-menu-complete) can be used to accept the match currently
 inserted and continue inserting matches after that. Matches inserted this
 way can be removed by invoking the tt(undo) function. Keys bound to one of
@@ -118,4 +121,9 @@
 tt(bindkey) builtin command (see
 ifzman(zmanref(zshmodules))\
 ifnzman(noderef(The zle Module))\
-).
+). For example, to make the return key leave menu-selection and
+continue with normal menu-completion one can call
+
+indent(tt(bindkey -M menuselect '^J' send-break))
+
+after loading the tt(complist) module.
diff -u os/Zle/complist.c Src/Zle/complist.c
--- os/Zle/complist.c	Wed Jun 30 11:56:57 1999
+++ Src/Zle/complist.c	Thu Jul  1 11:22:17 1999
@@ -649,12 +649,12 @@
     Cmgroup *pg;
     Thingy cmd;
     Menustack u = NULL;
-    int i = 0;
+    int i = 0, acc = 0;
     char *s;
 
     if (dummy && (!(s = getsparam("SELECTMIN")) ||
 		  (dat && dat->num < atoi(s))))
-	return 1;
+	return 0;
 
     selectlocalmap(mskeymap);
     noselect = 0;
@@ -681,10 +681,12 @@
 
     getk:
 
-	if (!(cmd = getkeycmd()) || cmd == Th(z_sendbreak) ||
-	    cmd == Th(z_acceptline))
+	if (!(cmd = getkeycmd()) || cmd == Th(z_sendbreak))
 	    break;
-	else if (cmd == Th(z_acceptandhold) ||
+	else if (cmd == Th(z_acceptline)) {
+	    acc = 1;
+	    break;
+	} else if (cmd == Th(z_acceptandhold) ||
 		 cmd == Th(z_acceptandmenucomplete)) {
 	    Menustack s = (Menustack) zhalloc(sizeof(*s));
 
@@ -847,11 +849,16 @@
     selectlocalmap(NULL);
     mselect = -1;
     inselect = 0;
+    if (acc) {
+	menucmp = 0;
+	lastambig = 0;
+	do_single(*(minfo.cur));
+    }
     if (!noselect) {
 	showinglist = -2;
 	zrefresh();
     }
-    return noselect;
+    return (!noselect ^ acc);
 }
 
 /* The widget function. */
diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Wed Jun 30 11:56:59 1999
+++ Src/Zle/zle_tricky.c	Thu Jul  1 11:04:29 1999
@@ -108,7 +108,8 @@
 
 /* != 0 if we are in the middle of a menu completion */
 
-static int menucmp;
+/**/
+int menucmp;
 
 /* Information about menucompletion. */
 
@@ -346,7 +347,8 @@
  * on the second tab, a` la bash, and then automenu kicks in when     *
  * lastambig == 2.                                                    */
 
-static int lastambig;
+/**/
+int lastambig;
 
 /* This says what of the state the line is in when completion is started *
  * came from a previous completion. If the FC_LINE bit is set, the       *
@@ -1058,7 +1060,8 @@
 	dat.matches = amatches;
 	dat.num = nmatches;
 	dat.cur = NULL;
-	runhookdef(MENUSTARTHOOK, (void *) &dat);
+	if (runhookdef(MENUSTARTHOOK, (void *) &dat))
+	    menucmp = 0;
     }
     return ret;
 }

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

Re: new menu selection and Re: New compinstall and bindkey

[Sven Wischnowsky]

Oliver Kiddle wrote:

> I've now looked at the new selection for menu completion. Firstly,
> thanks Sven: it's great. There is one thing I don't like. When I move
> the cursors to highlight the string I want to complete to and press
> return, the highlighting is removed but menu-completion continues so if
> I press tab again, it cycles through the selections as opposed to
> accepting my selection and going on to complete whatever is next.

This once was intentional, when menu-select was intended as a
menu-completion add-on. Now that it is more of a replacement we should 
probably change this. Since I don't use it that much, I'll have to
ask: do all of you agree that it should be changed?
If we change it we should probably give another widget a special
meaning in menu-select so that we have one for the current behaviour
and one for `leave menu-selection and accept the current match'. With
that users could do a `bindkey -M menuselect ...' to get their
prefered behavior. So: any suggestions for which widget we should use?
(Remember that one couldn't use this widget to leave menu-select,
then.) And what should be the default?

> I also have problems with an aixterm where the next item on the left is
> highlighted in addition to the one on the right in some circumstances.

Hm. Never seen this, so I can't help here (we don't have AIXes here).

Bye
 Sven


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