Re: backward-kill-shell-word widget

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

On 10 January 2016 at 21:19, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> Since that file does have my name on it, though, I'd like to have an
> explicit license statement on it.  I am releasing my version of that
> function (the one I posted upthread) under the MIT license.  Would you
> please update the file's header to reflect the license the file is under?

Thank you. I've updated the header, and also chosen to use just MIT
for the whole project.

> Thanks for the invitation to work on the project, but it's not clear to
> me what its scope is.  Improving shell-word widgets?  Providing
> a configuration that prebinds various "kill-word under word-style X"
> widgets?

I think those two are true. I see it as:
1. Organized key bindings for command line editing widgets
2. Thoroughly tested Zsh widgets, with bug reports sent to Zsh-workers
so that the fixing patches will spread across future versions of Zsh,
so that at time of zsh-6 users will not need Zew (that would cover
"Improving shell-word widgets")
3. Replacements and configuration workarounds for buggy widgets so
that users can have robust functionality here and now, comfortably
waiting for the fixing patches to spread
4. High quality code. I have experience that in Zsh things can be
written in a more and more better way, and it hardly ever stops. Your
advice on is-at-least and autoload -Uz are good example. It's like
accumulating negentropy in a project. I wouldn't accumulate this in
plain GitHub posted .zshrc.

Examples of negentropy that I accumulated in my previous projects are:
1. repeat 1; do list=( "$@" ); done
This makes the assignment work on a fresh heap (heap arena?), so it
works faster. This heap is separated from heap used by code outside
do-done block, so that code also runs faster. Zsh-5.2 optimized heap
handling and there's no gain, but all previous Zsh versions do benefit
from this:

https://github.com/psprint/zsh-cmd-architect/blob/master/h-list#L229-L231

2. FreeBSD has TERM=xterm termcap pruned out of smcup and rmcup, thus
alternate screen doesn't work in xterm. I detect and handle this:

https://github.com/psprint/zsh-cmd-architect/blob/master/zca#L63-L81

I was doing such accumulations for 5 months with ZNT and ZCA, choosing
(#m) over (#b) to gain speed, etc. I think this is possible with
editing widgets, to accumulate sane things, and this shouldn't go to a
GitHub posted dotfile but to a project. Here on the web page are
examples of possibly precious things to accumulate, but they need to
be verified first:

http://chneukirchen.org/blog/archive/2013/03/10-fresh-zsh-tricks-you-may-not-know.html

Other example is how I'm now locked on _history-complete-older. It has
problems, I will identify all them, send patches to Zsh-workers, and
for Zew will provide a custom version or a configuration workaround
(or a patch using $functions like Bart described).

> I notice your default config sets a zstyle and a setopt, I think that's
> exactly the sort of silent default that made oh-my-zsh unlikeable around
> here.

I will document every setopt and zstyle, point where it's used and
why. After user reads the doc, he will not have a black box that OMZ
does where God only knows what's happening, but rather a module with
setopts that he probably would also like to set. If not, he can choose
to workaround or to not use the software. Open box. I've already
started to write a help, documentation tool:

https://github.com/psprint/zsh-editing-workbench/blob/master/zew
http://imagizer.imageshack.us/a/img903/3292/oDwtY9.gif

I gave the example of Antigen code:

local script_loc="$(ls "$location" | grep '\.plugin\.zsh$' | head -n1)

I can understand it can be hard to trust such software. Zew will be
different, written how Zsh gods from IRC and mailing lists code. One
can really trust such software and feel comfortable that he doesn't
manage the few setopts and zstyles.

Best regards,
Sebastian Gniazdowski