zsh-workers
 help / color / mirror / code / Atom feed
* adding the original string as a completion match
@ 2002-03-27 11:10 Oliver Kiddle
  2002-03-28 10:15 ` Sven Wischnowsky
  0 siblings, 1 reply; 3+ messages in thread
From: Oliver Kiddle @ 2002-03-27 11:10 UTC (permalink / raw)
  To: zsh-workers

I thought it would be useful to have the original string added as a
possible completion in my _match based completion widget similar to how
_approximate adds it. So the patch below is a cut'n'paste job from
_approximate into _match which I won't commit unless someone says to.

Thinking about it, the original match could be useful anywhere that it
goes into menu completion. Would it be possible to have a completer a
bit like _all_matches (and taking some of the same styles) to add the
original string? I tend to get the original string by hitting undo and
just like to see what the original string was so this completer might
optionally just mention the string in a message.

And another question, is there any way with _all_matches that I can get
it to just insert all the matches and never list all the things which
_complete came up with? Something like a tag-order but that doesn't
work.

Oliver

--- _match	Mon Apr  2 12:08:02 2001
+++ _match	Wed Mar 27 08:18:38 2002
@@ -22,6 +22,8 @@
 
 _old_match_string="$PREFIX$SUFFIX$HISTNO"
 
+_tags matches original
+
 zstyle -s ":completion:${curcontext}:" match-original orig
 zstyle -s ":completion:${curcontext}:" insert-unambiguous ins
 
@@ -61,10 +63,19 @@
 #        ins=yes compstate[insert]="$ocsi" compstate[pattern_insert]="$ocspi"
   fi
 
-  [[ "$ins" = (true|yes|on|1) &&
-     $#compstate[unambiguous] -ge ${#:-${PREFIX}${SUFFIX}} ]] && 
-      compstate[pattern_insert]=unambiguous
+  if [[ "$ins" = (true|yes|on|1) &&
+      $#compstate[unambiguous] -ge ${#:-${PREFIX}${SUFFIX}} ]]
+  then 
+    compstate[pattern_insert]=unambiguous
+  elif _requested original &&
+      { [[ compstate[nmatches] -gt 1 ]] ||
+	zstyle -t ":completion:${curcontext}:" original }; then
+    local expl
+
+    _description -V original expl original
 
+    compadd "$expl[@]" -U -Q - "$PREFIX$SUFFIX"
+  fi    
 fi
 
 return ret
-- 

This e-mail and any attachment is for authorised use by the intended recipient(s) only.  It may contain proprietary material, confidential information and/or be subject to legal privilege.  It should not be copied, disclosed to, retained or used by, any other party.  If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender.  Thank you.


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

* Re: adding the original string as a completion match
  2002-03-27 11:10 adding the original string as a completion match Oliver Kiddle
@ 2002-03-28 10:15 ` Sven Wischnowsky
  2002-03-28 17:01   ` Oliver Kiddle
  0 siblings, 1 reply; 3+ messages in thread
From: Sven Wischnowsky @ 2002-03-28 10:15 UTC (permalink / raw)
  To: zsh-workers


Oliver Kiddle wrote:

> I thought it would be useful to have the original string added as a
> possible completion in my _match based completion widget similar to how
> _approximate adds it. So the patch below is a cut'n'paste job from
> _approximate into _match which I won't commit unless someone says to.

Nothing against that.

> Thinking about it, the original match could be useful anywhere that it
> goes into menu completion. Would it be possible to have a completer a
> bit like _all_matches (and taking some of the same styles) to add the
> original string? I tend to get the original string by hitting undo and
> just like to see what the original string was so this completer might
> optionally just mention the string in a message.

Something like _all_matches is problematic because whether menu
completion is to be used is decided very late, after all the
completers have been called.  It would be easier to add a style tested
by _main_complete itself saying whether the original string should be
added as a match or only as a description.  Other function could
probably rely on that then?  Or at least that code should check
whether the original string has been added by other means before.

> And another question, is there any way with _all_matches that I can get
> it to just insert all the matches and never list all the things which
> _complete came up with? Something like a tag-order but that doesn't
> work.

There should be a possibility for this by setting compstate[insert]=-1
after _all_matches added that all-matches-match.  Haven't tried,
though...


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de


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

* Re: adding the original string as a completion match
  2002-03-28 10:15 ` Sven Wischnowsky
@ 2002-03-28 17:01   ` Oliver Kiddle
  0 siblings, 0 replies; 3+ messages in thread
From: Oliver Kiddle @ 2002-03-28 17:01 UTC (permalink / raw)
  To: Sven Wischnowsky; +Cc: zsh-workers

Sven Wischnowsky wrote:
 
> Something like _all_matches is problematic because whether menu
> completion is to be used is decided very late, after all the
> completers have been called.  It would be easier to add a style tested
> by _main_complete itself saying whether the original string should be
> added as a match or only as a description.  Other function could

Looking at where in _main_complete I would need to add this, it seems
that it could be done with a post function setup from a completer which
would be like _all_matches. Your suggestion is probably better though.

I tried this:

  if [[ $compstate[insert] = *menu* && "$compstate[nmatches]" -gt 1 &&
      -n $PREFIX$SUFFIX ]]; then
    _description -V original expl original
    compadd "$expl[@]" -U -Q - "$PREFIX$SUFFIX"
  fi

There needs to be more things in the if condition though. In
particular, it has problems when the matches added are added after part
of PREFIX will have been moved to IPREFIX, e.g. cd Mail/<tab> results
in the slash being removed. Any idea on how to get it working or if it
is even possible? If not, I'll commit the _match change instead.

> > And another question, is there any way with _all_matches that I can get
> > it to just insert all the matches and never list all the things which

> There should be a possibility for this by setting compstate[insert]=-1
> after _all_matches added that all-matches-match.  Haven't tried,
> though...

That didn't seem to work but compstate[insert]=all does the job. Hence
the following patch.

Thanks Sven.

Oliver

Index: Completion/Base/Completer/_all_matches
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Completer/_all_matches,v
retrieving revision 1.1
diff -u -r1.1 _all_matches
--- Completion/Base/Completer/_all_matches	2 Apr 2001 11:05:27 -0000	1.1
+++ Completion/Base/Completer/_all_matches	28 Mar 2002 16:53:05 -0000
@@ -33,8 +33,12 @@
   if [[ "$compstate[nmatches]" -gt 1 && $not[(I)(|_)$_completer] -eq 0 ]]; then
     local expl
 
-    _description all-matches expl 'all matches'
-    compadd "$expl[@]" -C
+    if zstyle -t "$_all_matches_context" insert; then
+      compstate[insert]=all
+    else
+      _description all-matches expl 'all matches'
+      compadd "$expl[@]" -C
+    fi
   fi
 
   unset _all_matches_context
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.152
diff -u -r1.152 compsys.yo
--- Doc/Zsh/compsys.yo	27 Mar 2002 16:10:11 -0000	1.152
+++ Doc/Zsh/compsys.yo	28 Mar 2002 16:53:06 -0000
@@ -1461,6 +1461,11 @@
 tt(EXTENDED_GLOB) option is in effect, so the characters `tt(#)',
 `tt(~)' and `tt(^)' have special meanings in the patterns.
 )
+kindex(insert, completion style)
+item(tt(insert))(
+This style is used by the tt(_all_matches) completer to decide whether to
+insert the list of all matches instead of adding it as another match.
+)
 kindex(insert-ids, completion style)
 item(tt(insert-ids))(
 When completing process IDs, for example as arguments to the tt(kill) and
-- 

This e-mail and any attachment is for authorised use by the intended recipient(s) only.  It may contain proprietary material, confidential information and/or be subject to legal privilege.  It should not be copied, disclosed to, retained or used by, any other party.  If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender.  Thank you.


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

end of thread, other threads:[~2002-03-28 17:01 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-03-27 11:10 adding the original string as a completion match Oliver Kiddle
2002-03-28 10:15 ` Sven Wischnowsky
2002-03-28 17:01   ` Oliver Kiddle

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