zsh-workers
 help / color / mirror / code / Atom feed
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: using modules in completion functions
Date: Wed, 5 Jul 2000 16:34:49 +0200 (MET DST)	[thread overview]
Message-ID: <200007051434.QAA11785@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Oliver Kiddle's message of Wed, 05 Jul 2000 15:06:30 +0100


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


             reply	other threads:[~2000-07-05 14:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-07-05 14:34 Sven Wischnowsky [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-07-05 14:06 Oliver Kiddle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200007051434.QAA11785@beta.informatik.hu-berlin.de \
    --to=wischnow@informatik.hu-berlin.de \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).