zsh-users
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: zsh-users@zsh.org
Subject: Re: off topic
Date: Sat, 10 Dec 2016 03:50:26 +0100	[thread overview]
Message-ID: <95362.1481338226@hydra.kiddle.eu> (raw)
In-Reply-To: <161209165454.ZM9226@torch.brasslantern.com>

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


  reply	other threads:[~2016-12-10  2:57 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20161209130109epcas2p1fd786d46827852a8cf1badcb5d003ec9@epcas2p1.samsung.com>
2016-12-09 12:29 ` vi mode reset Christian Brabandt
2016-12-09 14:33   ` Ray Andrews
2016-12-09 14:41   ` Peter Stephenson
2016-12-09 14:44   ` Oliver Kiddle
2016-12-09 15:07     ` off topic Ray Andrews
2016-12-09 16:28       ` Oliver Kiddle
2016-12-09 17:45         ` Ray Andrews
2016-12-10  0:54           ` Bart Schaefer
2016-12-10  2:50             ` Oliver Kiddle [this message]
2016-12-10  3:13               ` Bart Schaefer
2016-12-10  3:31               ` Ray Andrews
     [not found]             ` <95362.1481338226__15466.9970310808$1481338718$gmane$org@hydra.kiddle.eu>
2016-12-11  4:32               ` Daniel Shahaf
2016-12-11 17:07                 ` Ray Andrews
2016-12-11 17:19                   ` Bart Schaefer
2016-12-11 18:02                     ` Ray Andrews
2016-12-11 19:20                       ` Bart Schaefer
2016-12-11 20:23                         ` Ray Andrews
     [not found]         ` <584AEDBF.2050402__19991.0537027337$1481307418$gmane$org@eastlink.ca>
2016-12-09 19:24           ` Daniel Shahaf
2016-12-09 20:25             ` Ray Andrews
     [not found]             ` <584B1325.1010907__10266.7204490446$1481316980$gmane$org@eastlink.ca>
2016-12-10  0:14               ` Daniel Shahaf
2016-12-10  0:21                 ` Ray Andrews
2016-12-12 13:11         ` Vincent Lefevre
2016-12-09 15:48     ` vi mode reset Christian Brabandt
2016-12-09 16:46       ` Oliver Kiddle
2016-12-09 20:24         ` Christian Brabandt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=95362.1481338226@hydra.kiddle.eu \
    --to=okiddle@yahoo.co.uk \
    --cc=zsh-users@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).