Re: PATCH: predict-on (Re: Completeinword and ambiguous completions)

Re: PATCH: predict-on (Re: Completeinword and ambiguous completions)

[Sven Wischnowsky]

Bart Schaefer wrote:

> [ ... ] What I want to do is described precisely by:
> 
> (0) Assume no global compmatchers.
> (1) Generate the possible matches at the current cursor position as
>     if for expand-or-complete-prefix, i.e. ignoring what follows.
> (2) Compute the common prefix of those matches.
> (3) If the common prefix matches what follows on the line, move the
>     cursor to the end of the common prefix, else no change.
> (4) Recompute matches at this (new?) position as if for completeinword.
> (5) If exactly one, insert it and put the cursor at the end of it.
> (5) Else if none, move the cursor back to the original position.
> (6) Otherwise (and if autolist) list the matches from (4).

Haven't tried, but:

1) write a simple pseudo-completer which only does:

    SUFFIX=''
    compstate[list]=''
    compstate[insert]=''
    return 1

   I.e. make the completion code only test for matches.

2) in the prediction function call the completion code with this
   completer as the first argument and all other completer you want to 
   use as other arguments

3) After that you have the unambiguous prefix in
   `_lastcomp[unambiguous]'. With `compmatchers' out of the way it
   should really be only a prefix in most cases, only functions like
   `_path_files' and functions that use their own `-M' flags may result 
   in unambiguous strings which are not only prefixes. But a bit of
   comparing that string to the stuff on the line (the prefix used by
   the completion system is saved in `_lastcomp[prefix]') and probably
   cutting `_lastcomp[unambiguous]' at the `_lastcomp[unambiguous_cursor]'
   position may reveal that.

4) Now cut off the original prefix from the unambiguous string and
   compare the rest to the beginning of `RBUFFER'. If it matches,
   move forward and try completion (without the dummy completer)
   again.

5) Then you can look at `_lastcomp[nmatches]' to see if there were
   matches.

I think this should work... but maybe I'm overlooking something.

Bye
 Sven


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

Re: PATCH: predict-on (Re: Completeinword and ambiguous completions)

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Oct 21,  9:10am, Sven Wischnowsky wrote:
> } Subject: Re: Completeinword and ambiguous completions
> }
> } Bart Schaefer wrote:
> } > zsh% setopt prompt
> } > (feep, cursor stays on "m")
> } > 
> } > What I'd like is, in the first of those cases, the cursor doesn't stay
> } > on the "m" but rather moves to the end of the unambiguous prefix, so that
> } > I can immediately start menu completion for the rest of the word.
> } 
> }   compmatchers=('' 'r:|=*')
> } 
> } Is that good enough?
> 
> It seems to work some, but not all, of the time.  For example:
> 
> zagzig<4> setopt promptt
> 
> If the cursor is on the second `t' there are two possible completions
> (promptsubst and promptpercent).  So when the cursor is on the `m' I
> expect TAB to move it to the second `t'.  Instead I get a feep.

Ugh. The completion code doesn't try to do that at all, right.

You can try the (probably expensive):

  compmatchers=('r:|?=* r:|=*')

of course. This works for me at least with your example. Another way
would be to try completion again and again while moving the
cursor. But that would even be more expensive.

> Maybe the following will explain why I'm interested in this.  I want to
> press TAB in the middle of a predictivly-inserted line to jump ahead to
> the next spot where I might want to edit.

Almost-DWIM?

Bye
 Sven


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

Re: PATCH: predict-on (Re: Completeinword and ambiguous completions)

[Bart Schaefer]

On Oct 22,  8:40am, Sven Wischnowsky wrote:
} Subject: Re: PATCH: predict-on (Re: Completeinword and ambiguous completio
}
} Bart Schaefer wrote:
} 
} > On Oct 21,  9:10am, Sven Wischnowsky wrote:
} > } Subject: Re: Completeinword and ambiguous completions
} > }
} > }   compmatchers=('' 'r:|=*')
} > } 
} > } Is that good enough?
} > 
} > It seems to work some, but not all, of the time.  For example:
} > 
} > zagzig<4> setopt promptt
} > 
} > If the cursor is on the second `t' there are two possible completions
} > (promptsubst and promptpercent).  So when the cursor is on the `m' I
} > expect TAB to move it to the second `t'.  Instead I get a feep.
} 
} Ugh. The completion code doesn't try to do that at all, right.
} 
} You can try the (probably expensive):
} 
}   compmatchers=('r:|?=* r:|=*')
} 
} of course. This works for me at least with your example.

No, that's far too aggressive.  If I drop that into predict-on, I can't
type anything -- it erases the whole line and makes me start over every
character or two, or else I get weird stuff like this:

zagzig<6> seto          
_bash_completions        kpsetool                 setmetamode            
_history_complete_word   netscape-communicator    setopt                 
_set_options             restoretextmode          setsysfont             
_setopt                  savetextmode             setup_compinit         
_unset_options           setclock                 unsetopt               
_unsetopt                setconsole               xsetmode               
_user_at_host            setfont                  xsetpointer            
_x_selection_timeout     setkeycodes              xsetroot               

If I hack up insert-and-predict to reset compmatchers locally, then it
works again until I get to this point with cursor on the "o":

zagzig<6> setopt

If I now press TAB, I get

zagzig<4> setopt        
_set_options     _unset_options   setopt           unsetopt       
_setopt          _unsetopt        setup_compinit                  

with the cursor moved back to the "s".  I never want the cursor to move
backwards.

(setup_compinit is a function I use to force compinit to read functions
out of the current zsh build tree rather than out of the install.)

} Another way
} would be to try completion again and again while moving the
} cursor. But that would even be more expensive.

It's also not what I want.  What I want to do is described precisely by:

(0) Assume no global compmatchers.
(1) Generate the possible matches at the current cursor position as
    if for expand-or-complete-prefix, i.e. ignoring what follows.
(2) Compute the common prefix of those matches.
(3) If the common prefix matches what follows on the line, move the
    cursor to the end of the common prefix, else no change.
(4) Recompute matches at this (new?) position as if for completeinword.
(5) If exactly one, insert it and put the cursor at the end of it.
(5) Else if none, move the cursor back to the original position.
(6) Otherwise (and if autolist) list the matches from (4).

I don't care about any other possible completions between the start
position and the end of the common prefix, and don't want to consider
them as possible matches.

} > Maybe the following will explain why I'm interested in this.  I want to
} > press TAB in the middle of a predictivly-inserted line to jump ahead to
} > the next spot where I might want to edit.
} 
} Almost-DWIM?

Yes.  Even without the stuff I'm asking about above, this works very
nicely -- I like it MUCH better than incremental-complete-word, because
it's modeless:  I never have to accept a completion and then accept the
line -- I can accept the line immediately at any time, or hit TAB to go
through the normal completion process on the current word, or just keep
typing to have the completion incrementally change for me.

Here's a follow-on patch to fix a logic-error in the last one and to
back out compmatchers (at least for now):

Index: Functions/Zle/predict-on
===================================================================
@@ -25,19 +25,17 @@
 # error message.
 
 predict-on() {
-    setopt localoptions nounset noksharrays
+    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
-    [[ $compmatchers[2] != 'r:|=*' ]] &&
-      compmatchers=('' 'r:|=*' $compmatchers)
+    zle -N delete-char-or-list delete-no-predict
 }
 predict-off() {
-    setopt localoptions nounset noksharrays
+    setopt localoptions unset noksharrays
     zle -A .self-insert self-insert
     zle -A .magic-space magic-space
     zle -A .backward-delete-char backward-delete-char
-    [[ $compmatchers[2] != 'r:|=*' ]] || shift 2 compmatchers
 }
 insert-and-predict () {
   emulate -L zsh
@@ -75,11 +73,14 @@
       zle .history-beginning-search-forward || RBUFFER=""
       return 0
     else
-      # Depending on preference, you might call "predict-off" here,
-      # and also set up forward deletions to turn off prediction.
+      # Depending on preference, you might call "predict-off" here.
       LBUFFER="$LBUFFER[1,-2]"
     fi
   fi
+}
+delete-no-predict() {
+  predict-off
+  zle .$WIDGET "$@"
 }
 
 [[ -o kshautoload ]] || predict-on "$@"

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

Re: Completeinword and ambiguous completions

[Sven Wischnowsky]

Bart Schaefer wrote:

> Consider the following situation:
> 
> zsh% setopt completeinword
> zsh% setopt pro<TAB>
> zsh% setopt prompt<TAB>
> promptbang     promptcr       promptpercent  promptsubst    promptvars
> 
> Note that the prefix "prompt" is unambiguous.  Now consider what happens
> if the cursor is over the "m" when TAB is hit in each of these cases:
> 
> zsh% setopt prompt
> (feep, cursor stays on "m")
> zsh% setopt promptvars
> zsh% setopt promptvars
> (cursor is one space past end of word)
> 
> What I'd like is, in the first of those cases, the cursor doesn't stay
> on the "m" but rather moves to the end of the unambiguous prefix, so that
> I can immediately start menu completion for the rest of the word.  The
> following almost does it:

That's a case for global match specs, since what you want is that the
code finds out that you are in a prefix for possible matches and moves 
you at the end of the unambiguous string. Since completeinword
normally doesn't test this, but instead looks only for strings ending
with the stuff after the cursor, it doesn't help. But with:

  compmatchers=('r:|=*')

It takes the string from the line only as a prefix, builds the
possible matches you were expecting and puts you at the place were
something is missing, i.e. the end in your example.

This is then independent of the setting of completeinword (at least in 
this example). And, of course, you may prefer to use:

  compmatchers=('' 'r:|=*')

to first try to generate matches without this strings-is-a-prefix
behaviour.


Is that good enough?

Bye
 Sven


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

PATCH: predict-on (Re: Completeinword and ambiguous completions)

[Bart Schaefer]

On Oct 21,  9:10am, Sven Wischnowsky wrote:
} Subject: Re: Completeinword and ambiguous completions
}
} Bart Schaefer wrote:
} > zsh% setopt prompt
} > (feep, cursor stays on "m")
} > 
} > What I'd like is, in the first of those cases, the cursor doesn't stay
} > on the "m" but rather moves to the end of the unambiguous prefix, so that
} > I can immediately start menu completion for the rest of the word.
} 
}   compmatchers=('' 'r:|=*')
} 
} Is that good enough?

It seems to work some, but not all, of the time.  For example:

zagzig<4> setopt promptt

If the cursor is on the second `t' there are two possible completions
(promptsubst and promptpercent).  So when the cursor is on the `m' I
expect TAB to move it to the second `t'.  Instead I get a feep.

Maybe the following will explain why I'm interested in this.  I want to
press TAB in the middle of a predictivly-inserted line to jump ahead to
the next spot where I might want to edit.

Index: Functions/Zle/predict-on
===================================================================
@@ -1,31 +1,43 @@
 # This set of functions implements a sort of magic history searching.
 # After predict-on, typing characters causes the editor to look backward
-# in the history for the first line beginning with what you have typed
-# so far.  After predict-off, editing returns to normal for the line found.
+# in the history for the first line beginning with what you have typed so
+# far.  After predict-off, editing returns to normal for the line found.
 # In fact, you often don't even need to use predict-off, because if the
-# line doesn't match something in the history, adding a key at the end
-# behaves as normal --- though editing in the middle is liable to delete
+# line doesn't match something in the history, adding a key performs
+# standard completion --- though editing in the middle is liable to delete
 # the rest of the line.
 #
+# The setting of compmatchers means that if you use the completion system,
+# you should be able to type TAB at almost any point to advance the cursor
+# to the next "interesting" character position (usually the end of the
+# current word, but sometimes somewhere in the middle of the word).  And
+# of course as soon as the entire line is what you want, you can accept
+# with RETURN, without needing to move the cursor to the end first.
+#
 # To use it:
 #   autoload -U predict-on
 #   zle -N predict-on
 #   zle -N predict-off
 #   bindkey '...' predict-on
 #   bindkey '...' predict-off
-# Note that all the functions are defined when you first call type the
-# predict-on key, which means typing the predict-off key before that gives
-# a harmless error message.
+# 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.
 
 predict-on() {
+    setopt localoptions nounset noksharrays
     zle -N self-insert insert-and-predict
     zle -N magic-space insert-and-predict
     zle -N backward-delete-char delete-backward-and-predict
+    [[ $compmatchers[2] != 'r:|=*' ]] &&
+      compmatchers=('' 'r:|=*' $compmatchers)
 }
 predict-off() {
+    setopt localoptions nounset noksharrays
     zle -A .self-insert self-insert
     zle -A .magic-space magic-space
     zle -A .backward-delete-char backward-delete-char
+    [[ $compmatchers[2] != 'r:|=*' ]] || shift 2 compmatchers
 }
 insert-and-predict () {
   emulate -L zsh
@@ -37,7 +49,16 @@
     LBUFFER="$LBUFFER$KEYS"
     if [[ $LASTWIDGET == (self-insert|magic-space|backward-delete-char) ]]
     then
-      zle .history-beginning-search-backward || RBUFFER=""
+      if ! zle .history-beginning-search-backward
+      then
+	RBUFFER=""
+	if [[ ${KEYS[-1]} != ' ' ]]
+	then
+	  integer curs=$CURSOR
+	  zle complete-word
+	  CURSOR=$curs
+	fi
+      fi
     fi
   fi
   return 0

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