Re: Problem with 'predict-on'

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mar 24,  5:18am, Thorsten Kampe wrote:
} 
} I'm testing the ZLE widget "predict-on" with...

predict-on is probably due for an overhaul.  It was written for 3.1.x
(I've forgotten which value of 'x') and only updated once about a year
ago.

} autoload -U predict-on; predict-on

} This means that predict-on is active by default.

Actually a better way to accomplish this is

zle-line-init() { predict-on }
zle -N zle-line-init

Calling predict-on in .zshrc means it's on for the very first prompt,
but zle-line-init makes sure it's on at the beginning of every prompt.

Ideally, predict-on would give an error if it is called anywhere other
than in a widget, but the zle-line-init special widget didn't exist
when predict-on was created.

} But there are some flaws with predict-on:

Yes, several.  You'll also notice that it doesn't interact very well
with "undo".  (PWS or Wayne, if you're reading this, advice on how to
fix that would be appreciated.)

I've also just noticed a new problem with backspacing, one which I'm
quite sure has appeared quite recently ... I'm reporting that in another
message to zsh-workers right now.

} first of all I can not backspace the first
} character I typed in the command line.

Yes, that's true.  If there isn't at least one character, there's no
basis for predictive typing.  So the choices would be to delete the
entire line when the first character is deleted, or ... I'm not sure
what.  If "delete the entire line" seems like the right thing, try
this patch:

Index: predict-on
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-4.0/Functions/Zle/predict-on,v
retrieving revision 1.2
diff -c -r1.2 predict-on
--- predict-on	15 Mar 2003 17:43:15 -0000	1.2
+++ predict-on	24 Mar 2004 16:08:52 -0000
@@ -120,6 +120,8 @@
       zle .history-beginning-search-forward || RBUFFER=""
       return 0
     fi
+  else
+    zle .kill-whole-line
   fi
 }
 delete-no-predict() {

However, that may not be very helpful until the history-search bug gets
fixed.

} Then pasting text via
} [Shift]-[Ins] doesn't turn off prediction (like it should[1]).

This probably means that ((PENDING)) doesn't work correctly on your
system, or that the implemention of Shift+Ins is such that the pasted
text does not appear as typeahead.

PENDING (integer)
     The number of bytes pending for input, i.e. the number of bytes
     which have already been typed and can immediately be read. On
     systems where the shell is not able to get this information, this
     parameter will always have a value of zero.  Read-only.

Unfortunately if insert-and-predict can't determine that there is more
than a single character being inserted, it doesn't know that a paste is
happening, and so doesn't turn itself off.