zsh-workers
 help / color / mirror / code / Atom feed
* Re: using modules in completion functions
@ 2000-07-05 14:34 Sven Wischnowsky
  0 siblings, 0 replies; 2+ messages in thread
From: Sven Wischnowsky @ 2000-07-05 14:34 UTC (permalink / raw)
  To: zsh-workers


Oliver Kiddle wrote:

> While looking through the manual, I noticed the disable-stat style is
> used for cvs completion when deciding whether to load the stat module.
> For completing file descriptors, I had taken a different approach where
> the stat module was used if already loaded but if not, ls is used. I
> would expect that it will be a fairly common situation that we will
> have where a completion function can make good use of a module but can
> cope without it and we have to decide whether or not to use it. It
> would therefore be a good idea if we agreed on a common way to handle
> this.
> 
> What I would suggest is a style named something like use-module which
> can be set to one of three values which would correspond to:
> 1. always use the module, loading it if necessary
> 2. never use the module
> 3. use the module but only if it is already loaded
> where the third should probably be the default
> 
> The name of the module could be placed somewhere in the context. Where
> would it make sense to put it - the argument, as a sub-command or
> elsewhere?

I'd think: as the tag, if at all.

> If it can't go in the context, I suppose we could have
> separate styles such as use-module-stat but that wouldn't be so good in
> my opinion.

Or use only one style and the value gives the names of the modules to
use with some kind of token to distinguish between `load always' and
`use if loaded'. If you really want that, because, if the module is
already loaded, why not use it unconditionally? I mean, it should be
faster than any alternative, otherwise using the module doesn't make
sense anyway. In that case the style could be named `load-module', if
course.


Bye
 Sven


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


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

* using modules in completion functions
@ 2000-07-05 14:06 Oliver Kiddle
  0 siblings, 0 replies; 2+ messages in thread
From: Oliver Kiddle @ 2000-07-05 14:06 UTC (permalink / raw)
  To: zsh-workers

While looking through the manual, I noticed the disable-stat style is
used for cvs completion when deciding whether to load the stat module.
For completing file descriptors, I had taken a different approach where
the stat module was used if already loaded but if not, ls is used. I
would expect that it will be a fairly common situation that we will
have where a completion function can make good use of a module but can
cope without it and we have to decide whether or not to use it. It
would therefore be a good idea if we agreed on a common way to handle
this.

What I would suggest is a style named something like use-module which
can be set to one of three values which would correspond to:
1. always use the module, loading it if necessary
2. never use the module
3. use the module but only if it is already loaded
where the third should probably be the default

The name of the module could be placed somewhere in the context. Where
would it make sense to put it - the argument, as a sub-command or
elsewhere? If it can't go in the context, I suppose we could have
separate styles such as use-module-stat but that wouldn't be so good in
my opinion.

Oliver


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

end of thread, other threads:[~2000-07-05 14:35 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-07-05 14:34 using modules in completion functions Sven Wischnowsky
  -- strict thread matches above, loose matches on Subject: below --
2000-07-05 14:06 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).