zsh-workers
 help / color / mirror / code / Atom feed
* RE: change to __path_files and clean up of Functions/Completion needed
@ 1999-02-25 15:02 Sven Wischnowsky
  1999-02-25 16:42 ` completion cleanup discussion + patch Peter Stephenson
  0 siblings, 1 reply; 6+ messages in thread
From: Sven Wischnowsky @ 1999-02-25 15:02 UTC (permalink / raw)
  To: zsh-workers


Andrej Borsenkow wrote:

> > > I think, it is unacceptable. It is the same, as if users had to modify C
> > > sources to change compctl behaviour.
> >
> > I don't think so. This is shell code after all.
> 
> O.K. I hope it is not too late.

Certainly not, we are far from a final version and it is mails like
this one that tells the more development-oriented of us what other
would like to have.

> The good old completion has some nice features:
> 
> 1. It works out-of-the-box. Not setup is needed; immediately after
> installing zsh users can start with compctl.

It's a shift of means, yes. Instead of a builtin you use functions.

> 2. it is easy to modify completion on-the-fly. What is important, it is the
> same command with the same syntax as used in startup files. It is
> invariant - 'compctl $(compctl -L cd) cd' is noop as it should be.

There are the `def*comp' functions and defining completion functions
on-the-fly isn't that complicated (and unusual) either (at least I
though that...). We probably should merge the `def*comp' functions
into `compdef' with options for defining pattern/key completion
functions and give it an option to delete definitions, btw.

> 3. it is easy to use. It is not a joke. Using compctl amounts simply to
> listing what is considered a match - no shell programming is needed. It can
> be used immediately after reading manual. (Please, I know about -K. But most
> cases are actually quite simple). What's more important, no shell
> porgramming is needed for extended/conditional completion. All is limited to
> a single command.

I had the impression that some think `compctl -x' is more complicated
than shell programming. Do not look to much at the things currently
needed, things will improve over time.

> 4. (this is of more personal nature) It does not pollute namespace (why
> don't we have anonymous functions :) It does not suddenly defines
> variables/functions/aliases that a completion user is not interested in at
> all (and probably, should not know of as well)

Not fully to the mark, but: the aliases will almost certainly
disappear in one of the next versions (at least I'm planning to remove 
them when we have the new test-syntax). Also, the global parameters
should probably be changed to `_comps' and `_patcomps', reducing the
probability of name clashes.

> I think, it is time to decide, if we want new style completion be for
> wizards only or intended for general user community. If it should be of
> general use, it should be at least as easy to use, as compctl. Exactly for
> these reasons my first reaction was to stay with compctl as a single entry
> point and use new style completion to extend it's ability.

I'd like to think the other way round: use `compctl' if you like it
and it is enough for you. If yo don't like it or you have a problem
you can't (easily) solve there, use the new completion stuff. And the
Functions/Completion we currently have are *only examples*. You can
easily write a completion widget that does:

  complete() {
    case "$COMMAND" in
    foo) ...complicated stuff for comamnd foo...;;
      ... probably for other commands ...
    *) compcall;;  # use compctl elsewhere
    esac
  }

Something like this will eventually appear as an example in the
manual, I think. The examples we currently have began with my attempt
to show that everything `compctl' does can be done with the stuff I
implemented (actually, I wanted to show that already more is possible, 
`_path_files' for example).

This, btw, is also the reason why I still don't like calling
completion widgets from `compctl'. If once `compctl' isn't enough any
more, use completion widgets. Implementing a simple one is easy and
you can still use your old `compctl's with `compcall' -- no real need
to make this two-way.

> What I suggest, is some framework that IMHO makes new completion almost as
> easy to use as compctl.
> 
> 1. use separate array (cpath?) for a completion stuff. Mixing it with fpath
> is probably a bad idea (at least, I suddenly get a bunch of autoloaded
> functions that actually dont exist :)

If you mean: another builtin path parameter I'm against it. I want the 
user to be completely free in what kind of completion code he wants to 
implement and I don't even want to direct his thinking into a certain
direction by such a parameter. If you mean that `cpath' should be used 
only in shell code, I would be for it but I would want to have the
functions autoloaded -- and for this we need `fpath' (again: this
could be solved if `autoload foo=<path>' would work).

> 2. automatically install at least run-time for new completion (and probably
> the completion for zsh builtins) in standard system-wide location and
> initialize cpath to point to this location

Again, I want the users to decide what kind of completion function
he'd like to use, so we can't pre-install something, especially not
with cpath which the user probably doesn't need.

> 3. provide a single command to make life easier (compctl is taken, sigh)
> This command would need at least
> 
>   init - initialize completion. Traverse cpath loading
>          definitions. This would allow users to
>          override system-wide completion by adding own
>          directories to cpath after system location
> 
>   load - load a (single) definition. With options to read
>          from stdio, single file or a directory. And may be
>          directly as argument. Great for testing :)
> 
>   dump - printout of current definition(s) for selected command(s)
>          (--default-- etc). This should be directly usable as input
>          to load.

Once we renamed `init' and `dump' to `compinit' and `compdump' (what
Peter probably will do in pws-10 -- at least we already talked about
it) and if we have only one function for defining them (`compdef'), we 
have almost reached the state you described. Putting everything into
one function isn't really needed, is it? Especially since dumping
won't be done that often (but adding a function that calls/sources
`init', `dump', and `compdef' depending on the options it gets would
be easy). But then again: this would be an improvement affecting (and
intersting for) only the the current example.

> 4. The run-time for completion stuff should _not_ require modification. Even
> more so, because these functions are very close to winners of Obfuscated Zsh
> Programming Contest :-)

You mean the `-M' problem, right? I moved this into the `_match_*'
functions to make it usable for all functions doing matching. But as a 
side effect this also saves users from the shock they may get when
seeing functions like `_path_files'. We should probably add comments
in `init' pointing to the places where the user might wish to look at
(as Peter did with `dump', hm, so it was only me who forgot to do
this, oops).

> This command should behave as function (or be implemented as such). This
> allows to start with emulate -RL zsh, set all needed options (extendedglob
> problem :), define any needed local variables without fear to stomp on
> user's environment. Anything, that this function exports, should 'course be
> documented.

The examples need global parameters to keep the state that has to live 
longer than the execution of the function. If we had parameter
namespaces, we could cleanly solve this (ksh has them, should we...),
and we could solve it in a way that will not collide with any
parameters used by anyone.
As to the documentation, if been thinking about this -- the question
is: where should we document it? Certainly not in the manual, since
these are only example functions like `zls'.

Bye
 Sven


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


^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: completion cleanup discussion
@ 1999-02-26 12:43 Sven Wischnowsky
  0 siblings, 0 replies; 6+ messages in thread
From: Sven Wischnowsky @ 1999-02-26 12:43 UTC (permalink / raw)
  To: zsh-workers


Bart Schaefer wrote:

> If I want to use exactly one completion for which there already happens
> to be a widget implementation, why should I have to redo all my key
> bindings and load other extra functions and dispatch-table arrays just
> to get at it?

Touche.

> If we're working out all these complex widget functions, they at least
> should be maximally re-usable.

Certainly, yes.

> What do ksh parameter namespaces look like, syntactically?

I had this from the bash-FAQ, but they aren't really supported, it
seems. But still: in ksh one can use dots in parameter names (that's
what they are referring to in the bash-FAQ). I can't find any other
fancy stuff you can do with prefixes (i.e. namespaces) in the ksh
manual now that I had a look at it. But that shouldn't stop us from
adding real namespace with the same syntax (`.complete.comps',
`.complete.patcomps') if we feel that this is interesting to have. I'm 
not proposing to implement this, though.

> Why not in the manual?  The Perl manual has sections that are entirely
> dedicated to "template" implementations of various Perl idioms.  If we do
> arrange for installation in $(libdir) of the Functions/ directory, there's
> no reason not to treat it as a real part of zsh and have a manual section
> devoted to it.

What I really meant was: not in the completion manual. As an extra
manual section (included in zshall, info, ...): ok, yes.

Bye
 Sven


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


^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~1999-02-26 12:44 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-02-25 15:02 change to __path_files and clean up of Functions/Completion needed Sven Wischnowsky
1999-02-25 16:42 ` completion cleanup discussion + patch Peter Stephenson
1999-02-23 10:26   ` change to __path_files and clean up of Functions/Completion needed Sven Wischnowsky
1999-02-25 13:32     ` Andrej Borsenkow
1999-02-26  6:39       ` completion cleanup discussion Bart Schaefer
1999-02-26 12:43 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).