PATCH: cursor position after completion

PATCH: cursor position after completion

[Sven Wischnowsky]

With `option_prefix=yes' and a global match spec `r:|-=*' trying
completion on things like `pnmpad -<TAB>' in a directory like the zsh
`Src' directory gives you the options and all files containing a
hyphen. Then the completion code positions the cursor on the first
place where characters are missing which is before (on) the `-' in
this case.

Since this has annoyed me for too long now, the patch below makes the
cursor be placed on the last position where characters are missing or
differ. I hope that this gets it right in more cases than the previous 
code, although it isn't perfect either. Unfortunately, placing it at
the position where the greatest number of matches differ is impossible 
since we can't really detect this without comparing the parts of all
matches separately, which is too expensive.

Bye
 Sven

diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Thu Sep  2 11:39:18 1999
+++ Src/Zle/zle_tricky.c	Thu Sep  2 12:59:52 1999
@@ -7348,7 +7348,7 @@
 		    inststrlen(s->line, 1, s->llen);
 		else
 		    inststrlen(s->word, 1, s->wlen);
-		if (d < 0 && (s->flags & CLF_DIFF))
+		if (s->flags & CLF_DIFF)
 		    d = cs;
 		if (ins) {
 		    li += s->llen;
@@ -7363,7 +7363,7 @@
 	}
 	/* Remember the position if this is the first prefix with
 	 * missing characters. */
-	if (pm < 0 && (l->flags & CLF_MISS) && !(l->flags & CLF_SUF))
+	if ((l->flags & CLF_MISS) && !(l->flags & CLF_SUF))
 	    pm = cs;
 	pcs = cs;
 	/* Insert the anchor. */
@@ -7384,7 +7384,7 @@
 	if (l->flags & CLF_MISS) {
 	    if (l->flags & CLF_MID)
 		b = cs;
-	    else if (sm < 0 && (l->flags & CLF_SUF))
+	    else if (l->flags & CLF_SUF)
 		sm = cs;
 	}
 	/* And now insert the suffix or the original string. */
@@ -7402,10 +7402,11 @@
 	    }
 	} else {
 	    int hp = 0, hs = 0;
+	    Cline js = NULL;
 
 	    for (j = -1, i = 0, s = l->suffix; s; s = s->next) {
 		if (j < 0 && (s->flags & CLF_DIFF))
-		    j = i;
+		    j = i, js = s;
 		if (s->flags & CLF_LINE) {
 		    inststrlen(s->line, 0, s->llen);
 		    i += s->llen; pcs = cs + s->llen;
@@ -7428,7 +7429,7 @@
 	    if (hs)
 		spos += i;
 	    cs += i;
-	    if (d < 0 && j >= 0)
+	    if (j >= 0)
 		d = cs - j;
 	}
 	/* If we reached the right positions, re-insert the braces. */

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

Re: PATCH: cursor position after completion

[Sven Wischnowsky]

Felix Rosencrantz wrote:

> I would like to request a different solution to cursor positioning with
> completion and matching control.

I found myself in situations where I wanted that, too (after the patch)...

> When I'm completing filenames where matching control occurs, I'd prefer
> the cursor to move to the position of the first place where characters
> are missing, not the last.  If I'm completing something that might be 
> an option I would like to have it put me in the last position.

... but I don't think the type of completion is the right thing to base the
decision upon.

> So to me the questions are:
> 
>    How should ZSH decide at which matching hot spot to leave the cursor?
> 
>    If it makes the wrong choice, is there a better way for the user to
>    correct the position and continue completing?
> 
> It seems that there should be a more intuitive solution.  I think there
> are alternatives to counting matches.
> 
> Maybe a simple mechanism that would allow the user to cycle the
> cursor through the matching hot spots of a word.  Maybe before menu
> completion kicks in the cursor could be moved to the different hot
> spots.  Though this might be annoying, too.

And since a cycle is endless this doesn't seem to make much sense to
me. We could add a builtin widget which doesn't break the current
completion state and cycles through the positions or we add a special
array available only in widgets containing the positions so that we
could write a shell function widget doing anything that may seem
useful (or two widget: move backward and forward to the previous/next
interesting position).

> Maybe it would it be useful if there was a parameter to configure if you
> prefer the cursor to be positioned at the first or last hot spot.
> Or maybe the matching control specifications could be enhanced with cursor
> positioning rules.

That's another idea I hadn't thought about. But I can't think of
*what* we could make expressible this way.

>
> ...
> 
> I guess I just want it to dwim.  One of the reasons, I moved from tcsh to zsh,
> is that zsh does matching control, that handles partial completion &
> case-sensitivity issues so much better.  But this new behavior doesn't feel
> quite right.

Yes, it's hard to find the right thing. I'd like to hear about any
ideas any of you have about this. Or just observations and
descriptions of the circumstances when the code did the wrong thing.

Every help with this is very much appreciated.

Bye
 Sven


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

Re: PATCH: cursor position after completion

[Felix Rosencrantz]

I would like to request a different solution to cursor positioning with
completion and matching control.

When I'm completing filenames where matching control occurs, I'd prefer
the cursor to move to the position of the first place where characters
are missing, not the last.  If I'm completing something that might be 
an option I would like to have it put me in the last position.

So to me the questions are:

   How should ZSH decide at which matching hot spot to leave the cursor?

   If it makes the wrong choice, is there a better way for the user to
   correct the position and continue completing?

It seems that there should be a more intuitive solution.  I think there
are alternatives to counting matches.

Maybe a simple mechanism that would allow the user to cycle the
cursor through the matching hot spots of a word.  Maybe before menu
completion kicks in the cursor could be moved to the different hot
spots.  Though this might be annoying, too.

Maybe it would it be useful if there was a parameter to configure if you
prefer the cursor to be positioned at the first or last hot spot.
Or maybe the matching control specifications could be enhanced with cursor
positioning rules.

One problem with matching control is that it can leave the cursor deserted
at a position that doesn't allow you to make the choice you want to
make.  For example
	% mkdir /tmp/test
	% cd /tmp/test
	% touch zsh3.1.6-pws-3  zsh3.1.6-test-3 zsh3.1.6-test-3_debug
	% compctl -M 'r:|[.,_-]=*'
	% more zsh[] 		#Hit TAB and you get:
	% more zsh3.1.6--3[]

But if you wanted the zsh3.1.6-pws-3 you have to move the cursor up to the
position between the minus signs.

I guess I just want it to dwim.  One of the reasons, I moved from tcsh to zsh,
is that zsh does matching control, that handles partial completion &
case-sensitivity issues so much better.  But this new behavior doesn't feel
quite right.

-FR.
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com