Re: Questions (and PATCH: small change to _complete)

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Nov 30,  9:35am, Sven Wischnowsky wrote:
} Subject: Re: Questions (and PATCH: small change to _complete)
}
} Bart Schaefer wrote:
} 
} > I don't see how the array would be "in the way".  It can serve the dual
} > purpose of ordering the groups and of making their names known so that
} > you know what groups it's sensible to ask for when accessing them.
} 
} To be able to define ordering of groups with such an array, we would
} have to use a normal array. If we ever want to give raw access to the
} matches and match-groups added we probably would want to use an assoc
} with the group names as keys and some information about the groups as
} the values (number of first/last match or whatever). Then we would
} have either both or something which will probably be uglier than only
} one assoc. I think. But I may be wrong.

Hmm.  I was thinking that the "some information about the groups" that
you'd want to be able to access would in fact be the matches that are
in that group.  Since we still haven't solved the issues of having an
assoc whose values are arrays, I'd assumed that access to the matches
would not be through an assoc, and hence that you'd need to know what
groups existed.

} > Here's a question ... why isn't $curcontext an array?  Is it really an
} > advantage for it to be a colon-separated string?  And if it is, why not
} > tie the regular array to a colon-array and get both for free?
} 
} I used the colon-separated string because 1) I liked making them look
} a bit like other hierarchical names users already know (pathnames, of
} course) and 2) it was clear from the beginning that they would be used 
} for pattern matching and `*:dvips:-o*' looks more friendly than
} `*" dvips -o"*' or some such.

On the other hand, "dvips:-o" doesn't look like what one might actually
see on the command line, whereas "dvips -o" does.  Dunno whether that's
potentially less confusing, or more so.

} However, if we use an array, we could
} make this look like one of those X.400 names:
} 
}   ( completer=complete command=dvips option=-o argument=1 tag=all-files)

This is somewhat like the ksh syntax for assigning to multiple keys of
an assoc.  I believe that would actually look like

  ( [completer]=complete [command]=dvips [option]=-o ... )

(I resisted attempting this for zsh because it means making the RHS of an
array assignment into a special semantic context in which globbing does
not occur unless the LHS is a normal array, and I didn't feel like doing
that much violence to the parser.)

} Maybe going a bit too far?

It does bring up the possibility of actually making $curcontext an assoc,
although that probably *is* going to far at this point.

} Or maybe not... And would probably call for 
} help by some builtin to define patterns for such names.

Eh?

} But still, saving and restoring these things would be costlier than
} the simple `local curcontext="$curcontext"' we have now.

True.

} And the main question: as long as we don't use the `...=...' syntax
} above, when do we need to access single components? Currently we don't.

It would have the advantage of removing any ambiguity about whether a
given character was part of one of the elements or merely a separator.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com