zsh-workers
 help / color / mirror / code / Atom feed
* (file) completion in compinstall
@ 2000-04-28 11:13 Andrej Borsenkow
  2000-04-28 11:56 ` Peter Stephenson
  0 siblings, 1 reply; 3+ messages in thread
From: Andrej Borsenkow @ 2000-04-28 11:13 UTC (permalink / raw)
  To: ZSH workers mailing list

As I understand, compinstall is using vared to get input. Currently,
completion in the first prompt (for the file name) tries to complete
commands; I did not try any other (is there anything accept file names
that may be sensibly completed? I believe, everything else is menu
driven or free text input)

You understand, for any Zsh user hitting TAB becomes the second nature
... :-)

-andrej

Have a nice DOS!
B >>


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

* Re: (file) completion in compinstall
  2000-04-28 11:13 (file) completion in compinstall Andrej Borsenkow
@ 2000-04-28 11:56 ` Peter Stephenson
  0 siblings, 0 replies; 3+ messages in thread
From: Peter Stephenson @ 2000-04-28 11:56 UTC (permalink / raw)
  To: Zsh hackers list

> As I understand, compinstall is using vared to get input. Currently,
> completion in the first prompt (for the file name) tries to complete
> commands; I did not try any other (is there anything accept file names
> that may be sensibly completed? I believe, everything else is menu
> driven or free text input)

I was going to remark on this, too, but forgot.  As far as I know,
completion usually just treats a line of vared input exactly the same way
as an ordinary command line.  This is very rarely the most useful
behaviour; a better default would be ordinary default completion,
i.e. assume a null command and treat the rest as command words.

There's some low-level support: compstate[vared] gets set to the name of
the parameter being edited and can be detected in completion functions.
However, there doesn't seem to be any support in the function system with
the exception of some commented-out code in _first, which would treat the
line being edited as if you were editing an assignment to that variable.  I
can't remember why that's not the default.

It might be possible to change this in compinstall by setting
compstate[context] directly, but come to think of it, I doubt if it
actually is possible outside a completion widget.  Even then, making the
value local would be unpleasant.

I'd prefer a more general solution to completion with vared, if Sven has
any ideas...

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


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

* Re: (file) completion in compinstall
@ 2000-04-28 12:14 Sven Wischnowsky
  0 siblings, 0 replies; 3+ messages in thread
From: Sven Wischnowsky @ 2000-04-28 12:14 UTC (permalink / raw)
  To: zsh-workers


Peter Stephenson wrote:

> > As I understand, compinstall is using vared to get input. Currently,
> > completion in the first prompt (for the file name) tries to complete
> > commands; I did not try any other (is there anything accept file names
> > that may be sensibly completed? I believe, everything else is menu
> > driven or free text input)
> 
> I was going to remark on this, too, but forgot.  As far as I know,
> completion usually just treats a line of vared input exactly the same way
> as an ordinary command line.  This is very rarely the most useful
> behaviour; a better default would be ordinary default completion,
> i.e. assume a null command and treat the rest as command words.
> 
> There's some low-level support: compstate[vared] gets set to the name of
> the parameter being edited and can be detected in completion functions.
> However, there doesn't seem to be any support in the function system with
> the exception of some commented-out code in _first, which would treat the
> line being edited as if you were editing an assignment to that variable.  I
> can't remember why that's not the default.

Now that you say that... neither can I.

> It might be possible to change this in compinstall by setting
> compstate[context] directly, but come to think of it, I doubt if it
> actually is possible outside a completion widget.  Even then, making the
> value local would be unpleasant.

You can't, $compstate is not available there.

> I'd prefer a more general solution to completion with vared, if Sven has
> any ideas...

That's what $compcontext is for. Similar to what Functions/Misc/nslookup
does, you just do:

  local compcontext=compinstall

And then have a completion function with `#compdef compinstall'. There 
you either unconditionally complete for inside of compinstall or, like 
_nslookup, you first test `[[ -n "$compcontext" ]]' to see if you are
completing inside compinstall or its arguments.

Using the indirection ($compcontext gives a context which is looked up 
in $_comps) allows users to override the default implementation with
their own functions, as usual.

Is that enough and clean enough?

Bye
 Sven


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


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

end of thread, other threads:[~2000-04-28 12:14 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-28 11:13 (file) completion in compinstall Andrej Borsenkow
2000-04-28 11:56 ` Peter Stephenson
2000-04-28 12:14 Sven Wischnowsky

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