From: Richard Hartmann <richih.mailinglist@gmail.com>
To: zsh workers <zsh-workers@zsh.org>
Subject: ENBF or similar for making zsh etc aware of a programs' syntax? (was: "Re: minor annoyance with zsh and git flow" on -users)
Date: Fri, 3 Jun 2011 02:35:58 +0200 [thread overview]
Message-ID: <BANLkTi==fVQ8gmkc+5Nnkq4vZBHUngY6JQ@mail.gmail.com> (raw)
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
next reply other threads:[~2011-06-03 0:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-03 0:35 Richard Hartmann [this message]
2011-06-03 6:34 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='BANLkTi==fVQ8gmkc+5Nnkq4vZBHUngY6JQ@mail.gmail.com' \
--to=richih.mailinglist@gmail.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).