From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9143 invoked from network); 11 Sep 1999 22:58:55 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 11 Sep 1999 22:58:55 -0000 Received: (qmail 25413 invoked by alias); 11 Sep 1999 22:58:39 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 2592 Received: (qmail 25406 invoked from network); 11 Sep 1999 22:58:36 -0000 From: "Bart Schaefer" Message-Id: <990911225831.ZM18771@candle.brasslantern.com> Date: Sat, 11 Sep 1999 22:58:31 +0000 In-Reply-To: <199909081527.RAA19661@paris.ifh.de> Comments: In reply to Peter Stephenson "Re: is there a mix of history-search-backward and history-beginning-search-backward" (Sep 8, 5:27pm) References: <199909081527.RAA19661@paris.ifh.de> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-users@sunsite.auc.dk Subject: Re: is there a mix of history-search-backward and history-beginning-search-backward MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 8, 5:27pm, Peter Stephenson wrote: > Subject: Re: is there a mix of history-search-backward and history-beginni > > I might put these in the Functions/Zle directory (after Bart has found out > whatever's wrong with them). I don't see anything wrong with them except that there doesn't seem to be any use of the "stat" local paramter. With a tad more cleverness, though, you can get away with only one function: function history-search-end { integer ocursor=$CURSOR if [[ $LASTWIDGET = history-beginning-search-*-end ]]; then # Last widget called set $hbs_pos. CURSOR=$hbs_pos else hbs_pos=$CURSOR fi if zle .${WIDGET%-end}; then # success, go to end of line zle .end-of-line else # failure, restore position CURSOR=$ocursor return 1 fi } zle -N history-beginning-search-backward-end history-search-end zle -N history-beginning-search-forward-end history-search-end While we're on the subject, I've been fooling with insert-and-predict. The version below seems to work pretty well, but the history-search-forward in delete-backward-and-predict is less than ideal because of zsh's habit of leaving edits behind in the history list until the next trashzle(). That means that if you do some editing and then continue searching backwards, when you search forward again you may find an edited history line, which is probably not what you want. Using ((-CURSOR)) rather than actually deleting the character minimizes this effect, but assignment to LBUFFER in either function can leave junk behind. Any clever fixes for this? I think this is now clean enough that you could actually run with predict turned on most of the time. 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 } predict-off() { zle -A .self-insert self-insert zle -A .magic-space magic-space zle -A .backward-delete-char backward-delete-char } insert-and-predict () { emulate -L zsh if [[ ${RBUFFER[1]} = ${KEYS[-1]} ]] then # same as what's typed, just move on ((++CURSOR)) else LBUFFER="$LBUFFER$KEYS" if [[ $LASTWIDGET == (self-insert|magic-space|backward-delete-char) ]] then zle .history-beginning-search-backward || RBUFFER="" fi fi return 0 } delete-backward-and-predict() { emulate -L zsh if [[ -n "$LBUFFER" ]] then # If the last widget was e.g. a motion, then probably the intent is # to actually edit the line, not change the search prefix. if [[ $LASTWIDGET == (self-insert|magic-space|backward-delete-char) ]] then ((--CURSOR)) 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. LBUFFER="$LBUFFER[1,-2]" fi fi } zle -N insert-and-predict zle -N predict-on zle -N predict-off -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com