Re: Proposed _history completer

Re: Proposed _history completer

[Sven Wischnowsky]

Felix Rosencrantz wrote:

> I'm not currently doing any work on the _history completer.  So if you
> want to commit the changes that would be fine with me.  Though I think
> my testing is pretty limited (e.g. I don't use NUMERIC arguments, and I didn't
> try various zstyle configurations.)  I was thinking that in case there were
> any obvious problems with the completer (e.g. _wanted shouldn't be used in
> a completer) someone would post that feedback.

No, that's ok.

> Also, I don't have a lot of time to work on it, this completer has been on my
> list for a while.  So if other people want work on it I would be happy.
> 
> Sven Wischnowsky wrote:
> >_first contains a bit of code for something like this...
> 
> It's not quite N number of lines back that the compctl uses, but it seems
> like a reasonable approximation.

See below...

> >> I think there is a lot of potential to be found in limiting history words to
> >> similar contexts;  only history lines where the current command is used,
> >> or previous values for the current option. 
> >
> >Sounds good.
> >
> >> To do this might require
> >> some changes to the zsh/parameter module to make this efficient.
> >
> >Hm, I can't see how this could be done, yet. Have you tried how
> >slow/fast it is?
> 
> I wasn't sure how to break up the values of $history to find the start
> of commands, and to break up along word boundaries.  I was thinking
> that we might need C code support for that.  The $historywords array
> gives us the words, but it doesn't give much context (e.g. like if the word
> is in a command position, what history line the command is from).

Hmhm.

Maybe we could make $historywords an assoc with the words as keys and
the values giving information about that word. Something like the
history number where it comes from plus information about the context
(command-context, of some kind).

And no, I haven't looked how difficult to implement this would be (the 
history number itself would be easy if I remember correctly).

Bye
 Sven


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

Re: Proposed _history completer

[Bart Schaefer]

On Apr 27, 12:44pm, Sven Wischnowsky wrote:
} Subject: Re: Proposed _history completer
}
} Maybe we could make $historywords an assoc with the words as keys and
} the values giving information about that word. Something like the
} history number where it comes from plus information about the context
} (command-context, of some kind).

That can't work, can it?  What if the same word appears in different
places in the history, or even different places in the same command?
The keys would have to be made unique somehow, or else you have to
have a complicated format for compounding the value.

I think having a way to chop a string into shell words -- something like
what you did for copy-prev-shell-word -- would be more effective.

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

Re: Proposed _history completer

[Bart Schaefer]

On Apr 28,  9:20am, Sven Wischnowsky wrote:
}
} Bart Schaefer wrote:
} 
} > I think having a way to chop a string into shell words -- something like
} > what you did for copy-prev-shell-word -- would be more effective.
} 
} [...] some parameter flag, most likely. Hm, s and S are taken,
} so are c and C. We could use `=' but that would probably be too
} irritating.

Hrm.  How would a parameter flag do this on an array?  Parse each word
separately?

Hrm, again; maybe the way to do this is with a modifier rather than a
flag.  :S is available, and it'd be kinda fun to be able to apply this
to history as well as to parameters.  Or maybe it wouldn't ...

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

Re: Proposed _history completer

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Apr 27, 12:44pm, Sven Wischnowsky wrote:
> } Subject: Re: Proposed _history completer
> }
> } Maybe we could make $historywords an assoc with the words as keys and
> } the values giving information about that word. Something like the
> } history number where it comes from plus information about the context
> } (command-context, of some kind).
> 
> That can't work, can it?  What if the same word appears in different
> places in the history, or even different places in the same command?
> The keys would have to be made unique somehow, or else you have to
> have a complicated format for compounding the value.

Ouch. Of course ;-}

> I think having a way to chop a string into shell words -- something like
> what you did for copy-prev-shell-word -- would be more effective.

Ah, when I wrote that I had planned to allow this anyway and then
forgot... some parameter flag, most likely. Hm, s and S are taken,
so are c and C. We could use `=' but that would probably be too
irritating.


Bye
 Sven


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

Re: Proposed _history completer

[Felix Rosencrantz]

I'm not currently doing any work on the _history completer.  So if you
want to commit the changes that would be fine with me.  Though I think
my testing is pretty limited (e.g. I don't use NUMERIC arguments, and I didn't
try various zstyle configurations.)  I was thinking that in case there were
any obvious problems with the completer (e.g. _wanted shouldn't be used in
a completer) someone would post that feedback.

Also, I don't have a lot of time to work on it, this completer has been on my
list for a while.  So if other people want work on it I would be happy.

Sven Wischnowsky wrote:
>_first contains a bit of code for something like this...

It's not quite N number of lines back that the compctl uses, but it seems
like a reasonable approximation.

>> I think there is a lot of potential to be found in limiting history words to
>> similar contexts;  only history lines where the current command is used,
>> or previous values for the current option. 
>
>Sounds good.
>
>> To do this might require
>> some changes to the zsh/parameter module to make this efficient.
>
>Hm, I can't see how this could be done, yet. Have you tried how
>slow/fast it is?

I wasn't sure how to break up the values of $history to find the start
of commands, and to break up along word boundaries.  I was thinking
that we might need C code support for that.  The $historywords array
gives us the words, but it doesn't give much context (e.g. like if the word
is in a command position, what history line the command is from).  Here is
a quick test I tried to see where words are broken for $history and
$historywords:


    prompt% echo "this is long string" `echo this is a cmd string | cat -n `
    this is long string 1 this is a cmd string
    prompt% ~/bin/args $historywords 
    0. $historywords
    1. ~/bin/args
    2. `echo this is a cmd string | cat -n `
    3. "this is long string"
    4. echo
    prompt% ~/bin/args $history
    0. ~/bin/args $historywords
    1. echo "this is long string" `echo this is a cmd string | cat -n `

In this instance, how do we find the words supplied to various echo commands
or the cat command.  How do we find that cat is command here.  I'm not
sure how easy this is to do in a zsh script.

Even if we had that information, I was thinking it might be more efficient
to have the zsh/parameter module prune what is actually put into these
special history parameters.  Prune might limit the lines/words to only
those of specific commands, or within the last so many lines of history.
But I'm not sure how we would specify what is pruned, if we wanted to do that.

I tend to have a large history buffer, so I always worry about what resources
those arrays are using.

>> It might be useful to use history as a way to filter completions from other
>> completers.  To first use completions that are already found in history.
>> Or the opposite, to eliminate choices that are found in the history.
>
>Hm, the latter sounds more useful. That could probably be done with
>some trickery with _comp_ignore, which is set in _description, but the
>history stuff probably shouldn't go there. Maybe another completer
>that sets some array and a change to _description to include
>that. Might make things pretty slow, but there may be potential for
>optimisation... probably an option to compadd like -F but that gives
>strings (not patterns) to exclude. Or maybe just make -F use strings
>without wildcards directly in a strcmp().

You've gone beyond my understanding of the completion system.  Would require
more studying on my part to be clear about what you are proposing.

-FR


__________________________________________________
Do You Yahoo!?
Talk to your friends online and get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

Re: Proposed _history completer

[Sven Wischnowsky]

Felix Rosencrantz wrote:

> Here is a first attempt at proposing a completer that completes words in
> history.  This is the start of a replacement for the example in the compctl
> manual that searches history if filenames don't match in the default
> completion (compctl -D -f + -H 0 '').
> 
> This is a pruned down version of the _history_complete_word widget so
> that it would behave as a completer function and not as a stand alone
> widget.  Some of the behavior provided by the _history_complete_word
> widget is lost, but the ability to include it as a completer should be
> useful.  It might be useful to use with the predict widgets.

I think (or at least hope) I suggested this when Adam added _h_c_w.

> One benefit is that it is now possible to use the default styles that all the
> completers use.  For example, matcher-list can be used with _history.
> 
> Future changes to this widget might include the ability to limit how much
> of history is used for completion, like the old compctl -H flag. 

_first contains a bit of code for something like this...

> I think there is a lot of potential to be found in limiting history words to
> similar contexts;  only history lines where the current command is used,
> or previous values for the current option. 

Sounds good.

>  To do this might require
> some changes to the zsh/parameter module to make this efficient.

Hm, I can't see how this could be done, yet. Have you tried how
slow/fast it is?

> It might be useful to use history as a way to filter completions from other
> completers.  To first use completions that are already found in history.
> Or the opposite, to eliminate choices that are found in the history.

Hm, the latter sounds more useful. That could probably be done with
some trickery with _comp_ignore, which is set in _description, but the
history stuff probably shouldn't go there. Maybe another completer
that sets some array and a change to _description to include
that. Might make things pretty slow, but there may be potential for
optimisation... probably an option to compadd like -F but that gives
strings (not patterns) to exclude. Or maybe just make -F use strings
without wildcards directly in a strcmp().


Bye
 Sven


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

Proposed _history completer

[Felix Rosencrantz]

[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]

Here is a first attempt at proposing a completer that completes words in
history.  This is the start of a replacement for the example in the compctl
manual that searches history if filenames don't match in the default
completion (compctl -D -f + -H 0 '').

This is a pruned down version of the _history_complete_word widget so
that it would behave as a completer function and not as a stand alone
widget.  Some of the behavior provided by the _history_complete_word
widget is lost, but the ability to include it as a completer should be
useful.  It might be useful to use with the predict widgets.

One benefit is that it is now possible to use the default styles that all the
completers use.  For example, matcher-list can be used with _history.

Future changes to this widget might include the ability to limit how much
of history is used for completion, like the old compctl -H flag. 
I think there is a lot of potential to be found in limiting history words to
similar contexts;  only history lines where the current command is used,
or previous values for the current option.   To do this might require
some changes to the zsh/parameter module to make this efficient.

It might be useful to use history as a way to filter completions from other
completers.  To first use completions that are already found in history.
Or the opposite, to eliminate choices that are found in the history.

-FR.


__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 2519 bytes --]

--- zsh/Doc/Zsh/,compsys.yo	Thu Apr 20 01:04:57 2000
+++ zsh/Doc/Zsh/compsys.yo	Sun Apr 23 19:10:02 2000
@@ -2132,10 +2132,18 @@
 at all.
 
 In a different mode selected by the tt(completions) style, all
 em(completions) generated for the string on the line are inserted.
 )
+findex(_history)
+item(tt(_history))(
+Complete words from the shell's command  history.  This completer 
+uses the tt(remove-all-dups), and tt(sort) styles used by the
+tt(_history_complete_word) bindable command, see
+ifzman(the section `Completion System Configuration' above)\
+ifnzman(noderef(Completion System Configuration)).
+)
 findex(_list)
 item(tt(_list))(
 This completer allows one to delay the insertion of matches until
 completion is attempted a second time without the word on the line
 being changed. On the first attempt, only the list of matches will be
--- zsh/Completion/Core/,.distfiles	Wed Apr 19 17:48:28 2000
+++ zsh/Completion/Core/.distfiles	Sun Apr 23 19:24:54 2000
@@ -1,11 +1,11 @@
 DISTFILES_SRC='
     .distfiles
     _all_labels _alternative _approximate
     _call _compalso _complete _correct _description _expand
-    _file_descriptors _files _funcall _ignored _list _main_complete _match
-    _menu _multi_parts _message _next_label _normal _oldlist _options
+    _file_descriptors _files _funcall _history _ignored _list _main_complete
+    _match _menu _multi_parts _message _next_label _normal _oldlist _options
     _parameters _path_files _prefix _requested _sep_parts
     _set_options _setup _sort_tags _tags
     _unset_options _wanted
     compdump compinit compinstall
 '
--- /dev/null	Sun Apr 23 19:21:14 2000
+++ zsh/Completion/Core/_history	Sun Apr 23 19:26:09 2000
@@ -0,0 +1,31 @@
+#autoload
+
+#
+# Complete words from the history
+#
+# Code taken from _history_complete_words.
+#
+# Available styles:
+#
+#   :history-words:sort -- sort matches lexically (default is to sort by age)
+#   :history-words:remove-all-dups --
+#                          remove /all/ duplicate matches rather than just
+#                          consecutives
+
+  local opt expl 
+
+  if zstyle -t ":completion:${curcontext}:" remove-all-dups; then
+    opt=-
+  else
+    opt=-1
+  fi
+  if zstyle -t ":completion:${curcontext}:" sort; then
+    opt="${opt}J"
+  else
+    opt="${opt}V"
+  fi
+
+  # We skip the first element of historywords so the current word doesn't
+  # interfere with the completion
+  _wanted "$opt" history-words expl 'history word' \
+      compadd -Q - "${(@)historywords[2,-1]}"