From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2080 invoked from network); 9 Jun 1998 19:16:47 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 9 Jun 1998 19:16:47 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id PAA16735; Tue, 9 Jun 1998 15:11:20 -0400 (EDT) Resent-Date: Tue, 9 Jun 1998 15:11:20 -0400 (EDT) From: "Bart Schaefer" Message-Id: <980609121203.ZM6732@candle.brasslantern.com> Date: Tue, 9 Jun 1998 12:12:03 -0700 In-Reply-To: <199806091801.TAA04656@taos.demon.co.uk> Comments: In reply to Zefram "Re: User-defined zle widgets and built-in widget failure" (Jun 9, 7:01pm) References: <199806091801.TAA04656@taos.demon.co.uk> X-Mailer: Z-Mail (5.0.0 30July97) To: Zefram Subject: Re: User-defined zle widgets and built-in widget failure Cc: zsh-workers@math.gatech.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"hRMUC1.0.Q54.NZOVr"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4067 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Jun 9, 7:01pm, Zefram wrote: } Subject: Re: User-defined zle widgets and built-in widget failure } } The mechanism I planned is that each thingy will include a single-bit } flag, which can be tested and modified using the zle builtin. Then all } you do to test for error is "if zle -F feep; ...", where the value of } "F" has yet to be determined. I think we should tie the most common cases to standard scripting concepts; e.g., failure should be a nonzero $?, and the numeric value of $? should indicate the reason for failure. It shouldn't be necessary to invoke "zle" multiple times to find out this kind of basic information; further, it makes it obvious how a widget writer sets the value, i.e., with "return". } Or a more general possibility would be thingy array variables } accessible via thingy names Just how many thingys are we talking about here? I suggest defining one array variable $ZLE (or whatever name you want), and define the meanings of the array positions. E.g., ZLE could be equivlent to ($BUFFER $CURSOR $LBUFFER $RBUFFER) in the current scheme; instead of BUFFER="the text here" you'd say ZLE[1]="the text here". (I don't think you should literally do that, because the buffer chunks are best accessed directly as scalars, but for purposes of example ...) } (though I'd want to do a proper namespace separation, e.g., ${zle.feep}). You're creeping dangerously close to Perl associative arrays, there. Unless we're talking about a huge amount of data, just use numbered positions in an array with a "sufficiently unique" name. } That reminds me, more generally I'd like to move the zsh-specific } parameter names to completely separate names that can't conflict } with POSIX parameter names. If we have ${zsh.module_path} instead of } $module_path, then this can be available regardless of the name used to } invoke zsh. What do people think? I think I'd rather not have to rewrite my .z* scripts again. How much "moving" are we talking about? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com