zsh-users
 help / color / mirror / code / Atom feed
* Re: Getting completion to tell the user what to do
@ 1999-07-20  7:08 Sven Wischnowsky
  1999-07-20  8:53 ` Bart Schaefer
  0 siblings, 1 reply; 4+ messages in thread
From: Sven Wischnowsky @ 1999-07-20  7:08 UTC (permalink / raw)
  To: zsh-users


Bart Schaefer wrote:

> This ought to be an easy one in the new 3.1.6 completion system, but I just
> can't get it to work.
> 
> I'm trying to complete "subject string goes here" as in
> 
> 	mail -s "subject string goes here"
> 
> What I want is to offer no completions at all, because the subject is free-
> form text, but print a hint to the user as to what he's supposed to type.
> 
> The following almost works (inside a completion function the rest of which
> is not interesting):
> 
>   compadd -S '' -X 'Please enter the subject of the message' ''
> 
> but because there's a unique completion, the explanation is printed only
> when the user types ^D, and there's no beep to let him know why tab isn't
> doing anything.  OK, I thought, I can force a listing:
> 
>   compadd -S '' -X 'Please enter the subject of the message' ''
>   compstate[list]=list
>   compstate[force_list]=yes
>   compstate[restore]=no
> 
> but that doesn't work -- there's still no explanation printed.
> 
> What obvious thing have I forgotten/overlooked here?  Is there an entirely
> better alternative to using compadd -X ?

Time for dirty tricks:

  compadd -UX 'Please...' -n ''
  compstate[insert]=''
  compstate[list]=list
  compstate[force_list]=yes

You need the -U because otherwise the empty string never matches
what's on the line (not even the empty string on the line). Then we
can switch of insertion completely.

If you want the string to be listed only on a TAB with an empty string 
you can do `compadd -X "Please..." -n dummy' -- i.e. add a string with 
matching.

The -n, of course, is just to be sure that the matches are not visible.

Is that good enough?

Bye
 Sven


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


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

* Re: Getting completion to tell the user what to do
  1999-07-20  7:08 Getting completion to tell the user what to do Sven Wischnowsky
@ 1999-07-20  8:53 ` Bart Schaefer
  0 siblings, 0 replies; 4+ messages in thread
From: Bart Schaefer @ 1999-07-20  8:53 UTC (permalink / raw)
  To: Sven Wischnowsky, zsh-users

On Jul 20,  9:08am, Sven Wischnowsky wrote:
} Subject: Re: Getting completion to tell the user what to do
}
} Bart Schaefer wrote:
} 
} > What I want is to offer no completions at all [...]
} > but print a hint to the user as to what he's supposed to type.
} > 
} > What obvious thing have I forgotten/overlooked here?  Is there an entirely
} > better alternative to using compadd -X ?
} 
} Time for dirty tricks:
} 
}   compadd -UX 'Please...' -n ''
}   compstate[insert]=''

Oho -- undocumented dirty tricks, no less.  The compstate[insert] doc
doesn't give any hint that it can be set but empty.  Of which case that
is documented is this a degenerate?

}   compstate[list]=list
}   compstate[force_list]=yes
} 
} You need the -U because otherwise the empty string never matches
} what's on the line (not even the empty string on the line).

Really?  When I first tried

	compadd -X 'Please ...' ''

(without the -S) then every time I pressed TAB a single space got inserted
(the suffix).  If the empty string isn't a match, why did that happen?

} Then we can switch off insertion completely.

So that's what compstate[insert]='' means?

} If you want the string to be listed only on a TAB with an empty string 
} you can do `compadd -X "Please..." -n dummy' -- i.e. add a string with 
} matching.

Presumably then "dummy" should be something that can't possibly match?
Or does that not matter?

} The -n, of course, is just to be sure that the matches are not visible.
} 
} Is that good enough?

It's just marvelous, thanks.  One question, though -- I thought that we
made kill-whole-line erase the completion listing, but it doesn't seem to
do that in this case:

    zagzig% mail -s <TAB><C-u>

leaves me with

    zagzig% 
    Please enter a descriptive subject

which is rather annoying when I start in typing some completely different
command and doing completions for it that don't themselves produce a list.

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


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

* Re: Getting completion to tell the user what to do
@ 1999-07-20  9:16 Sven Wischnowsky
  0 siblings, 0 replies; 4+ messages in thread
From: Sven Wischnowsky @ 1999-07-20  9:16 UTC (permalink / raw)
  To: zsh-users


Bart Schaefer wrote:

> On Jul 20,  9:08am, Sven Wischnowsky wrote:
> } Subject: Re: Getting completion to tell the user what to do
> }
> } Bart Schaefer wrote:
> } 
> } > What I want is to offer no completions at all [...]
> } > but print a hint to the user as to what he's supposed to type.
> } > 
> } > What obvious thing have I forgotten/overlooked here?  Is there an entirely
> } > better alternative to using compadd -X ?
> } 
> } Time for dirty tricks:
> } 
> }   compadd -UX 'Please...' -n ''
> }   compstate[insert]=''
> 
> Oho -- undocumented dirty tricks, no less.  The compstate[insert] doc
> doesn't give any hint that it can be set but empty.  Of which case that
> is documented is this a degenerate?

Unsetting compstate[insert].

> }   compstate[list]=list
> }   compstate[force_list]=yes
> } 
> } You need the -U because otherwise the empty string never matches
> } what's on the line (not even the empty string on the line).
> 
> Really?  When I first tried
> 
> 	compadd -X 'Please ...' ''
> 
> (without the -S) then every time I pressed TAB a single space got inserted
> (the suffix).  If the empty string isn't a match, why did that happen?

Ugh, right, sorry.

> } Then we can switch off insertion completely.
> 
> So that's what compstate[insert]='' means?

Exactly that.

> } If you want the string to be listed only on a TAB with an empty string 
> } you can do `compadd -X "Please..." -n dummy' -- i.e. add a string with 
> } matching.
> 
> Presumably then "dummy" should be something that can't possibly match?
> Or does that not matter?

That would be better, yes. Unless you also have `compstate[insert]=""' or
`unset "compstate[insert]"', in which case it doesn't matter.

> } The -n, of course, is just to be sure that the matches are not visible.
> } 
> } Is that good enough?
> 
> It's just marvelous, thanks.  One question, though -- I thought that we
> made kill-whole-line erase the completion listing, but it doesn't seem to
> do that in this case:
> 
>     zagzig% mail -s <TAB><C-u>
> 
> leaves me with
> 
>     zagzig% 
>     Please enter a descriptive subject
> 
> which is rather annoying when I start in typing some completely different
> command and doing completions for it that don't themselves produce a list.

Nasty side-effect of 7161.

Bye
 Sven

diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Tue Jul 20 10:42:27 1999
+++ Src/Zle/zle_tricky.c	Tue Jul 20 11:08:31 1999
@@ -6743,8 +6743,9 @@
 	listmatches();
     if (validlist)
 	freematches();
-    lastambig = menucmp = menuacc = validlist = showinglist =
-	fromcomp = listshown = 0;
+    lastambig = menucmp = menuacc = validlist = showinglist = fromcomp = 0;
+    if (listshown < 0)
+	listshown = 0;
     minfo.cur = NULL;
     minfo.asked = 0;
     compwidget = NULL;
diff -u od/Zsh/compwid.yo Doc/Zsh/compwid.yo
--- od/Zsh/compwid.yo	Mon Jul 19 15:54:31 1999
+++ Doc/Zsh/compwid.yo	Tue Jul 20 11:14:45 1999
@@ -236,7 +236,8 @@
 behaviour of the tt(MENU_COMPLETE) or tt(AUTO_MENU) options, respectively,
 is to be used.
 
-On exit it may be set to any of the values above, or to a number, in which
+On exit it may be set to any of the values above (where setting it to
+the empty string is the same as unsetting it), or to a number, in which
 case the match whose number is given will be inserted into the command line.
 It may also be set to a string of the form `var(group):var(match)' which
 specifies a match from a group of matches to be inserted, counting from 1

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


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

* Getting completion to tell the user what to do
@ 1999-07-19 17:38 Bart Schaefer
  0 siblings, 0 replies; 4+ messages in thread
From: Bart Schaefer @ 1999-07-19 17:38 UTC (permalink / raw)
  To: zsh-users

This ought to be an easy one in the new 3.1.6 completion system, but I just
can't get it to work.

I'm trying to complete "subject string goes here" as in

	mail -s "subject string goes here"

What I want is to offer no completions at all, because the subject is free-
form text, but print a hint to the user as to what he's supposed to type.

The following almost works (inside a completion function the rest of which
is not interesting):

  compadd -S '' -X 'Please enter the subject of the message' ''

but because there's a unique completion, the explanation is printed only
when the user types ^D, and there's no beep to let him know why tab isn't
doing anything.  OK, I thought, I can force a listing:

  compadd -S '' -X 'Please enter the subject of the message' ''
  compstate[list]=list
  compstate[force_list]=yes
  compstate[restore]=no

but that doesn't work -- there's still no explanation printed.

What obvious thing have I forgotten/overlooked here?  Is there an entirely
better alternative to using compadd -X ?

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


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

end of thread, other threads:[~1999-07-20  9:16 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-07-20  7:08 Getting completion to tell the user what to do Sven Wischnowsky
1999-07-20  8:53 ` Bart Schaefer
  -- strict thread matches above, loose matches on Subject: below --
1999-07-20  9:16 Sven Wischnowsky
1999-07-19 17:38 Bart Schaefer

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