Re: Using buffer for history-incremental-search-backward

Re: Using buffer for history-incremental-search-backward

[Felix Rosencrantz]

>} So is there anyway to history-incremental-search-backward (and
>} related commands to show a list of matching commands.  Sort of like
>} the w2k "F7" key in a cmd.exe window.)
>
>Not without interrupting the search.  But one could write a completion
>function that would do it; just search the $history hash:
>
>       compadd - "$history[(R)$BUFFER]"
>
>or something like that.

Maybe I'll play with that a little.  Though I was sort of under the
impression that the completion system could only complete a single word
at time, and not sets of words, like a previous command line would be.

I've sort of fancied the idea that zsh might have a completer for sets
of commandline args/flags at once.  For example, with the tar command it
would be possible to complete standard sets of flags that I use (e.g.
xzf, czf, xvf, etc.), which is possible since the flags are together as
a single word.  But what if I had a command that only has long options
that I wanted to complete all at once as a group ( for example for
GNU tar "--extract --gzip --file archive" , "--create --gzip --file
archive", etc.)  Can the completion system handle that?

Thanks very much, Bart, for your help with the h-i-s-b, it works just like I
want.

-JT.

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

Re: Using buffer for history-incremental-search-backward

[Bart Schaefer]

On Jul 5, 11:32pm, Felix Rosencrantz wrote:
} Subject: Re: Using buffer for history-incremental-search-backward
}
} I was sort of under the impression that the completion system could
} only complete a single word at time, and not sets of words, like a
} previous command line would be.

It is pretty much oriented around completing the current single word.
However, if that word happens to be the first one on the line (or the
first one in a "command position") then you can safely use that word
as a search key to complete entire commands.  You just need to use the
-U option of compadd to cause that word to be erased and replaced by
the command that was looked up.

For example, this may be enough for your w2k F7 key widget; I confess
not to know how anything on w2k really works:

    #compdef -k menu-select \e[18~
    (( CURRENT == 1 && $#words == 1 )) &&
    compadd -QU "${(@)history[(R)*$words[CURRENT]*]}"

You can try it without the `&& $#words == 1' part, too, but note that
it only completes when the cursor is in the first word.

One problem with the above is that it bypasses the completion function
system, so you don't get the benefit of all the context analysis that
goes on in _main_complete et al.  For that you need to tie in:

    #compdef -k menu-select \e[18~
    # The following depends on the FUNCTION_ARGZERO option.
    # Use the file base name instead of $0 if that's not set.
    if [[ $_comps[-command-] != $0 ]]; then
        # We've not been called before, so:
	#  set a trap to restore state safely ...
	trap "_comps[-command-]='$_comps[-command-]'" EXIT INT
	#  make ourself be called for command words ...
	_comps[-command-]=$0
	#  and then call the regular completion system.
	_main_complete
    else
	# The completion system has called us back; add matches.
	compadd -QU "${(@)history[(R)*$words[CURRENT]*]}"
    fi

} But what if I had a command that only has long options that I
} wanted to complete all at once as a group ( for example for GNU tar
} "--extract --gzip --file archive" , "--create --gzip --file archive",
} etc.) Can the completion system handle that?

As long as what you need to replace is only one word, the thing that
replaces it can have more than one word.

} Thanks very much, Bart, for your help with the h-i-s-b, it works just
} like I want.

You're welcome!

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Using buffer for history-incremental-search-backward

[Bart Schaefer]

On Jul 3, 11:14pm, Felix Rosencrantz wrote:
}
} I actually thought my h-i-s-b was still in the history
} search, it sort of looked like it from the trace output....

Unfortunately, all it manages to do is abort the search.  Really, even
when you name the widget history-incremental-search-backward, it's not
calling your widget after the first time ... it's calling the internal
one, until you break out of repeating the same search and start again.

} Though it would also be useful if there was a parameter that explicitly
} says you are in the mini-buffer (or whatever the mode is).

Unfortunately there really is no mini-buffer.  Each of the commands that
uses a "mini-buffer" implements it (and key reading for it) separately.

This could get worked on, though, now that we actually do have multiple
keymaps.

} So is there anyway to history-incremental-search-backward (and related
} commands to show a list of matching commands.  Sort of like the w2k "F7"
} key in a cmd.exe window.)

Not without interrupting the search.  But one could write a completion
function that would do it; just search the $history hash:

	compadd - "$history[(R)$BUFFER]"

or something like that.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Using buffer for history-incremental-search-backward

[Felix Rosencrantz]

>While `sleep' is running, zle is inactive and the regular tty driver
>is in control of the interpretation of input characters.  Chances are
>you have `stty ^R redisplay' or the like (probably as a default, rather
>than explicitly in any of your init files), so the tty driver consumes
>the ^R before zle gets started again.

Opps...  Should have caught that myself.  That was the problem.  (Also
just noticed that the zsh's default stty completer doesn't know the
names used by the GNU stty.)

The function you provided works great.  (The example has a typo missing
the "al".)  I actually thought my h-i-s-b was still in the history
search, it sort of looked like it from the trace output....

>Both of these things could be considered bugs.

I think you're right that LASTWIDGET should probably be set correctly.
Though it would also be useful if there was a parameter that explicitly
says you are in the mini-buffer (or whatever the mode is).  Also,
it would useful if zle had the ability to specify bindings in the
mini-buffer and to somehow bless widgets as being safe to use in the
mini-buffer.

Zle still has a lot of little rough edges, like these problems with the
mini-buffer, and others like with widgets that try to handle multiline
command.  Or because zle can't update the prompt, it's not possible to
write a widget that does a cd, and have the prompt be correct.


So is there anyway to history-incremental-search-backward (and related
commands to show a list of matching commands.  Sort of like the w2k "F7"
key in a cmd.exe window.)

Thanks.
-FR.

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

Re: Using buffer for history-incremental-search-backward

[Bart Schaefer]

On Jul 3, 12:30am, Felix Rosencrantz wrote:
} Subject: Using buffer for history-incremental-search-backward
}
} I'm trying to figure out how to use history-incremental-search-backward.
} 
} host% sleep 5
} ^Recho
} host% echo
} 
} So why doesn't the control-R register?

While `sleep' is running, zle is inactive and the regular tty driver is
in control of the interpretation of input characters.  Chances are you
have `stty ^R redisplay' or the like (probably as a default, rather than
explicitly in any of your init files), so the tty driver consumes the ^R
before zle gets started again.

} I tried to write a widget that can be dropped in the
} place of the builtin h-i-s-b.  The problem I've been having is how to
} determine if this is the initial call of h-i-s-b, or if it is in the
} middle of a search in progress.

Ordinarily that's what the LASTWIDGET parameter is for, but the behavior
after you already have started an incremental search is not what you'd
expect:  your widget has not been assigned to LASTWIDGET yet because the
(internal C) function for `zle history-incremental-search-backward' has
not yet returned!  So you have to fudge that yourself.

Then there's the additional problem that there is a limited set of key
bindings during the incremental search, and the binding for the h-i-s-b
widget is not one of them -- so you have to actually *name* your widget
`history-increment-search-backward', and refer to the real widget by its
"safe" name (with a leading dot) in the `zle' calls.

    history-increment-search-backward () {
        setopt localoptions unset
	if [[ -n "$doing_hisb" ]]; then
	    zle .history-incremental-search-backward
	else
	    local doing_hisb=yes
	    zle .history-incremental-search-backward "$BUFFER"
	fi
    }

Both of these things could be considered bugs.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Using buffer for history-incremental-search-backward

[Felix Rosencrantz]

I'm trying to figure out how to use history-incremental-search-backward.

I do this.
zsh -f
host% echo abc  > /dev/null
host% echo def  > /dev/null
host% echo ghi  > /dev/null
host% bindkey -e
host% sleep 5
^Recho
host% echo

So why doesn't the control-R register?  Regardless, there are times I
would like to take the initial contents of the current BUFFER and start
a h-i-s-b.  So I tried to write a widget that can be dropped in the
place of the builtin h-i-s-b.  The problem I've been having is how to
determine if this is the initial call of h-i-s-b, or if it is in the
middle of a search in progress.

Here's my current version:
h-i-s-b () {
        local saveBuf
        saveBuf=$BUFFER 
        BUFFER="" 
        zle history-incremental-search-backward $saveBuf
}
zle -N h-i-s-b h-i-s-b
bindkey "^R" h-i-s-b

The problem is that it doesn't properly handle the situation of being
called in the middle of the current search, like the builtin h.i.s.b.
does.

-FR.


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/