Re: PATCH: predict-on: suppress long listings

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxxxx