Style mechanism discussion

[Peter Stephenson <pws@pwstephenson.fsnet.co.uk>]

Sven Wischnowsky wrote:
> Another question is whether we should at least try to group the styles 
> in some sensible way. Probably even using subsections. Opinions?

As long as they've got obvious names, I don't think it matters.  Calling
things e.g. section.foo and section.bar is only better than foo and bar if
section is really adding to the information, and even in that case it's
probably easier just to change the name to section_foo and section_bar ---
I don't think use of different namespaces is really necessary here.  Unless
I've missed the point of this.

> The completion code would use names of the form `:completion:...' and
> stuffing that `:completion' in front would be the main task of
> `compstyle'. If styles are used elsewhere, they would use different
> prefixes (`:prompt'? `:zftp'?)

These sound like good possibilities.  Maybe we could even have our
long-awaited improved interface to shell options via an `:option' set of
styles.  But we would need to keep the current option interface, too: it
would be a very nasty change otherwise and make zsh completely unlike other
shells.  This would limit the behaviour of the new interface just to be a
front-end to option setting.  Even that's probably quite useful.

> and probably their own *style functions 
> unless we decide to only use the builtin (i.e. all styles, independent 
> of the package-prefix) everywhere -- then compstyle would/could/should
> be removed, too.

Perhaps it's easiest just to have zstyle and specify the utility
explicitly, i.e.

  zstyle ':completion:*:default' list-colors ${(s.:.)LS_COLORS}

etc., avoiding proliferating commands of any kind.  As long as the styles
don't overlap between utilities, the `:completion' is redundant with the
`*' already in front; and if styles do overlap between utilities, we should
probably try and make them do consistent things anyway.  For example, the
host/user name styles in completion could probably be re-used in zftp.

Of course, you would need to be careful to make sure things like

  compstyle ':(correct(|-word)|approximate)' accept '2n'

got converted properly, putting :completion in front.  Maybe there's a way
of making the behaviour of the tags hierarchy more transparent, but I don't
see it since it's different in different contexts (which is really exactly
why it's there).

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>