From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21656 invoked by alias); 3 Jun 2011 06:34:44 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 29442 Received: (qmail 20301 invoked from network); 3 Jun 2011 06:34:41 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <110602233427.ZM16440@torch.brasslantern.com> Date: Thu, 02 Jun 2011 23:34:24 -0700 In-reply-to: Comments: In reply to Richard Hartmann "ENBF or similar for making zsh etc aware of a programs' syntax? (was: "Re: minor annoyance with zsh and git flow" on -users)" (Jun 3, 2:35am) References: X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh workers Subject: Re: ENBF or similar for making zsh etc aware of a programs' syntax? (was: "Re: minor annoyance with zsh and git flow" on -users) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Jun 3, 2:35am, Richard Hartmann wrote: } } Basically, my idea was to define a generic syntax file for programs, } potentially using ENBF. That could be used to (auto)build completions, } colour the prompt, syntax-check commands and scripts, automated tests, } automagic building/verification of piped commands and a ton of other } things. Without wanting to be discouraging ... We had a discussion about this kind of thing a very long time ago when the completion function system was being developed, and concluded that the shell already has one language parser built into it, so rather than create another one, compsys is all defined in terms of shell functions. I'm also skeptical of (a) the ability of such a language to describe an arbitary command's option syntax -- callers of _arguments often must resort to state machines; command options don't follow consistent grammar rules, and the whole point of completion is that it's context sensitive, whereas EBNF describes a context-insensitive syntax -- and (b) the practicality of creating the necessary library of descriptions of commands -- just as an example, there are more than 6500 packages in the yum repositories I use for CentOS, but only 660 files in the zsh completion library. On the flip side, I'd also encourage you to do a bit of research into work that has already been in this direction. A couple of minutes of searching found for example http://www.jnode.org/ which describes a shell where all the commands describe their syntax in an XML format. However, in jnode it was clearly a design decision that commands use a consistent option syntax. In summary, I think you've got a lot of work cut out for you to build enough community interest to make this idea workable. --