From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3286 invoked from network); 14 Feb 2000 10:50:25 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 14 Feb 2000 10:50:25 -0000 Received: (qmail 9098 invoked by alias); 14 Feb 2000 10:50:19 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9712 Received: (qmail 9089 invoked from network); 14 Feb 2000 10:50:19 -0000 X-Envelope-Sender-Is: Andrej.Borsenkow@mow.siemens.ru (at relayer goliath.siemens.de) From: "Andrej Borsenkow" To: "ZSH workers mailing list" Subject: RFD: Zsh styles and OOP ... Date: Mon, 14 Feb 2000 13:50:06 +0300 Message-ID: <000101bf76d9$415ce110$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Unfortunately, no ready-for-implementation ideas ... just some speculations. To put in general way, styles are used to define properties of objects. Even if we speak only about completion, there are already more than one sort (type? class?) of objects there. 1. list of generated matches 2. completion functions (every functions - not just completers) 3. completion system widgets 4. completion system as whole Each of these classes really has it's own hierarchy (if at all) and should reasonably have it's own namespace. Unfortunately, the way contexts are defined currently makes no difference between different objects putting all of them in single namespace (that actually is appropriate only for matches list). This gives way to confusing settings like zstyle :completion:* completers _complete that implies, that you can define different copmpleters for diff and gzip, while completers is actually a property of completion widget(s) Another example is setting of ps arguments, hosts dastabase, rgb database and such. I can hardly imagine setup, where kill and killall would use different settings for ps arguments; or different X commands would use different rgb or font database. Again, these styles are actually property of completion system as a whole or at least some helper functions. And in any case, they are independent of current command, argument position etc. I believe, it would be of real help to developers as well to - clear define what sorts of objects exist - what properties do they have - use context names, that refelect actual object hierarchy without need of dummy placeholders or fake "match it all" entries It would of much help to users if they had context/tags/styles descriprion divided into subgroups for every object type instead of current long list. Not sure how interesting it is ... /andrej