From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15086 invoked by alias); 2 May 2010 09:08:28 -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: 27943 Received: (qmail 19956 invoked from network); 2 May 2010 09:08:26 -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 brasslantern.com does not designate permitted sender hosts) MIME-Version: 1.0 In-Reply-To: <12855ad6dba.6318419370147111815.5595086135333789265@dorfelite.net> References: <12854b73c24.-5662614641985446414.-6364714751911043221@dorfelite.net> <1285584468e.-5976807992945925025.-2686280647114173652@dorfelite.net> <12855ad6dba.6318419370147111815.5595086135333789265@dorfelite.net> Date: Sun, 2 May 2010 02:08:21 -0700 Message-ID: Subject: Re: Added builtins per runtime From: Bart Schaefer To: Christoph Kappel Cc: zsh-workers@zsh.org Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 1, 2010 at 2:02 PM, Christoph Kappel wrote: > > That was exactly my question. Can a module change it's features per runtime? There doesn't appear to be any reason that a module could not provide a builtin (or even, I suppose, a parameter) that modifies the module's own features array on the fly. The effect would need to be the same as if "zmodload -F" had been invoked to enable the newly-materialized feature. > Generally the use of the word feature in the doc is really confusing, reading the > coding makes it's even worse when a feature struct contains lists of builtins, > condistions etc. which are called features too. > > The doc also doesn't make very clear what abstracts. The concept of features (as in the feature struct) was only recently introduced, and was layered on top of the existing implementation of builtins/parameters/etc. The abstraction may therefore be a bit less clean than one would find if it had been designed from scratch. > I basically want to provide a builtin/feature/whatever that provides a way to add > actions in another language - ruby in my case. I suspect that what you mean by this is that you intend to link a ruby interpreter to zsh, and you want to permit interpreted functions defined in ruby to appear on the fly as builtin commands from the point of view of the zsh interpreter. It might be possible to do that, because the same C function defined in the module can be called under multiple names. However, I'd suggest that you start by having a single builtin that invokes the ruby interpreter and pass it the name of the ruby function as its first argument, rather than attempt to create a new builtin for every function.