zsh-workers
 help / color / mirror / code / Atom feed
* PATCH: documentation for new _history_complete_word
@ 1999-09-27 13:18 Adam Spiers
  1999-09-27 13:46 ` Peter Stephenson
  1999-09-27 14:33 ` Peter Stephenson
  0 siblings, 2 replies; 3+ messages in thread
From: Adam Spiers @ 1999-09-27 13:18 UTC (permalink / raw)
  To: zsh workers mailing list

This patch should only be applied at the same time as my rewrite of
_history_complete_word.  The rewrite didn't make it into pws-6; maybe
because there are still (very slight) problems with duplicates
removal?  Any ideas on solutions to this problem, or will we have to
wait for Sven to get back?

Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /usr/local/cvsroot/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.3
diff -u -r1.3 compsys.yo
--- Doc/Zsh/compsys.yo	1999/09/23 11:32:49	1.3
+++ Doc/Zsh/compsys.yo	1999/09/27 01:35:34
@@ -1597,6 +1597,15 @@
 to the pathname of a file containing color names in the format of an
 X11 tt(rgb.txt) file.
 )
+item(tt(history_list))(
+If this is set to a non-empty string, the tt(_history_complete_word)
+bindable command will list all available matches.
+)
+item(tt(history_remove_all_dups))(
+If this is set to a non-empty string, the tt(_history_complete_word)
+bindable command will remove all duplicate matches, rather than just
+removing consecutive duplicates.
+)
 item(tt(history_sort))(
 If this is set to a non-empty string, completion functions that
 generate words from the history as possible matches sort these words


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: PATCH: documentation for new _history_complete_word
  1999-09-27 13:18 PATCH: documentation for new _history_complete_word Adam Spiers
@ 1999-09-27 13:46 ` Peter Stephenson
  1999-09-27 14:33 ` Peter Stephenson
  1 sibling, 0 replies; 3+ messages in thread
From: Peter Stephenson @ 1999-09-27 13:46 UTC (permalink / raw)
  To: zsh workers mailing list

Adam Spiers wrote:
> This patch should only be applied at the same time as my rewrite of
> _history_complete_word.  The rewrite didn't make it into pws-6; maybe
> because there are still (very slight) problems with duplicates
> removal?  Any ideas on solutions to this problem, or will we have to
> wait for Sven to get back?

That was just because it didn't appear as a patch, so I assumed it was just
for trying out, but I can dig it out.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: PATCH: documentation for new _history_complete_word
  1999-09-27 13:18 PATCH: documentation for new _history_complete_word Adam Spiers
  1999-09-27 13:46 ` Peter Stephenson
@ 1999-09-27 14:33 ` Peter Stephenson
  1 sibling, 0 replies; 3+ messages in thread
From: Peter Stephenson @ 1999-09-27 14:33 UTC (permalink / raw)
  To: zsh workers mailing list

Adam Spiers wrote:
> This patch should only be applied at the same time as my rewrite of
> _history_complete_word.  The rewrite didn't make it into pws-6

I've added this now (the rest of you will have to extract it by hand from
8028 in some MIME-aware way).  It has the unfortunate effect that menu
completion is turned off unless history_stop is set, even if you usually
have it on.  The following seems to fix that.  But it still seems not to
respect option settings properly.  With no menu behaviour at all, instead
of getting a complete set of possible completions, maybe with autolisting,
as you would expect, you get only the last completion.  Shouldn't it just
forget about newer and older in this case and add the lot?  (I haven't even
looked at what happens with automenu.)

A couple of other things

- probably it should return status 1 when it gets to the end of the list
  in either direction so that the shell can beep if appropriate.  It might
  be neat to do this if and only if HIST_BEEP is set.
- There's probably a better way of doing the checking for which direction
  to move.  The usual way would be to check $WIDGET, but then you
  have to add the other widget by hand using zle -C.  Maybe we can think
  of an extension to compdef which would allow you to define both
  in the top line, with default bindings.  In fact, it would be handy
  to have a way of defining command widgets to use multiple types
  of completion, so you can get listing as well as completing behaviour
  from the same function with no extra work.

--- Completion/Commands/_history_complete_word.bak	Mon Sep 27 16:00:42 1999
+++ Completion/Commands/_history_complete_word	Mon Sep 27 16:25:34 1999
@@ -36,7 +36,8 @@
 
   [[ -z "$compconfig[history_list]" ]] && compstate[list]=''
 
-  if [[ -n "$compstate[old_list]" && -n "$compconfig[history_stop]" ]]; then
+  if [[ -n "$compstate[old_list]" &&
+    ( -n "$compconfig[history_stop]" || "$compstate[insert]" = menu ) ]]; then
     # array of matches is newest -> oldest (reverse of history order)
     if [[ "$direction" == 'older' ]]; then
       if [[ compstate[old_insert] -eq $_hist_menu_length ||

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~1999-09-27 15:09 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-09-27 13:18 PATCH: documentation for new _history_complete_word Adam Spiers
1999-09-27 13:46 ` Peter Stephenson
1999-09-27 14:33 ` Peter Stephenson

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).