From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-request@euclid.skiles.gatech.edu>
Received: (qmail 3240 invoked from network); 3 Jul 1997 10:56:45 -0000
Received: from euclid.skiles.gatech.edu (list@130.207.146.50)
  by ns1.primenet.com.au with SMTP; 3 Jul 1997 10:56:45 -0000
Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id GAA23844; Thu, 3 Jul 1997 06:43:58 -0400 (EDT)
Resent-Date: Thu, 3 Jul 1997 06:43:58 -0400 (EDT)
Date: Thu, 3 Jul 1997 14:48:31 +0400 (MSD)
From: Andrej Borsenkow <borsenkow.msk@sni.de>
X-Sender: bor@itsrm1
Reply-To: borsenkow.msk@sni.de
To: Zsh workers mailing list <zsh-workers@math.gatech.edu>
Subject: Suggestion for completion interface
Message-ID: <Pine.SV4.3.95.970703140557.4351H-100000@itsrm1>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-ID: <"YYf_T2.0.Vq5.j9ukp"@euclid>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/3346
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

Currently coompletion is tightly coupled with several ZLE widgets; it is
impossible to use completion is user-defined widgets, also it impossible
to add extensions to completion (notorious colour-ls patch).

May be, it possible to slightly change interface. The idea is:

  completion should just build a list of possible choices. It can
  return it e.g. in define ZSH variable, let's say COMPLETION_RESULT
  
  ZLE should provide widget(s), which just takes as argument given list
  of choices and implement usual list/menu selection (well, it is no
  more completion)

  then current widgets, like complete-word, list-choices etc can be
  redefined in terms of call to completion followed by call to 
  selection widget.

  hard part is providing hooks to user-extensions. One possibility is,
  that selection widgets operate on two arrays - one with actual choices
  and other with "user visible" ones. It will make colour patch 
  really simple.

All the above has probably some advantages:

  1. there were several requests about calling completion from user
     functions. The above changes make it at least possible to call
     coompletion in widgets (were input is clear defined).

  2. It makes it possible to create custom completion widgets. Currently
     I have to define completion for _every_ command I use. With
     suggested changes it would be possible to create widget
        zle-select-user with contents like
           ZLE_CHOICES=("${(@)${(f@)$(</etc/passwd)}%%:*}")
           zle select-word
     asuming, that select-word operates on ZLE_CHOICES array.

     then I could do "bindkey ^Xu zle-select-user" and use ^Xu in 
     _every_ command to simply complete/select user name in _any_
     command position.

  3. Well, if e.g. selct-word will operate on two arrays (internal and
     user-visible) then colours in ZSH could be implemented as

       zcomplete                # call completion
       ZLE_CHOICES_INTERNAL=COMPLETION_RESULT
       ZLE_CHOICES_USER=...     # what ever needs to be done to colour
                                # file names and so on. stat module comes
                                # handy
       zle menu-select          # calls widget, which presents user
                                # elements of ZLE_CHOICES_USER but
                                # passes to ZSH corresponding elements
                                # ZLE_CHOICES_INTERNAL

     such widget could the be used instead of complete-word.

If course, it is only idea. The widgets should probbaly know much more
about current completion environment than just it's results - such as
what is completed (it could be vars, options and so on - not only files)
so that user widget can decide, if it needs to mark files at all.

Just interested, is it all sounds reasonable.

-------------------------------------------------------------------------
Andrej Borsenkow 		Fax:   +7 (095) 252 01 05
SNI ITS Moscow			Tel:   +7 (095) 252 13 88

NERV:  borsenkow.msk		E-Mail: borsenkow.msk@sni.de
-------------------------------------------------------------------------