ENBF or similar for making zsh etc aware of a programs' syntax? (was: "Re: minor annoyance with zsh and git flow" on -users)

ENBF or similar for making zsh etc aware of a programs' syntax? (was: "Re: minor annoyance with zsh and git flow" on -users)

[Richard Hartmann]

Hi all,

moving to -workers and including full quote below.

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. Also, this could be shared between various programs. zsh is
obviously my main concern, but I can see this being useful across
various tools and programs. If upstreams were to maintain these
definitions, all shells and other programs interacting with a piece of
software would be able to always know what to send to and expect,
eliminating version issues, etc.

This should probably be coordinated via/pushed to freedesktop.org at some point.

I am poking this issue once again as I just stumbled across something
that could also be solved by this approach:


~ % git config -l
zsh: correct 'config' to '.config'? [N/y/a/e] a
~ %


Feedback?
Richard


On Thu, May 26, 2011 at 13:16, Richard Hartmann
<richih.mailinglist@gmail.com> wrote:
> On Thu, May 26, 2011 at 02:22, Bart Schaefer <schaefer@brasslantern.com> wrote:
>
>> Of course the root of all this is that "subcommands" are not a concept
>> that unix-derived shells were ever designed to deal with.  This ...
>
> You are raising an interesting point. Realistically speaking, love it
> or hate it, this kind of syntax will only become more common over time
> which means a way to deal with this generically would be helpful.
>
> Of course, this more or less requires zsh to actually know what
> commands a program can understand and with what syntax. Part of this
> information could be gleaned from completions, I guess.
>
> A different approach would be to define syntax files for commands
> (EBNF?) which could be distributed with the programs themselves or at
> least shared between shells. Dreaming some more, this could then even
> be helpful for zsh's long-long-term possibility of syntax highlighting
> capabilities..
>
>
> I'll stop babbling now, but the more I think about it, the more I
> think it's an interesting idea...
>
>
> Richard
>
> PS: If zsh, Bash, fish, you name it could generate their own
> completion definitions from EBNF or similar, this could be a huge
> boost to having current completions everywhere.
>
> PPS: And it could even solve the old "keep zsh's git completion in
> git's git or zsh's" debate.
>



-- 
Richard

Re: ENBF or similar for making zsh etc aware of a programs' syntax? (was: "Re: minor annoyance with zsh and git flow" on -users)

[Bart Schaefer]

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.

--