* Felix Rosencrantz <f.rosencrantz@gmail.com> [Dec 03, 2004 15:11]:
> Viewing completion function files under the cvs tree (e.g.
> Completion/Unix/Type/_files)  It seems like both of these syntax files
> had some problems with variable syntax.  Though Nikolai's seems to
> behave better.

It should, it doesn't try to highlight very much.

> Though Nikolai's had problems with variables not listed in braces
> (e.g. $#foo would only highlight the '$#'). It would only highlight
> the first character.

This is intentional.  Well, at least somewhat.  The $# in the part of
$#foo shouldn't be, I fixed that (but $# on its own should).

My reasoning is that you want "special" variables, such as $#, $n, and
the like to be highlighted, as well as advanced stuff such as ${...}
allows, but not necesarilly $foo, as the highlighting can become rather
cluttered, as in the standard Vim one.

The question is, does this make sense to most other people?

I'm actually thinking that none of them should be highlighted, not even
those that are "special".  Any input?

Three choices:

1.  Highlight all variable references alike.
2.  Highlight only "special" variables, such as $$, $#, and $n.
3.  Highlight no variable references at all.

If you look at the C syntax definition, no variable references are
highlighted, and this isn't only due to the fact that it is infinitely
much harder to determine what a variable in C (no marking $) is but also
to keep things simple and clean.  Variables are everywhere, so
highlighting all of them makes the display cluttered.

> I would like to see the syntax files be able to handle more of the
> parameter expansion  syntax and flags (like found in man zshexpn) .
> It would be nice if it could color things like:
> "${(@j:|:M)${(@)tmp#-}#?}" or show an error if it saw code like
> "${(b)tmp} ('b' is not a valid flag).

I have come, after much experimentation and many syntax definitions for
many different kinds of formats and languages, that trying to do syntax
validation in a syntax definition is not the right place.  One may
debate that certain errors can and should be caught in the syntax
definition, but I hardly see ${(b)tmp} to be an instance of this case.
The problem is that once the 'b' becomes a valid flag, the syntax
definition is more or less useless, as it will report false information
to its user.

> Also things like the first line #compdef or #autoload lines are not
> marked or highlighted in any way, other than as a comment.

Hm, that's an interesting suggestion.  The #! /bin/shell stuff should
perhaps also be highlighted.  It's simple enough to add.

Could you perhaps point me to where I find the exact information that
may appear in a beginning comment line?  I always seem to lose that
page in the info pages.
	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);}