* Re: PATCH: predict-on (Re: Completeinword and ambiguous completions)
@ 1999-10-22 6:40 Sven Wischnowsky
1999-10-22 10:16 ` Bart Schaefer
0 siblings, 1 reply; 4+ messages in thread
From: Sven Wischnowsky @ 1999-10-22 6:40 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: PATCH: predict-on (Re: Completeinword and ambiguous completions)
1999-10-22 6:40 PATCH: predict-on (Re: Completeinword and ambiguous completions) Sven Wischnowsky
@ 1999-10-22 10:16 ` Bart Schaefer
0 siblings, 0 replies; 4+ messages in thread
From: Bart Schaefer @ 1999-10-22 10:16 UTC (permalink / raw)
To: Sven Wischnowsky, zsh-workers
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: PATCH: predict-on (Re: Completeinword and ambiguous completions)
@ 1999-10-22 12:29 Sven Wischnowsky
0 siblings, 0 replies; 4+ messages in thread
From: Sven Wischnowsky @ 1999-10-22 12:29 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Completeinword and ambiguous completions
@ 1999-10-21 7:10 Sven Wischnowsky
1999-10-21 16:40 ` PATCH: predict-on (Re: Completeinword and ambiguous completions) Bart Schaefer
0 siblings, 1 reply; 4+ messages in thread
From: Sven Wischnowsky @ 1999-10-21 7:10 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* PATCH: predict-on (Re: Completeinword and ambiguous completions)
1999-10-21 7:10 Completeinword and ambiguous completions Sven Wischnowsky
@ 1999-10-21 16:40 ` Bart Schaefer
0 siblings, 0 replies; 4+ messages in thread
From: Bart Schaefer @ 1999-10-21 16:40 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1999-10-22 12:29 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-10-22 6:40 PATCH: predict-on (Re: Completeinword and ambiguous completions) Sven Wischnowsky
1999-10-22 10:16 ` Bart Schaefer
-- strict thread matches above, loose matches on Subject: below --
1999-10-22 12:29 Sven Wischnowsky
1999-10-21 7:10 Completeinword and ambiguous completions Sven Wischnowsky
1999-10-21 16:40 ` PATCH: predict-on (Re: Completeinword and ambiguous completions) Bart Schaefer
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).