Zsh Mailing List Archive
Messages sorted by:
Re: ENBF or similar for making zsh etc aware of a programs' syntax? (was: "Re: minor annoyance with zsh and git flow" on -users)
- X-seq: zsh-workers 29442
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh workers <zsh-workers@xxxxxxx>
- 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)
- Date: Thu, 02 Jun 2011 23:34:24 -0700
- In-reply-to: <BANLkTi==fVQ8gmkc+5Nnkq4vZBHUngY6JQ@mail.gmail.com>
- List-help: <mailto:email@example.com>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <BANLkTi==fVQ8gmkc+5Nnkq4vZBHUngY6JQ@mail.gmail.com>
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
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.
Messages sorted by: