Re: off topic

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

Bart wrote:
> I've had the below kicking around for a while, was planning to post it
> after 5.3 was out but might as well offer it for comments.  This is

> It's also designed to be source-able at any point either before or
> after the user's own zstyles without stomping on anything.

Rather than a source-able file, would it perhaps make sense to embrace
the concept of plugins.
It's a concept that people are familiar with from other software.
With vim for example, it is common to have a list in .vimrc, e.g:
  call plug#begin('~/.vim/plugged')
  Plug 'surround.vim'
  Plug 'tommcdo/vim-exchange'
  ...

The various existing zsh plugin managers are similar.

One well known plugin named sensible.vim is similar to what you
posted: defaults everyone can agree on.

I think it also tends to result in better maintained plugins when people
keep their own plugin in their own github area vs. an omz pull request
and then assuming that the omz people will look after it thereafter.

As a first step, we could add an Etc/plugin-guide file to outline
conventions such as how structure a plugin, use of add-zsh-hook,
how to avoid trampling on the rest of the user's setup. default_zstyle
could perhaps be included in Misc (or added as an option to zstyle).
Name of path variable which is used when searching for plugins, etc.
The omz convention seems to be a single file with the extension
.plugin.zsh which is sourced but there may be more to it than that.
We also need to think about the order in which commands are run.

We could include a rudimentary plugin manager. So people would do
something like:
  autoload -U pluginit; pluginit
  plug zsh-syntax-highlighting
  plug zsh-viexchange
Or they could continue using zplugin or whatever else if they want
fancy features like coloured github updates. And if we've kept
things simple, it could work to just source a single file for a
plugin.

Finally, we could include the odd plugin in the distribution for
anything which could be considered fairly core - such as the sensible
defaults plugin.

> default_zstyle ':completion:*' matcher-list '' 'r:|[-._,]=** r:|=**' \
>     'm:{[:lower:][:upper:]}={[:upper:][:lower:]} r:|[-._,]=** r:|=**' \
>     'r:|[-._,]=** r:|=** l:|=*'

Given correction, _approximate and this, it ends up fairly aggressive in
changing what was typed. I'd take something more conservative. Perhaps
just lower -> upper case matching and r: stuff with a limited set of tags.
You have to know that the r: stuff is there to use it except when it
does unexpected things.
On the completer, I'd sooner have _oldlist in and skip _correct.
_extensions is fairly harmless too.

If _approximate is included, we should allow for mistyped prefixes:
  zstyle ':completion::approximate*:*' prefix-needed false

The part I probably would object most to is the ugly inclusion of the
word "Completing " in the completion headings  :)

> default_zstyle ':completion:*' format '%BCompleting %U%d%u%b'

I just use %B%d%b

Oliver