Re: Vim syntax file for zsh

[Nikolai Weibull <mailing-lists.zsh-users@xxxxxxxxxxxxxxxxxxxxxx>]

* Felix Rosencrantz <f.rosencrantz@xxxxxxxxx> [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);}