From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19374 invoked from network); 9 Dec 2004 18:19:10 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 9 Dec 2004 18:19:10 -0000 Received: (qmail 3579 invoked from network); 9 Dec 2004 18:19:04 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 9 Dec 2004 18:19:04 -0000 Received: (qmail 20220 invoked by alias); 9 Dec 2004 18:18:14 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8280 Received: (qmail 20211 invoked from network); 9 Dec 2004 18:18:13 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 9 Dec 2004 18:18:13 -0000 Received: (qmail 2258 invoked from network); 9 Dec 2004 18:18:13 -0000 Received: from mxfep01.bredband.com (195.54.107.70) by a.mx.sunsite.dk with SMTP; 9 Dec 2004 18:18:12 -0000 Received: from puritan.pcp.ath.cx ([213.112.43.197] [213.112.43.197]) by mxfep01.bredband.com with ESMTP id <20041209181811.JTHC18879.mxfep01.bredband.com@puritan.pcp.ath.cx> for ; Thu, 9 Dec 2004 19:18:11 +0100 Received: by puritan.pcp.ath.cx (Postfix, from userid 1000) id B4BA4AE045; Thu, 9 Dec 2004 19:18:13 +0100 (CET) Date: Thu, 9 Dec 2004 19:18:13 +0100 From: Nikolai Weibull To: zsh-users@sunsite.dk Subject: Re: Vim syntax file for zsh Message-ID: <20041209181813.GF9424@puritan.pcp.ath.cx> Mail-Followup-To: zsh-users@sunsite.dk References: <20041201120202.GB9543@puritan.pcp.ath.cx> <20041204164217.GA20437@puritan.pcp.ath.cx> <20041208134714.GB10098@puritan.pcp.ath.cx> <20041208181429.GC10098@puritan.pcp.ath.cx> <902B4263-49EA-11D9-A14D-000A95D2C79E@kalama.no-ip.org> <20041209144520.GC9424@puritan.pcp.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: * X-Spam-Status: No, hits=1.5 required=6.0 tests=RCVD_IN_SORBS autolearn=no version=2.63 X-Spam-Hits: 1.5 * Felix Rosencrantz [Dec 09, 2004 17:40]: > 1. When I first read your message, I sort of expected that it would > highlight the special variables differently, even if I used the "all" > setting. It doesn't do that, though that might be nice. Hm, this'll make it too complex. One of the reasons i wrote this was because the distributed one was highlighting all kinds of craps as special, which are in turn highlighted as dark red on my display...very annoying. > 2. Strings: These snippets of code all color the same and probably > shouldn't, the embedded variable reference in double quotes should be > colored. > 'SUSFU' > 'SU$FU' > "SU$FU" True, I'll contain stuff like that in "..." strings. > 3. Backquotes: While `su$fu` does not highlight the string itself, > except for the variable reference. Ah, seems I forgot about the old-style command expansions, either intentionaly or otherwise. They should be frowned upon, but I'll add highlighting for them nonetheless. As it is now, embedded \` will be highlighted as special characters, which they aren't (they're recursive backquotes), but I think that works out as an advantage, as it will make them more visible. > 4. Keyword Highlighting: Some unusualness with the local keyword and > it's args: In _files, I notice at the very start some odd coloring on > the word type, since it is a keyword. Though in this situation it is > meant to be a local variable name: local type sdef > Also for keywords that seem to be arguments, same file the argument > "r:" stands out when it shouldn't: zparseopts blah blah r: blah blah > This is more a problem with where keywords are found. Many keywords > should only be marked as keywords when they are in a command position. > Not sure if this is easy to do... Yeah, this can be rather hard to get right, as commands can occur at so many different places. It would really require a parser to get this right. The upshot is, don't call variables by names that are also keywords. > 5. Assignments in Local: The assignment on the local line causes the > left side of the assignment to be colored, which causes "ret=0" to > standout in a distracting way, since the other variables are not > highlighted... In this case it seems like the other variables should > either be highlighted like lvalues or the "ret" should not be > highlighted....: > local sus fu foo ret=0 bar Well, that could be up for debate as well. Since it is an assignment, it should be highlighted as such in my opinion...surely sus, fu, foo, and bar get assigned to further down as well, where they will be highlighted correctly. That it stands out should only hint further that ret has been assigned to separately from the others, making sure that ret will be initialized correctly before use. Perhaps this should all be covered by another variable, like zsh_syntax_assignments? My big issue with assignments are with array subscript assignments, with which I'm not sure that it's working correctly for every instance. It has to be implemented as a region, as the subscript can be just about anything (well a substitution of some sort at least). nikolai -- ::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka ::: ::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden ::: ::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,lisp,war3 ::: main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}