zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh workers <zsh-workers@zsh.org>
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	[thread overview]
Message-ID: <110602233427.ZM16440@torch.brasslantern.com> (raw)
In-Reply-To: <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
} 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.

-- 


      reply	other threads:[~2011-06-03  6:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-03  0:35 Richard Hartmann
2011-06-03  6:34 ` Bart Schaefer [this message]

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=110602233427.ZM16440@torch.brasslantern.com \
    --to=schaefer@brasslantern.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).