Tip of the day: previous command output

Tip of the day: previous command output

[Jesper Holmberg]

Someone asked for zsh tips a couple of weeks ago. Here's something I use
a lot. I got the basic idea from some user group somewhere, and then I've
tweaked the idea to suit my needs.

The motivation for the following snippet is the fact that I often do a 'find'
or a 'locate' to find some files I'm interested in, and then want to do some
action on one of the files I just found. This function provides a way to put
completions from the output of the previous command on the command line.

_jh-prev-result () {
    hstring=$(eval `fc -l -n -1`)
    set -A hlist ${(@s/
/)hstring}
    compadd - ${hlist}
}

zle -C jh-prev-comp menu-complete _jh-prev-result
bindkey '\ee' jh-prev-comp


What this does is that it repeats the previous command, saving the output
in a string. It then splits the output string on new-lines, and quotes
each element (so that for example file names containing spaces get
properly quoted). I then bind the function to a menu-complete-like widget,
so that I can step through the alternatives.

Test it together with 'loocate' or 'find'. Perhaps someone finds this
useful, and any suggestions for improvement would be appreciated.

Jesper

Re: Tip of the day: previous command output

[Bart Schaefer]

On Thu, 19 Aug 2004, Jesper Holmberg wrote:

> The motivation for the following snippet is the fact that I often do a 
> 'find' or a 'locate' to find some files I'm interested in, and then want 
> to do some action on one of the files I just found.
[...]
> What this does is that it repeats the previous command, saving the output
> in a string.

I use this little function [*] for a similar purpose:

    keep () {
        kept=()		# Erase old value in case of error on next line
        kept=($~*)
        print -Rc - $kept
    }
    alias keep='noglob keep '

Note that "kept" is deliberately not declared local.

E.g. I might do

     patch < zsh-workers_NNNN.diff
     keep **/*.(orig|rej)
     emacs ${${kept:#*.orig}:r}
     rm $kept

That way I don't have to redo the possibly-expensive recursive glob twice;
the result is all stashed in $kept where I can manipulate the file names
and pick out the ones I want to work on.

I haven't bothered to combine it with a completion key because I hardly
ever want one specific file or its unmodified name; I almost always end up
typing some kind of parameter substitution expression.


[*] OK, I'm fibbing.  I actually call it "show" but there's an MH command
by that name that zsh may try to do completion for, so I changed the name
for public consumption.

Re: Tip of the day: previous command output

[Andy Spiegl]

> I use this little function [*] for a similar purpose:
Great!  I was just about to post a followup asking how to do what Bart is
doing because I use find and locate a lot, too but then I usually do stuff
with the whole list of found files, not just one of them.

So I modified Barts "keep" to use
      kept=$($*)
instead of
      kept=($~*)

So that I can do
  keep locate -i pictures | grep -i thursday | grep -i png
  keep print $kept | grep too_dark
  qiv $kept

At least that's what I thought that would work.  But it doesn't.
The first keep prints out the found files but $kept doesn't contain the
list.

Help, where is my mistake?
 Andy.

-- 
                              o      _     _         _
  ------- __o       __o      /\_   _ \\o  (_)\__/o  (_)          -o)
  ----- _`\<,_    _`\<,_    _>(_) (_)/<_    \_| \   _|/' \/       /\\
  ---- (_)/ (_)  (_)/ (_)  (_)        (_)   (_)    (_)'  _\o_    _\_v
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Our continuing mission: To seek out knowledge of C, to explore strange
 UNIX commands and to boldly code where no one has a manpage 4... 

Re: Tip of the day: previous command output

[Bart Schaefer]

On Thu, 19 Aug 2004, Andy Spiegl wrote:

> So I modified Barts "keep" to use
>       kept=$($*)

Unless you also dropped the alias that prefixes keep with noglob, you 
still need $~*, and to make it an array you probably want

	kept=( $($~*) )

> So that I can do
>   keep locate -i pictures | grep -i thursday | grep -i png

I don't know whether you intended this, but [with your original edit] 
that's equivalent to

	kept=$(locate -i pictures)
	print -Rc - $kept | grep -i thursday | grep -i png

whereas I would guess that, rather, you meant

	kept=( $(locate -i pictures | grep -i thursday | grep -i png) )

There's no provision -- except via a zmodload'd module -- for creating a 
user-defined "precommand modifier" like (say) "time" or "coproc" that 
syntatically consumes an entire pipeline.  You'd have to use [inside 
"keep"]

	kept=( $(eval $*) )

[in this case NOT $~*] and write

	keep locate -i pictures \| grep -i thursday \| grep -i png

An alternative is to write "keep" this way:

    keep() {
	kept=()
	kept=( $~* )
	if [[ ! -t 0 ]]; then
	    while read line; do
		kept+=( $line )
	    done
	fi
	print -Rc - $kept
    }

Then you can write

	locate -i pictures | grep -i thursday | grep -i png | keep

and thanks to the magic of zsh running the last command of a pipe in the 
current shell when that command is a function or builtin, you get what you 
want in $kept.

Re: Tip of the day: previous command output

[Andy Spiegl]

> Unless you also dropped the alias that prefixes keep with noglob, you 
> still need $~*

Oops, I thought the ~ is only needed to make sure $* is treated as a
pattern?  Hm, but on the other hand...yes you are right, I _do_ want zsh to
expand the globs before executing the command.  Oh boy, I still have so
much to learn about zsh.  It's so wonderfully powerful but also pretty
complex.

What would be the difference if I dropped alias with the noglob and used $*
instead of $~*?  I guess zsh would expand the globs before calling the
function, right?  But the result should be the same or not?

> > So that I can do
> >   keep locate -i pictures | grep -i thursday | grep -i png
> 
> I don't know whether you intended this, but [with your original edit] 
> that's equivalent to
> 
> 	kept=$(locate -i pictures)
> 	print -Rc - $kept | grep -i thursday | grep -i png

Oooops again.  Thanks for pointing that out!
But still strange that $kept is empty afterwards!

> whereas I would guess that, rather, you meant
> 
> 	kept=( $(locate -i pictures | grep -i thursday | grep -i png) )
Yes, you are right of course.

Hm, wouldn't it be a nice feature in general to have zsh always remember
the output of the last command, i.e. an automagic "keep"?  I suppose that
many zsh user do what I do frequently: execute something and the execute it
again only to append more options like grep, cut, awk etc.  Would that be
very hard to implement?  Or are there other drawbacks like more memory
usage because some commands might have _a lot_ of output?  Hm, maybe it
should be done with a global size limit to avoid the latter problem.

Well, if that's not possible I'll use your alternative suggestion together
with a global alias "K" that I can simply append to a command line.

Thanks for your great help!
 Andy.

-- 
                              o      _     _         _
  ------- __o       __o      /\_   _ \\o  (_)\__/o  (_)          -o)
  ----- _`\<,_    _`\<,_    _>(_) (_)/<_    \_| \   _|/' \/       /\\
  ---- (_)/ (_)  (_)/ (_)  (_)        (_)   (_)    (_)'  _\o_    _\_v
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Bad or missing mouse driver. Spank the cat? (Y/N)

Re: Tip of the day: previous command output

[Vincent Lefevre]

On 2004-08-20 11:30:44 +0200, Andy Spiegl wrote:
> Hm, wouldn't it be a nice feature in general to have zsh always remember
> the output of the last command, i.e. an automagic "keep"?  I suppose that
> many zsh user do what I do frequently: execute something and the execute it
> again only to append more options like grep, cut, awk etc.  Would that be
> very hard to implement?  Or are there other drawbacks like more memory
> usage because some commands might have _a lot_ of output?  Hm, maybe it
> should be done with a global size limit to avoid the latter problem.

This would be nice, but I assume that there would be similar problems
to stderr coloring (if you remember the thread...).

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: Tip of the day: previous command output

[Andy Spiegl]

One more question for the gurus:

Now that I've got the list of lines (typically filenames) in $kept
how do I get them into the command line _quoted_.

I tried:
 insert-kept-result () {
   [[ -n "$kept" ]] && LBUFFER+=${(qqq)kept}
 }
 zle -N insert-kept-result
 bindkey '\er' insert-kept-result

But that puts quotes around the whole list of filenames instead of quotes
around every single filename, like so:
 "foo bar baz"  instead of  "foo" "bar" "baz"

Actually, ideally I'd like only filenames with spaces and special chars to
be quoted to avoid cluttering up the command line, but I assume that's even
tougher to do. :-(

Thanks,
 Andy.

-- 
                              o      _     _         _
  ------- __o       __o      /\_   _ \\o  (_)\__/o  (_)          -o)
  ----- _`\<,_    _`\<,_    _>(_) (_)/<_    \_| \   _|/' \/       /\\
  ---- (_)/ (_)  (_)/ (_)  (_)        (_)   (_)    (_)'  _\o_    _\_v
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Mitchell's Law of Committees:
  Any simple problem can be made insoluble if enough meetings are
  held to discuss it.  

Re: Tip of the day: previous command output

[Vincent Lefevre]

On 2004-08-20 14:12:02 +0200, Andy Spiegl wrote:
> Now that I've got the list of lines (typically filenames) in $kept
> how do I get them into the command line _quoted_.

And would it be possible to get a menu, in order to select one or
several filenames manually?

And how about typing a pattern somewhere in the command line, then
applying a function that replaces this pattern by the matching lines
(quoted) of $kept?

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: Tip of the day: previous command output

[Bart Schaefer]

On Fri, 20 Aug 2004, Andy Spiegl wrote:

> What would be the difference if I dropped alias with the noglob and used 
> $* instead of $~*?  I guess zsh would expand the globs before calling 
> the function, right?

Right.

>  But the result should be the same or not?

Should be the same.  Waiting to expand uses a little less memory.


On Fri, 20 Aug 2004, Vincent Lefevre wrote:

> On 2004-08-20 11:30:44 +0200, Andy Spiegl wrote:
> > Hm, wouldn't it be a nice feature in general to have zsh always remember
> > the output of the last command, i.e. an automagic "keep"?
> 
> This would be nice, but I assume that there would be similar problems
> to stderr coloring (if you remember the thread...).

Exactly right, Vincent.


On Fri, 20 Aug 2004, Andy Spiegl wrote:

> Now that I've got the list of lines (typically filenames) in $kept
> how do I get them into the command line _quoted_.

The best way is probably to use a completion widget.

  insert-kept-result () {
    compstate[insert]=all
    compadd -a kept
  }
  zle -C insert-kept-result complete-word insert-kept-result

> Actually, ideally I'd like only filenames with spaces and special chars 
> to be quoted to avoid cluttering up the command line, but I assume 
> that's even tougher to do. :-(

Not with completion, it isn't.

As a bonus, if you type part of a word and then invoke insert-kept-result
it'll only insert the subset of $kept that matches the partial word.


On Fri, 20 Aug 2004, Vincent Lefevre wrote:

> On 2004-08-20 14:12:02 +0200, Andy Spiegl wrote:
> > Now that I've got the list of lines (typically filenames) in $kept
> > how do I get them into the command line _quoted_.
> 
> And would it be possible to get a menu, in order to select one or
> several filenames manually?

For that we get a little more intense:

  _insert_kept() {
    (( $#kept )) || return 1
    local action
    zstyle -s :completion:$curcontext insert-kept action
    if [[ -n $action ]]
    then compstate[insert]=$action
    fi
    compadd -a kept
  }
  zle -C insert-kept-result complete-word _generic
  zstyle ':completion:insert-kept-result:*' completer _insert_kept

Now you get Andy's thing with

  zstyle ':completion:*' insert-kept all

Or you can get menu completion with

  zstyle ':completion:*' insert-kept menu

and it does menu completion according to whatever your other usual styles
are (or you can add other specific styles for this context).

Just remember that TAB is still going to execute _main_complete directly,
so if you start whacking TAB to cycle through the menu you won't get very
far -- the normal completion context will take over and discard the list
taken from $kept.  You have to use the same keybinding to cycle as you did
to get into the menu to begin with.

Note also that if you simply stick _insert_kept into your normal completer
style, the TAB key will insert values from $kept when it has a value and
go on to use other completions when $kept is empty or unset.

> And how about typing a pattern somewhere in the command line, then
> applying a function that replaces this pattern by the matching lines
> (quoted) of $kept?

You'll have to be more specific.  You mean something like expand-word,
except that the expansion gets stashed in $kept first?

I won't try to test this, but something like this should do it:

  _expand_word_and_keep() {
    function compadd() {
      local -a args
      zparseopts -E -a args A: O:
      if (( ! $#args ))
      then builtin compadd -A kept "$@"
      fi
      builtin compadd "$@"
    }
    local result
    kept=()
    _main_complete _expand
    result=$?
    unfunction compadd
    return $result
  }

See the #compdef line at the top of the _expand_word function file in the 
distribution for how you'd plug that onto a key.

Hmm, it occurs to me that I'm not sure what happens when you combine the
-A and -C options of compadd ...

Re: Tip of the day: previous command output

[Bart Schaefer]

On Fri, 20 Aug 2004, Bart Schaefer wrote:

> I won't try to test this, but something like this should do it:

OK, I lied.  I tested it.  It didn't do what I expected, though it did 
what I told it to do.

Here's a version that actually does what was asked:

  _expand_word_and_keep() {
    function compadd() {
      local -A args
      zparseopts -E -A args J:
      if [[ $args[-J] == all-expansions ]]
      then
        builtin compadd -A kept "$@"
        kept=(${(Q)${(z)kept}})
      fi
      builtin compadd "$@"
    }
    local result
    _main_complete _expand
    result=$?
    unfunction compadd
    return result
  }

With 4.2.1, you can replace the five "local ... return" lines with

    { _main_complete _expand } always { unfunction compadd }

Left as an excercise:  Get the name of the "keep" variable from a zstyle,
so you can stash expansions in different places depending on context.

Re: Tip of the day: previous command output

[Bart Schaefer]

On Fri, 20 Aug 2004, Bart Schaefer wrote:

> On Fri, 20 Aug 2004, Andy Spiegl wrote:
> 
> > What would be the difference if I dropped alias with the noglob and used 
> > $* instead of $~*?  I guess zsh would expand the globs before calling 
> > the function, right?
> 
> Right.
> 
> >  But the result should be the same or not?
> 
> Should be the same.  Waiting to expand uses a little less memory.

I just thought of another difference ... and remembered the reason that I 
did it the way I did.

Recall:

    keep () {
        kept=()         # Erase old value in case of error on next line
        kept=($~*)
        print -Rc - $kept
    }

Without the noglob, and if you use the NO_MATCH or CSH_NULL_GLOB setopts, 
which I do, then globbing errors occur before the function is called, and 
thus prevent the function from being called.  With the noglob alias, the 
globbing error occurs inside the function, at the second assignment.  The 
distinction is that in the latter case the prevous value of kept is erased 
on a globbing error, whereas in the former case it retains its old value.

I find that having kept set to empty on a glob failure is more useful, but
you may prefer otherwise.

Re: Tip of the day: previous command output

[Vincent Lefevre]

On 2004-08-20 21:25:47 -0700, Bart Schaefer wrote:
> > And how about typing a pattern somewhere in the command line, then
> > applying a function that replaces this pattern by the matching lines
> > (quoted) of $kept?
> 
> You'll have to be more specific.  You mean something like expand-word,
> except that the expansion gets stashed in $kept first?

No, I mean that instead of expanding to filenames, one expands
to lines from $kept (but only those that match the pattern).
For instance, if $kept is (ab ac bc) and [ESC][TAB] is bound
to the function in question, then

  a*[ESC][TAB]

gives

  ab ac

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: Tip of the day: previous command output

[Bart Schaefer]

On Sun, 22 Aug 2004, Vincent Lefevre wrote:

> I mean that instead of expanding to filenames, one expands
> to lines from $kept (but only those that match the pattern).

Aha.  So, akin to the case where you've provided a prefix, but instead 
you've provided a pattern.

This is almost exactly the same as the _insert_kept widget, so I'll just
edit it to include a test on the $WIDGET name.  Like so:

  _insert_kept() {
    (( $#kept )) || return 1
    local action
    zstyle -s :completion:$curcontext insert-kept action
    if [[ -n $action ]]
    then compstate[insert]=$action
    fi
    if [[ $WIDGET = *expand* ]]
    then compadd -U ${(M)kept:#${~words[CURRENT]}}
    else compadd -a kept
    fi
  }
  zle -C insert-kept-result complete-word _generic
  zle -C expand-kept-result complete-word _generic
  zstyle ':completion:*-kept-result:*' completer _insert_kept

This obviously isn't as sophisticated as _expand, which knows how to deal 
with all sorts of things besides just patterns.  You might also find that
the call to compadd -U needs to have some of the -i -I -P -S options 
thrown in to avoid obliterating parts of the word that you didn't mean
to obliterate; I've shown only the most simple solution.

Re: Tip of the day: previous command output

[Vincent Lefevre]

On 2004-08-22 18:10:57 -0700, Bart Schaefer wrote:
> On Sun, 22 Aug 2004, Vincent Lefevre wrote:
> 
> > I mean that instead of expanding to filenames, one expands
> > to lines from $kept (but only those that match the pattern).
> 
> Aha. So, akin to the case where you've provided a prefix, but
> instead you've provided a pattern.

Oops... I meant something like expand-or-complete, but expanding
on the values of kept matching the pattern (otherwise complete).
Anyway, your solution expand-kept-result just does that (no need
to have both widgets).

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: Tip of the day: previous command output

[Vincent Lefevre]

On 2004-08-20 21:25:47 -0700, Bart Schaefer wrote:
> On Fri, 20 Aug 2004, Vincent Lefevre wrote:
> > And would it be possible to get a menu, in order to select one or
> > several filenames manually?
> 
> For that we get a little more intense:
> 
>   _insert_kept() {
>     (( $#kept )) || return 1
>     local action
>     zstyle -s :completion:$curcontext insert-kept action
>     if [[ -n $action ]]
>     then compstate[insert]=$action
>     fi
>     compadd -a kept
>   }
>   zle -C insert-kept-result complete-word _generic
>   zstyle ':completion:insert-kept-result:*' completer _insert_kept
> 
> Now you get Andy's thing with
> 
>   zstyle ':completion:*' insert-kept all
> 
> Or you can get menu completion with
> 
>   zstyle ':completion:*' insert-kept menu
> 
> and it does menu completion according to whatever your other usual
> styles are (or you can add other specific styles for this context).

I was talking about another kind of menu (which could be useful for
standard completion too). For instance, there could be a cursor for
the (standard zsh) menu, or perhaps a number, to be able to choose
one or several word candidates.

$ echo [TAB]
[ab] ef  ij
 cd  gh  kl

[...] represents the cursor around "ab".

or

$ echo [TAB]
1 ab  3 ef  5 ij
2 cd  4 gh  6 kl

then typing some key followed by the number would insert the word.
This may be useful when there are many common prefixes (this often
occurs in practice).

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: Tip of the day: previous command output

[Bart Schaefer]

On Sun, 22 Aug 2004, Vincent Lefevre wrote:

> On 2004-08-20 21:25:47 -0700, Bart Schaefer wrote:
> > 
> > Or you can get menu completion with
> > 
> >   zstyle ':completion:*' insert-kept menu
> 
> I was talking about another kind of menu (which could be useful for
> standard completion too). For instance, there could be a cursor for
> the (standard zsh) menu, or perhaps a number, to be able to choose
> one or several word candidates.
> 
> $ echo [TAB]
> [ab] ef  ij
>  cd  gh  kl

How is does this differ from menu selection?

Starting from my previous post, you need only add:

    zmodload -i zsh/complist
    zstyle ':completion:insert-kept-result:*' menu yes select

Then load something into $kept e.g. with "keep", and then type whatever 
keystrokes you have insert-kept-result bound to.

If that doesn't correspond to the behavior you're describing above, then 
there's something I'm still not understanding.

> or
> 
> $ echo [TAB]
> 1 ab  3 ef  5 ij
> 2 cd  4 gh  6 kl
>
> then typing some key followed by the number would insert the word.

Numbering the possible matches is difficult, if not impossible, without 
changing the guts of the completion C code, because the labels that may be 
shown along with each match are assigned to the _possible_ matches, not to 
the _actual_ matches.  E.g. when completing files, compadd may be given 
the name of every file in the directory, and then the completion internals 
winnows them down to the names that actually fit the prefix or suffix 
that's already on the line.  So the numbers to show cannot be known until 
immediately before the list is displayed, and hence can't be passed to
compadd by user-definable functions.

However, someone more ambitious than I might alter the complist module to 
provide this display and some corresponding menuselect keymap bindings.  
A question would be, what do you expect to happen when the list is too 
long to fit on one screen?

Re: Tip of the day: previous command output

[Vincent Lefevre]

On 2004-08-22 16:03:23 -0700, Bart Schaefer wrote:
> How is does this differ from menu selection?

It seems that I need to reread all the documentation concerning the
completion system.

The date of the Zsh user guide is 1999/06/02; is it really that old?
It seems to have been rewritten since.

> Numbering the possible matches is difficult, if not impossible,
> without changing the guts of the completion C code, because the
> labels that may be shown along with each match are assigned to the
> _possible_ matches, not to the _actual_ matches. E.g. when
> completing files, compadd may be given the name of every file in the
> directory, and then the completion internals winnows them down to
> the names that actually fit the prefix or suffix that's already on
> the line. So the numbers to show cannot be known until immediately
> before the list is displayed, and hence can't be passed to compadd
> by user-definable functions.

I see. And is it possible to have some kind of realtime filtering in
a menu selection, like interactive search but reducing the displayed
matches at the same time?

> However, someone more ambitious than I might alter the complist
> module to provide this display and some corresponding menuselect
> keymap bindings. A question would be, what do you expect to happen
> when the list is too long to fit on one screen?

Being able to scroll would be sufficient IMHO.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: Tip of the day: previous command output

[Bart Schaefer]

On Mon, 23 Aug 2004, Vincent Lefevre wrote:

> The date of the Zsh user guide is 1999/06/02; is it really that old?

You mean PWS's user guide that's on-line at zsh.org?  I'm pretty sure 
that's its original date of "publication" and doesn't reflect incremental
updates.

> On 2004-08-22 16:03:23 -0700, Bart Schaefer wrote:
> > Numbering the possible matches is difficult, if not impossible,
> > without changing the guts of the completion C code
> 
> I see. And is it possible to have some kind of realtime filtering in
> a menu selection, like interactive search but reducing the displayed
> matches at the same time?

I _think_ that'd require changes to the C code as well.  Menu selection is 
a bit unusual in that it runs zle with a new keymap but then interprets 
several of the built-in widgets differently.  I'm pretty sure you can't
change the listing from widgets in that keymap, but there might be some
convoluted way to cause menu selection to exit and then immediately start
again on a new set of matches.

Re: Tip of the day: previous command output

[Vincent Lefevre]

On 2004-08-23 08:21:24 -0700, Bart Schaefer wrote:
> On Mon, 23 Aug 2004, Vincent Lefevre wrote:
> > The date of the Zsh user guide is 1999/06/02; is it really that old?
> 
> You mean PWS's user guide that's on-line at zsh.org? I'm pretty sure
> that's its original date of "publication" and doesn't reflect
> incremental updates.

Unfortunately this makes difficult to know when it is updated.

> I _think_ that'd require changes to the C code as well. Menu
> selection is a bit unusual in that it runs zle with a new keymap but
> then interprets several of the built-in widgets differently. I'm
> pretty sure you can't change the listing from widgets in that
> keymap, but there might be some convoluted way to cause menu
> selection to exit and then immediately start again on a new set of
> matches.

Yes, this is a good idea. I can imagine that the menu can be generated
from the current word, containing a pattern, and each time the user
adds a character to the pattern, the menu is updated.

Thanks for all these informations...

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: Tip of the day: previous command output

[Andy Spiegl]

> On 2004-08-22 16:03:23 -0700, Bart Schaefer wrote:
> > How is does this differ from menu selection?
> 
> It seems that I need to reread all the documentation concerning the
> completion system.

Ups, so do I!  I had no idea that it's possible to select an item and keep
browsing the menu selection.  I just tried that now but I'm having problems
with binding a key to "accept-and-menu-complete".  I thought that
Ctrl-Enter would be a nicely fitting key for that (which one do you guys
use?) and tried
 bindkey -M menuselect '\C\r' accept-and-menu-complete

which works but has the side effect that Enter (without Ctrl) is bound to
accept-and-menu-complete, too.

Is that a bug or a feature? :-)
How do you gurus use this interesting feature?

I am using zsh 4.2.0 on Debian Sarge.

Thanks,
 Andy.

-- 
                              o      _     _         _
  ------- __o       __o      /\_   _ \\o  (_)\__/o  (_)          -o)
  ----- _`\<,_    _`\<,_    _>(_) (_)/<_    \_| \   _|/' \/       /\\
  ---- (_)/ (_)  (_)/ (_)  (_)        (_)   (_)    (_)'  _\o_    _\_v
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Great spirits have always encountered violent opposition from
 mediocre minds.   - Albert Einstein

Re: Tip of the day: previous command output

[Bart Schaefer]

(I think we're making a run at the longest zsh-users thread ever.)

On Fri, 27 Aug 2004, Andy Spiegl wrote:

> I'm having problems with binding a key to "accept-and-menu-complete".  
> I thought that Ctrl-Enter would be a nicely fitting key for that (which 
> one do you guys use?) and tried
>  bindkey -M menuselect '\C\r' accept-and-menu-complete

The '\C' prefix is meaningless, and ignored, for characters outside the 
range a-z (or A-Z).  It's a shortcut for an ASCII value, not a shortcut
for (e.g.) an X11 key event.

Whether Ctrl-Enter is meaningful depends entirely on your terminal or 
emulator, and probably either sends a plain return, or sends a multi-
character sequence like a function key would.  You need to find out what
it sends and bind to _that_.

Re: Tip of the day: previous command output

[Andy Spiegl]

Hi Bart and Oliver,

> (I think we're making a run at the longest zsh-users thread ever.)
:-)

> You need to find out what it sends and bind to _that_.
Ups, you are right.  It just sends plain enter and ignores the Ctrl.
It does work with Alt though.  (tested with xterm and Eterm)

Thanks,
 Andy.

-- 
                              o      _     _         _
  ------- __o       __o      /\_   _ \\o  (_)\__/o  (_)          -o)
  ----- _`\<,_    _`\<,_    _>(_) (_)/<_    \_| \   _|/' \/       /\\
  ---- (_)/ (_)  (_)/ (_)  (_)        (_)   (_)    (_)'  _\o_    _\_v
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 No matter what anyone else tells you, nice guys do finish last.

Re: Tip of the day: previous command output

[zzapper]

On Thu, 19 Aug 2004 10:58:12 +0200,  wrote:

>Someone asked for zsh tips a couple of weeks ago. Here's something I use
>a lot. I got the basic idea from some user group somewhere, and then I've
>tweaked the idea to suit my needs.
>
>The motivation for the following snippet is the fact that I often do a 'find'
>or a 'locate' to find some files I'm interested in, and then want to do some
>action on one of the files I just found. This function provides a way to put
>completions from the output of the previous command on the command line.
>
>_jh-prev-result () {
>    hstring=$(eval `fc -l -n -1`)
>    set -A hlist ${(@s/
>/)hstring}
>    compadd - ${hlist}
>}
>
>zle -C jh-prev-comp menu-complete _jh-prev-result
>bindkey '\ee' jh-prev-comp
>

Anyone care to do a summary of this thread? Not being lazy I hope, but there's some quite advanced
stuff!


zzapper (vim, cygwin, wiki & zsh)
--

vim -c ":%s%s*%CyrnfrTfcbafbeROenzSZbbyranne%|:%s)[R-T]) )Ig|:norm G1VGg?"

http://www.vim.org/tips/tip.php?tip_id=305  Best of Vim Tips