Re: PATCH: predict-on: suppress long listings

Re: PATCH: predict-on: suppress long listings

[Sven Wischnowsky]

Bart Schaefer wrote:

> This is based on Sven's suggestion from 8399.  Also deletes two extraneous
> setopts.  Requires two patches I posted previously in 8364 and 8373.

May I pour some compconfig over this?

Also, this didn't really work together with AUTO_MENU, it started that 
too early (if it had just attempted completion). For now I've unset it 
in predict-on and restore it in predict-off, but there must be a
better solution.

Also, with a global match spec with partial-word stuff, the behavior
of always returning to the previous cursor position was clearly
wrong. With something like `Zle/z..' (and `r:.=*') this inserted
`Zle/zle.' and the dots typed simply vanished into thin air. Very
distracting. I've added the `predict_cursor' key for this. The value
`key' is probably the best for this (or the value `complete' which
uses `key' as a fallback). Looks much better for someone like me who
has gotten used to only type word parts nowadays.

And with a more sophisticated `completer' key, things sometimes just
got too slow and irritating (when it started to correct and things
like that), so there is now also `predict_completer'. I know that this 
defeats the purpose to make the string shown the one one could get by
typing tab, but still...

The last key, `predict_list', is probably not needed, but with the
usual behavior of showing a list below the command line, I find it
somewhat irritating when it suddenly stops doing so only because we
have reached the state where only one match is left.

I hope all this isn't completely the kind of stuff you didn't want to
have in predict-on...

Bye
 Sven

diff -u of/Zle/predict-on Functions/Zle/predict-on
--- of/Zle/predict-on	Wed Oct 27 15:41:45 1999
+++ Functions/Zle/predict-on	Wed Oct 27 15:53:26 1999
@@ -23,17 +23,28 @@
 # Note that all functions are defined when you first type the predict-on
 # key, which means typing the predict-off key before that gives a harmless
 # error message.
+#
+# This uses the configuration keys starting with `predict_'.
 
 predict-on() {
-    zle -N self-insert insert-and-predict
-    zle -N magic-space insert-and-predict
-    zle -N backward-delete-char delete-backward-and-predict
-    zle -N delete-char-or-list delete-no-predict
+  zle -N self-insert insert-and-predict
+  zle -N magic-space insert-and-predict
+  zle -N backward-delete-char delete-backward-and-predict
+  zle -N delete-char-or-list delete-no-predict
+
+  # Prediction doesn't work well with automenu set, so we unset it here
+  # and restore it in predict-off().
+  if [[ -o automenu ]]; then
+    unsetopt automenu
+    _predict_am=yes
+  fi
 }
 predict-off() {
-    zle -A .self-insert self-insert
-    zle -A .magic-space magic-space
-    zle -A .backward-delete-char backward-delete-char
+  zle -A .self-insert self-insert
+  zle -A .magic-space magic-space
+  zle -A .backward-delete-char backward-delete-char
+
+  [[ -n $_predict_am ]] && setopt automenu
 }
 insert-and-predict () {
   emulate -L zsh
@@ -50,11 +61,33 @@
 	RBUFFER=""
 	if [[ ${KEYS[-1]} != ' ' ]]
 	then
-	  integer curs=$CURSOR
+	  integer curs=$CURSOR pos nchar=${#LBUFFER//[^${KEYS[-1]}]}
 	  local -a +h comppostfuncs
 	  comppostfuncs=( predict-limit-list )
-	  zle complete-word
-	  CURSOR=$curs
+	  zle complete-word ${(s.:.)compconfig[predict_completer]}
+	  # Decide where to leave the cursor. The dummy loop is used to
+	  # get out of that `case'.
+	  while true; do
+	    case $compconfig[predict_cursor] in
+	    (complete)
+	      # At the place where the completion left it, if it is after
+	      # the character typed.
+	      [[ ${LBUFFER[-1]} = ${KEYS[-1]} ]] && break
+	      ;&
+	    (key)
+	      # Or maybe at the n'th occurrence of the character typed.
+	      pos=${BUFFER[(in:nchar:)${KEYS[-1]}]}
+	      if [[ pos -gt curs ]]; then
+	        CURSOR=$pos
+	        break
+	      fi
+	      ;&
+	    (*)
+	      # Or else at the previous position.
+	      CURSOR=$curs
+	    esac
+	    break
+	  done
 	fi
       fi
     fi
@@ -91,6 +124,7 @@
     compstate[list]=''
     compstate[force_list]=yes
   fi
+  [[ $compconfig[predict_list] = always ]] && compstate[force_list]=yes
 }
 
 # Handle zsh autoloading conventions
diff -u olddoc/Zsh/compsys.yo Doc/Zsh/compsys.yo
--- olddoc/Zsh/compsys.yo	Wed Oct 27 10:42:47 1999
+++ Doc/Zsh/compsys.yo	Wed Oct 27 15:52:08 1999
@@ -1795,4 +1795,32 @@
 If set to a non-empty string, the matches will be listed on every
 key-press.
 )
+item(tt(predict_completer))(
+The keys starting with tt(predict_) are used by the functions in the
+tt(predict-on) file in the tt(Functions/Zle) directory of the tt(zsh)
+source distribution.
+
+A colon separated list of completer functions (like the tt(completer)
+key for normal completion) to be used when attempting completion.
+)
+item(tt(predict_cursor))(
+This describes where the cursor should be left after completion was
+attempted. If it is set to `tt(complete)' the cursor is left where
+completion put it if it is after the character typed, otherwise this
+behaves like the value `tt(key)'. If it is set to `tt(key)' the
+prediction function will try to place the cursor after the character
+which corresponds to the last character typed. This is useful if one
+uses global match specifications with patterns for partial word
+completion. If no sensible place could be found or this configuration
+key is set to any other value (or unset), the cursor is moved back to
+the original position. With global match specifications as described
+above this sometimes means that the character typed does not appear on 
+the line.
+)
+item(tt(predict_list))(
+If this is set to `tt(always)' the list of possible matches when
+completion was tried will always be shown, even if there is only one
+match. Otherwise the listing behavior is as usual, i.e. the list will
+only be shown if there are multiple matches.
+)
 enditem()

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

Re: PATCH: predict-on: suppress long listings

[Bart Schaefer]

On Oct 27,  4:03pm, Sven Wischnowsky wrote:
} Subject: Re: PATCH: predict-on: suppress long listings
}
} May I pour some compconfig over this?

Sure!  I've been hoping you'd get interested.

} Also, this didn't really work together with AUTO_MENU, it started that 
} too early (if it had just attempted completion). For now I've unset it 
} in predict-on and restore it in predict-off, but there must be a
} better solution.

There is -- just unset it inside insert-and-predict and let localoptions
restore it when that exits.  Does that not work?  I'm not sure how to
reproduce exactly the behavior you don't like, so I can't tell.

} Also, with a global match spec with partial-word stuff, the behavior
} of always returning to the previous cursor position was clearly
} wrong.

Ah, yes.  It also does odd things with certain characters, like if you
type $! you end up with $\! with the cursor on the backslash.  Probably
it should search rightwards until it finds the character you typed and
stay there, going back again if it doesn't find that character.

There's one other annoying thing if you can think of how to fix it.
Example:

zagzig% setopt automenu			<-- type this and hit return
zagzig% se				<-- then type this
zagzig% setopt automenu			<-- history-searches to this

Now you have "setopt automenu" on the command line with the cursor on
the "t".  If you press TAB, you get this:

zagzig% setopt  automenu		<-- note two spaces

with cursor on the second space.  I don't want it to insert the space
after the completion when there already is a space on the line!

} I hope all this isn't completely the kind of stuff you didn't want to
} have in predict-on...

No problem.  BTW, the keys I chose to bind this to are `^X/' (on) and
`^X.' (off).  Those are pretty obscure things in emacs (I'd never used
them) and unused by default in zsh.  I originally had it on ^X^R and
^X^T but one of the other completion widgets wants ^X^R.

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

Re: PATCH: predict-on: suppress long listings

[Bart Schaefer]

On Oct 27,  4:03pm, Sven Wischnowsky wrote:
} Subject: Re: PATCH: predict-on: suppress long listings
}
} The last key, `predict_list', is probably not needed, but with the
} usual behavior of showing a list below the command line, I find it
} somewhat irritating when it suddenly stops doing so only because we
} have reached the state where only one match is left.

Actually, to prevent the "do you wish" prompt we should check list_max
as well.  And here's the automenu change.

Index: Functions/Zle/predict-on
===================================================================
@@ -31,20 +31,11 @@
   zle -N magic-space insert-and-predict
   zle -N backward-delete-char delete-backward-and-predict
   zle -N delete-char-or-list delete-no-predict
-
-  # Prediction doesn't work well with automenu set, so we unset it here
-  # and restore it in predict-off().
-  if [[ -o automenu ]]; then
-    unsetopt automenu
-    _predict_am=yes
-  fi
 }
 predict-off() {
   zle -A .self-insert self-insert
   zle -A .magic-space magic-space
   zle -A .backward-delete-char backward-delete-char
-
-  [[ -n $_predict_am ]] && setopt automenu
 }
 insert-and-predict () {
   emulate -L zsh
@@ -61,6 +52,7 @@
 	RBUFFER=""
 	if [[ ${KEYS[-1]} != ' ' ]]
 	then
+	  unsetopt automenu
 	  integer curs=$CURSOR pos nchar=${#LBUFFER//[^${KEYS[-1]}]}
 	  local -a +h comppostfuncs
 	  comppostfuncs=( predict-limit-list )
@@ -120,11 +112,14 @@
 # of matches from forcing a "do you wish to see all ...?" prompt.
 
 predict-limit-list() {
-  if [[ compstate[list_lines]+BUFFERLINES -gt LINES ]]; then
+  if (( compstate[list_lines]+BUFFERLINES > LINES ||
+	compstate[nmatches] > compstate[list_max] ))
+  then
     compstate[list]=''
     compstate[force_list]=yes
+  elif [[ $compconfig[predict_list] = always ]]
+    compstate[force_list]=yes
   fi
-  [[ $compconfig[predict_list] = always ]] && compstate[force_list]=yes
 }
 
 # Handle zsh autoloading conventions

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

Re: PATCH: predict-on: suppress long listings

[Bart Schaefer]

How embarrassing.

Index: Functions/Zle/predict-on
===================================================================
@@ -118,6 +118,7 @@
     compstate[list]=''
     compstate[force_list]=yes
   elif [[ $compconfig[predict_list] = always ]]
+  then
     compstate[force_list]=yes
   fi
 }

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

Re: PATCH: predict-on: suppress long listings

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Oct 28, 10:03am, Sven Wischnowsky wrote:
> } Subject: Re: PATCH: predict-on: suppress long listings
> }
> } 
> } Bart Schaefer wrote:
> } 
> } > Ah, yes.  It also does odd things with certain characters, like if you
> } > type $! you end up with $\! with the cursor on the backslash.  Probably
> } > it should search rightwards until it finds the character you typed and
> } > stay there, going back again if it doesn't find that character.
> } 
> } That's what `compconf predict_cursor=key' tries to achieve.
> 
> Yeah, but it searches rightwards from the end rather than leftwards from
> the current cursor position.  Most of the time that's OK, I guess.

I hope it is actually better... I first did it from the left and then
tried something like `zl/zle_tr..' (I had a `zle_tricky.c.orig' at
that time). When searching from the left this put the cursor after the
`.' before the `c', not on the one the dot typed really corresponded to.

Bye
 Sven


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

Re: PATCH: predict-on: suppress long listings

[Bart Schaefer]

On Oct 28, 10:03am, Sven Wischnowsky wrote:
} Subject: Re: PATCH: predict-on: suppress long listings
}
} 
} Bart Schaefer wrote:
} 
} > Ah, yes.  It also does odd things with certain characters, like if you
} > type $! you end up with $\! with the cursor on the backslash.  Probably
} > it should search rightwards until it finds the character you typed and
} > stay there, going back again if it doesn't find that character.
} 
} That's what `compconf predict_cursor=key' tries to achieve.

Yeah, but it searches rightwards from the end rather than leftwards from
the current cursor position.  Most of the time that's OK, I guess.

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

Re: PATCH: predict-on: suppress long listings

[Sven Wischnowsky]

Bart Schaefer wrote:

> } Also, this didn't really work together with AUTO_MENU, it started that 
> } too early (if it had just attempted completion). For now I've unset it 
> } in predict-on and restore it in predict-off, but there must be a
> } better solution.
> 
> There is -- just unset it inside insert-and-predict and let localoptions
> restore it when that exits.  Does that not work?  I'm not sure how to
> reproduce exactly the behavior you don't like, so I can't tell.

No it doesn't fix it. The problem is: with my setup if I type `ls si'
I get the line `ls sig.' with the cursor on the `g'. If I now type TAB 
(with automenu set) it immediately starts menu-completion (or, in my
case, menu-selection -- which is even worse in this case). Instead I
just want it to move the cursor on the dot, where normal completion
would place it.

> } Also, with a global match spec with partial-word stuff, the behavior
> } of always returning to the previous cursor position was clearly
> } wrong.
> 
> Ah, yes.  It also does odd things with certain characters, like if you
> type $! you end up with $\! with the cursor on the backslash.  Probably
> it should search rightwards until it finds the character you typed and
> stay there, going back again if it doesn't find that character.

That's what `compconf predict_cursor=key' tries to achieve. The `!',
btw, is somewhat irritating anyway -- if it is interpreted as a
history reference. Well, it isn't irritating if you know why it
happens, but probably not what one wants. (But the point of this
prediction thing is probably trying to make bang-hist expressions
superfluous, I'm just used to using them...)

> There's one other annoying thing if you can think of how to fix it.
> Example:
> 
> zagzig% setopt automenu			<-- type this and hit return
> zagzig% se				<-- then type this
> zagzig% setopt automenu			<-- history-searches to this
> 
> Now you have "setopt automenu" on the command line with the cursor on
> the "t".  If you press TAB, you get this:
> 
> zagzig% setopt  automenu		<-- note two spaces
> 
> with cursor on the second space.  I don't want it to insert the space
> after the completion when there already is a space on the line!

This is similar to my automenu problem. What we need is a way to
control normal completion (not the one called by prediction)
works. For your problem we could simply use:

  [[ -n $hasspace && compstate[nmatches] -eq 1 ]] &&
      compstate[insert]=1

(Tricky, ain't it?)

For my problem we could use something like:

  [[ $LASTWIDGET != $WIDGET ]] && compstate[insert]=unambiguous

(I'm not completely sure that his would work...)

> } I hope all this isn't completely the kind of stuff you didn't want to
> } have in predict-on...
> 
> No problem.  BTW, the keys I chose to bind this to are `^X/' (on) and
> `^X.' (off).  Those are pretty obscure things in emacs (I'd never used
> them) and unused by default in zsh.  I originally had it on ^X^R and
> ^X^T but one of the other completion widgets wants ^X^R.

I use `^P' for -on and `^P^P' for -off.


In another message:

> Actually, to prevent the "do you wish" prompt we should check list_max
> as well.  And here's the automenu change.

But then we have to test the special value `0', too.


Bye
 Sven

diff -u of/Zle/predict-on Functions/Zle/predict-on
--- of/Zle/predict-on	Thu Oct 28 08:52:46 1999
+++ Functions/Zle/predict-on	Thu Oct 28 10:01:53 1999
@@ -113,7 +113,7 @@
 
 predict-limit-list() {
   if (( compstate[list_lines]+BUFFERLINES > LINES ||
-	compstate[nmatches] > compstate[list_max] ))
+	( compstate[list_max] != 0 && compstate[nmatches] > compstate[list_max] ) ))
   then
     compstate[list]=''
     compstate[force_list]=yes

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

PATCH: predict-on: suppress long listings

[Bart Schaefer]

This is based on Sven's suggestion from 8399.  Also deletes two extraneous
setopts.  Requires two patches I posted previously in 8364 and 8373.

The +h in "local -a +h comppostfuncs" is unnecessary, but just in case it
ever becomes a special as part of moving common completion ops into C ...

Index: Functions/Zle/predict-on
===================================================================
@@ -25,14 +25,12 @@
 # error message.
 
 predict-on() {
-    setopt localoptions unset noksharrays
     zle -N self-insert insert-and-predict
     zle -N magic-space insert-and-predict
     zle -N backward-delete-char delete-backward-and-predict
     zle -N delete-char-or-list delete-no-predict
 }
 predict-off() {
-    setopt localoptions unset noksharrays
     zle -A .self-insert self-insert
     zle -A .magic-space magic-space
     zle -A .backward-delete-char backward-delete-char
@@ -53,6 +51,8 @@
 	if [[ ${KEYS[-1]} != ' ' ]]
 	then
 	  integer curs=$CURSOR
+	  local -a +h comppostfuncs
+	  comppostfuncs=( predict-limit-list )
 	  zle complete-word
 	  CURSOR=$curs
 	fi
@@ -79,8 +79,20 @@
   fi
 }
 delete-no-predict() {
-  predict-off
+  [[ $WIDGET != delete-char-or-list || -n $RBUFFER ]] && predict-off
   zle .$WIDGET "$@"
 }
+
+# This is a helper function for autocompletion to prevent long lists
+# of matches from forcing a "do you wish to see all ...?" prompt.
+
+predict-limit-list() {
+  if [[ compstate[list_lines]+BUFFERLINES -gt LINES ]]; then
+    compstate[list]=''
+    compstate[force_list]=yes
+  fi
+}
+
+# Handle zsh autoloading conventions
 
 [[ -o kshautoload ]] || predict-on "$@"

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