From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9346 invoked by alias); 11 Jan 2016 08:06:18 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 37559 Received: (qmail 2007 invoked from network); 11 Jan 2016 08:06:17 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Ga17XgnA42bx5GV4FHl9WjuPPpyHhfQYgakYGgE9ASA=; b=RA7xkvSh5LrX9dKJLXEaFUO/x3edHnfwtyMLBo9U34sBjnGItbvuygd+eeThMlgUjj fMd/Y26uHfbOeIp3aYAg/YkwjknU3jsMUu2Vymq/Ri0U8fM/63H1QXug5PI9f2Q/zi6y SXkiSlW9bwzO+FfWeIjzsbHTjjUFPAqMgcxKa7/F++XkkAeCzDDpbOAQz/MyB6gmx1Fq DKHecZFSD7az+84K7zeZIv4wQS+QMdvpU2v8tmMvoZzd5bKKK8TS6ZwVXTudX5eCtCVf NGyFvV3RpCiRtCVgjcQ/ltXgn8wKs/7S8PWjy6LHLuMvi7bdG/PP/1pWOO18g73Re2B9 7lew== X-Received: by 10.112.134.165 with SMTP id pl5mr32932067lbb.126.1452499574690; Mon, 11 Jan 2016 00:06:14 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20160110201919.GA17401@tarsus.local2> References: <20160110003758.GA28696@tarsus.local2> <20160110201919.GA17401@tarsus.local2> From: Sebastian Gniazdowski Date: Mon, 11 Jan 2016 09:05:55 +0100 Message-ID: Subject: Re: backward-kill-shell-word widget To: Daniel Shahaf Cc: Zsh hackers list Content-Type: text/plain; charset=UTF-8 On 10 January 2016 at 21:19, Daniel Shahaf 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