* backward-kill-shell-word widget @ 2016-01-01 0:37 Daniel Shahaf 2016-01-10 7:42 ` Sebastian Gniazdowski ` (4 more replies) 0 siblings, 5 replies; 25+ messages in thread From: Daniel Shahaf @ 2016-01-01 0:37 UTC (permalink / raw) To: zsh-workers [ I mentioned this to IRC some weeks ago and Valodim told me about select-word-style so I didn't post this to the list; but now, I'll post it anyway in case there's a subtle difference that I'm overlooking. Perhaps the interactive_comments test is such a difference? ] This widget is like ^W but for "shell words" rather than whitespace-separated words, so % echo foo "bar baz" <CURSOR>^W becomes % echo foo <CURSOR> If you use zsh 5.1.1 or older, comment the 'zle -f' line. (Without that line, using this widget followed by another kill followed by a yank won't include the text this widget killed in the yank.) --- backward-kill-shell-word() { local MATCH; integer MBEGIN MEND integer start end_of_word end_of_cut=$CURSOR # Walk backwards to an end-of-word [[ $LBUFFER =~ '[[:space:]]*$' ]] || : # sets $MATCH (( end_of_word = CURSOR - $#MATCH )) # Find the start of the shell word ending at $BUFFER[end_of_word] () { local l="$PREBUFFER$LBUFFER[1,end_of_word]" local -a a if [[ -o interactive_comments ]]; then a=( ${(zZ+c+)l} ) else a=( ${(z)l} ) fi (( start = end_of_word - ${#a[-1]} + 1 )) } # Standard kill-widget behaviour zle -f 'kill' if [[ $LASTWIDGET == *'kill'* ]]; then CUTBUFFER=${BUFFER[start,end_of_cut]}$CUTBUFFER else zle copy-region-as-kill -- "${BUFFER[start,end_of_cut]}" fi # Delete the last shell word from $LBUFFER LBUFFER[start,end_of_cut]="" } zle -N backward-kill-shell-word bindkey '^T' backward-kill-shell-word ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-01 0:37 backward-kill-shell-word widget Daniel Shahaf @ 2016-01-10 7:42 ` Sebastian Gniazdowski 2016-01-10 7:54 ` Sebastian Gniazdowski 2016-01-10 20:13 ` Daniel Shahaf 2016-01-10 13:37 ` Sebastian Gniazdowski ` (3 subsequent siblings) 4 siblings, 2 replies; 25+ messages in thread From: Sebastian Gniazdowski @ 2016-01-10 7:42 UTC (permalink / raw) To: Daniel Shahaf; +Cc: Zsh hackers list On 1 January 2016 at 01:37, Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > If you use zsh 5.1.1 or older, comment the 'zle -f' line. (Without that > line, using this widget followed by another kill followed by a yank > won't include the text this widget killed in the yank.) So you submit for people, not for commit? You could use is-at-least to submit for commit? Best regards, Sebastian Gniazdowski ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-10 7:42 ` Sebastian Gniazdowski @ 2016-01-10 7:54 ` Sebastian Gniazdowski 2016-01-10 20:13 ` Daniel Shahaf 1 sibling, 0 replies; 25+ messages in thread From: Sebastian Gniazdowski @ 2016-01-10 7:54 UTC (permalink / raw) To: Daniel Shahaf; +Cc: Zsh hackers list Oh wait, if you submit it now it will be included in zsh-5.2-dev-0 :))) So zle -f is where it should be I'm now configuring a setup of multiple Zle widgets that will allow to operate on $BUFFER in sophisticated manner, with use of shell word-style and (z) segments. Trying to negate ZCA's reason to exist, seeing where it will get me. A tricky situation, if one want's to have such setup in place everywhere, then main distribution isn't a best place, github might be better Best regards, Sebastian Gniazdowski ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-10 7:42 ` Sebastian Gniazdowski 2016-01-10 7:54 ` Sebastian Gniazdowski @ 2016-01-10 20:13 ` Daniel Shahaf 1 sibling, 0 replies; 25+ messages in thread From: Daniel Shahaf @ 2016-01-10 20:13 UTC (permalink / raw) To: Sebastian Gniazdowski; +Cc: Zsh hackers list Sebastian Gniazdowski wrote on Sun, Jan 10, 2016 at 08:42:23 +0100: > On 1 January 2016 at 01:37, Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > If you use zsh 5.1.1 or older, comment the 'zle -f' line. (Without that > > line, using this widget followed by another kill followed by a yank > > won't include the text this widget killed in the yank.) > > So you submit for people, not for commit? You could use is-at-least to > submit for commit? Compatibility is not the point; maintenance burden is. If the functionality my widget provides can be implemented in terms of existing widgets, then (a) perhaps my widget doesn't need to be committed at all, and (b) if it _is_ to be committed, it should be reimplemented in terms of existing widgets, if possible. Similarly, when I asked whether there is anything my widget does existing widgets don't, the point was that perhaps those widgets could be improved. For example, if my widget worked on Tuesdays and the existing widgets didn't, then teaching select-in-shell-word or "select-word-style shell" to work on Tuesdays would improve all widgets implemented in terms of those two widgets, not only b-k-s-word. Cheers, Daniel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-01 0:37 backward-kill-shell-word widget Daniel Shahaf 2016-01-10 7:42 ` Sebastian Gniazdowski @ 2016-01-10 13:37 ` Sebastian Gniazdowski 2016-01-10 19:59 ` Daniel Shahaf 2016-01-12 8:23 ` Bart Schaefer 2016-01-10 15:50 ` Sebastian Gniazdowski ` (2 subsequent siblings) 4 siblings, 2 replies; 25+ messages in thread From: Sebastian Gniazdowski @ 2016-01-10 13:37 UTC (permalink / raw) To: Daniel Shahaf; +Cc: Zsh hackers list I see that you use (z) flag :) I think this is cool. I just was about to decide to bind shell-worded transpose-words-match to Alt-r (have transpose-segment bound to Alt-t) and noticed that I rather want to keep select-word-style bash. I rather want Ctrl-W to delete normal words. So with your function one can have: - "Ctrl-W" / backward-kill-word to delete word with style of his choice - transpose-words-match to swap words with style of his choice, keeping in mind to position cursor at beginning of the words - "Alt-m" / copy-prev-shell-word to copy shell word regardless of word style - "Ctrl-T" / backward-kill-shell-word to delete shell word regardless of word style - "Alt-t" / my transpose-segment to swap shell words regardless of word style (should I rename the widget to "transpose-shell-word", looks like yes) - "Alt-/" / _history-complete-older to complete shell words regardless of word style I think this goes into a nice workbench for quick manipulation of command line, if one devotes time to establish order in that set of loosely coupled functionalities. Best regards, Sebastian Gniazdowski ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-10 13:37 ` Sebastian Gniazdowski @ 2016-01-10 19:59 ` Daniel Shahaf 2016-01-10 21:06 ` Bart Schaefer 2016-01-12 8:23 ` Bart Schaefer 1 sibling, 1 reply; 25+ messages in thread From: Daniel Shahaf @ 2016-01-10 19:59 UTC (permalink / raw) To: Sebastian Gniazdowski; +Cc: Zsh hackers list Sebastian Gniazdowski wrote on Sun, Jan 10, 2016 at 14:37:26 +0100: > I see that you use (z) flag :) I think this is cool. I just was about > to decide to bind shell-worded transpose-words-match to Alt-r (have > transpose-segment bound to Alt-t) and noticed that I rather want to > keep select-word-style bash. I rather want Ctrl-W to delete normal > words. So with your function one can have: > - "Ctrl-W" / backward-kill-word to delete word with style of his choice > - transpose-words-match to swap words with style of his choice, > keeping in mind to position cursor at beginning of the words > - "Alt-m" / copy-prev-shell-word to copy shell word regardless of word style > - "Ctrl-T" / backward-kill-shell-word to delete shell word regardless > of word style > - "Alt-t" / my transpose-segment to swap shell words regardless of > word style (should I rename the widget to "transpose-shell-word", > looks like yes) > - "Alt-/" / _history-complete-older to complete shell words regardless > of word style > > I think this goes into a nice workbench for quick manipulation of > command line, if one devotes time to establish order in that set of > loosely coupled functionalities. Don't put too much weight on my choice of <C-T> for b-k-s-word. It's not my preferred choice for b-k-s-word, it's simply the chord I always use for testing widgets. As to the general issue, I'd consider some more systematic approach. Vi has its operators; you could have something similar by having a "prefix key" that chooses the word style: e.g., <C-T><w> or <C-T><C-W> would "delete a shell word backwards", <C-Y><w> or <C-Y><C-W> would "delete a whitespace-separated word backwards", and plain <C-W> would delete a default-styled word backwards. And of course a NUMERIC could be prepended to any of those, just as with vi operators. How does emacs handle this issue? Does emacs have different chords for different kinds of "delete a word backwards"? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-10 19:59 ` Daniel Shahaf @ 2016-01-10 21:06 ` Bart Schaefer 0 siblings, 0 replies; 25+ messages in thread From: Bart Schaefer @ 2016-01-10 21:06 UTC (permalink / raw) To: Zsh hackers list On Jan 10, 7:59pm, Daniel Shahaf wrote: } } How does emacs handle this issue? Does emacs have different chords for } different kinds of "delete a word backwards"? I've never seen "chords" used that way before. Anyway, yes. Where possible to distinguish backspace from ctl-h (in which case ctl-h is a prefix character invoking help), shift makes no difference backspace is delete backward character ctl-backspace is kill backward word alt-backspace is kill backward word alt-ctl-backspace is kill line This of course may vary by emacs version/variant. Exactly what happens when ctl-h and backspace are the same, also varies. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-10 13:37 ` Sebastian Gniazdowski 2016-01-10 19:59 ` Daniel Shahaf @ 2016-01-12 8:23 ` Bart Schaefer 1 sibling, 0 replies; 25+ messages in thread From: Bart Schaefer @ 2016-01-12 8:23 UTC (permalink / raw) To: Zsh hackers list On Jan 10, 2:37pm, Sebastian Gniazdowski wrote: } Subject: Re: backward-kill-shell-word widget } } [...] I just was about } to decide to bind shell-worded transpose-words-match to Alt-r (have } transpose-segment bound to Alt-t) and noticed that I rather want to } keep select-word-style bash. I rather want Ctrl-W to delete normal } words. Just to finish a thought started elsewhere: zstyle ':zle:(backward|)kill-word' word-style bash zstyle ':zle:(backward|)kill-word-match' word-style shell zstyle ':zle:transpose-words' word-style normal zstyle ':zle:transpose-words-match' word-style shell There isn't a copy-prev-word-match yet, but there easily could be. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-01 0:37 backward-kill-shell-word widget Daniel Shahaf 2016-01-10 7:42 ` Sebastian Gniazdowski 2016-01-10 13:37 ` Sebastian Gniazdowski @ 2016-01-10 15:50 ` Sebastian Gniazdowski 2016-01-10 20:19 ` Daniel Shahaf 2016-01-10 17:17 ` Bart Schaefer 2016-01-11 11:53 ` Sebastian Gniazdowski 4 siblings, 1 reply; 25+ messages in thread From: Sebastian Gniazdowski @ 2016-01-10 15:50 UTC (permalink / raw) To: Daniel Shahaf; +Cc: Zsh hackers list Hello How about such project? https://github.com/psprint/zsh-editing-workbench Pros: - if transpose-shell-words and/or your backward-kill-shell-word will be commited, then somewhere near zsh-6.2 an user will be allowed to expect "it works everywhere, I can always copy my .zshrc and use the widgets" - by creating the project the functionality will be provided to all zsh versions, even zsh 4.x - all editing functionalities grasped by a group of people, configured, provided – sum of parts is more than set of parts, we will be able to obtain cool things and provide them in sane manner, with sane shortcuts etc. If I'm to work alone on the project, I need at least your permission to use backward-kill-shell-word under GPLv3 and MIT. Can I please? I used the github originated plugin architecture. I'm not into this very much, the code is often naive, for example this is how Antigen looks for files to source: local script_loc="$(ls "$location" | grep '\.plugin\.zsh$' | head -n1)" The plugin architecture is: add plugin to $fpath, source ".plugin.zsh". Maybe there is a flaw in this and it can be done better, not sure. Best regards, Sebastian Gniazdowski ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-10 15:50 ` Sebastian Gniazdowski @ 2016-01-10 20:19 ` Daniel Shahaf 2016-01-11 8:05 ` Sebastian Gniazdowski 0 siblings, 1 reply; 25+ messages in thread From: Daniel Shahaf @ 2016-01-10 20:19 UTC (permalink / raw) To: Sebastian Gniazdowski; +Cc: Zsh hackers list Sebastian Gniazdowski wrote on Sun, Jan 10, 2016 at 16:50:50 +0100: > Hello > How about such project? > > https://github.com/psprint/zsh-editing-workbench > Thank you for fixing the copyright header on zew-backward-kill-shell-word to reflect that not all code in that file had been authored by me. 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? Regarding your change to use is-at-least: first, you should pass '-Uz' to 'autoload'. Second, I would use «case "$(zle -f 2>/dev/null)" in» instead of is-at-least (functionality testing is better than version-number testing). I tested this method outside of widgets, not inside widgets, but I expect it would work inside widgets as well. You could do that test just once by defining the function as: . % cat b-k-s-word case "$(zle -f 2>/dev/null)" in (*bad option*) _bksw_maybe_zle_dash_f() {};; (*not enough arguments for -f*) _bksw_maybe_zle_dash_f() { zle -f "$@" };; (*) abort;; esac b-k-s-word() {...} b-k-s-word . and then in b-k-s-word call _bksw_maybe_zle_dash_f instead of 'zle -f'. > - all editing functionalities grasped by a group of people, > configured, provided – sum of parts is more than set of parts, we will > be able to obtain cool things and provide them in sane manner, with > sane shortcuts etc. > > If I'm to work alone on the project, I need at least your permission > to use backward-kill-shell-word under GPLv3 and MIT. Can I please? See above, I think my licensing it to you under MIT gives you what you want. 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 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. Cheers, Daniel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-10 20:19 ` Daniel Shahaf @ 2016-01-11 8:05 ` Sebastian Gniazdowski 2016-01-12 10:36 ` Sebastian Gniazdowski 2016-01-13 1:18 ` Daniel Shahaf 0 siblings, 2 replies; 25+ messages in thread From: Sebastian Gniazdowski @ 2016-01-11 8:05 UTC (permalink / raw) To: Daniel Shahaf; +Cc: Zsh hackers list On 10 January 2016 at 21:19, Daniel Shahaf <d.s@daniel.shahaf.name> 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-11 8:05 ` Sebastian Gniazdowski @ 2016-01-12 10:36 ` Sebastian Gniazdowski 2016-01-13 1:18 ` Daniel Shahaf 1 sibling, 0 replies; 25+ messages in thread From: Sebastian Gniazdowski @ 2016-01-12 10:36 UTC (permalink / raw) To: Daniel Shahaf; +Cc: Zsh hackers list On 11 January 2016 at 09:05, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote: > I gave the example of Antigen code: > > local script_loc="$(ls "$location" | grep '\.plugin\.zsh$' | head -n1) Example code for zgen would be: for script (${location}/*\.plugin\.zsh(N)) -zgen-source "${script}" Noshortloops breaks zgen, and short loops are AFAIK harmful as they limit Zsh's detection of syntax errors. However I currently use zgen and also tried antigen and OMZ to be in touch with the macrocosm of Zsh users that has developed around Github. I'm aware they do not code as Zsh Gods from IRC and mailing lists (not that I code in this way either, it always amazes me how things in share/$ZSH_VERSION/functions are constructed), however choose to test on myself what they developed, to stay in touch with the number of users and trends they establish. E.g., they developed a "plugin system" that adds plugin's directory to $fpath. The effect on my system: % echo $fpath /Users/sgniazdowski/github/zgen /Users/sgniazdowski/.zgen/psprint/zsh-navigation-tools-master /Users/sgniazdowski/.zgen/psprint/zsh-cmd-architect-master /Users/sgniazdowski/.zgen/psprint/zsh-editing-workbench-master /usr/local/share/zsh/site-functions /usr/share/zsh/site-functions /usr/share/zsh/5.0.8/functions So it's quite flooded (also note that they're prepending). In effect of the testing, I wonder if one could develop a plugin system without flooding $fpath? PS. At least the author didn't use grep. Maybe the code isn't that bad, haven't looked at it, currently test the things as black boxes. Best regards, Sebastian Gniazdowski ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-11 8:05 ` Sebastian Gniazdowski 2016-01-12 10:36 ` Sebastian Gniazdowski @ 2016-01-13 1:18 ` Daniel Shahaf 2016-01-13 8:38 ` Sebastian Gniazdowski 1 sibling, 1 reply; 25+ messages in thread From: Daniel Shahaf @ 2016-01-13 1:18 UTC (permalink / raw) To: Sebastian Gniazdowski; +Cc: Zsh hackers list Sebastian Gniazdowski wrote on Mon, Jan 11, 2016 at 09:05:55 +0100: > On 10 January 2016 at 21:19, Daniel Shahaf <d.s@daniel.shahaf.name> 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! Sebastian Gniazdowski wrote on Tue, Jan 12, 2016 at 11:36:58 +0100: > On 11 January 2016 at 09:05, Sebastian Gniazdowski > <sgniazdowski@gmail.com> wrote: > > I gave the example of Antigen code: > > > > local script_loc="$(ls "$location" | grep '\.plugin\.zsh$' | head -n1) > > Example code for zgen would be: > > for script (${location}/*\.plugin\.zsh(N)) -zgen-source "${script}" > > Noshortloops breaks zgen, and short loops are AFAIK harmful as they > limit Zsh's detection of syntax errors. I don't think this line of conversation is constructive. If you are aware of bugs in zgen or antigen, report those bugs to the respective projects. But please don't spam -workers@ with mails that have no content other than enumeration of flaws in existing projects. Just focus on improving your project. Daniel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-13 1:18 ` Daniel Shahaf @ 2016-01-13 8:38 ` Sebastian Gniazdowski 2016-01-14 0:13 ` Daniel Shahaf 0 siblings, 1 reply; 25+ messages in thread From: Sebastian Gniazdowski @ 2016-01-13 8:38 UTC (permalink / raw) To: Zsh hackers list On 13 January 2016 at 02:18, Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > Sebastian Gniazdowski wrote on Mon, Jan 11, 2016 at 09:05:55 +0100: >> for script (${location}/*\.plugin\.zsh(N)) -zgen-source "${script}" >> >> Noshortloops breaks zgen, and short loops are AFAIK harmful as they >> limit Zsh's detection of syntax errors. > > I don't think this line of conversation is constructive. > > If you are aware of bugs in zgen or antigen, report those bugs to the > respective projects. But please don't spam -workers@ with mails that > have no content other than enumeration of flaws in existing projects. I saw this different, as an occasion to somewhat introduce Github community to original Zsh mainstream. I think there's a crack between that mainstream and the community, e.g. OMZ. Maybe I'm wrong as zsh-syntax-highlighting was successfully introduced to Zsh-users on Github. All Github flavors of Zsh share one thing: fpath prepending "plugin architecture". 115 plugins gathered on "awesome-zsh-plugins" Github page. Guessing that almost all in spirit of colorful prompts, completions, grepping, sedding. Not in spirit of patterns, zsh-lovers or the book. That's a crack I think. I thought that I introduce how the vital Github macrocosm operates (the "plugin architecture") so that maybe there would arise a resolution to this. If Zsh mainstream would design well thought through plugin architecture, then it would be like this: rock solid architecture + any level of naivety (or innocence:) of contributions (plugins). What should that rs-architecture do? I leave this intentionally unsettled yet and choose to occasionally test zgen, antigen or OMZ on myself, waiting for ideas. But one thing that came up to me are reports from plugin operation. If one could easily see a generated text document that would enumerate which options, zstyles, aliases, etc. a plugin sets or creates, then it would be possible to still own the system despite dropping naive (or innocent:) plugins into it. That said I accept OMZ, zgen, antigen despite they can be users stuck in 'Zsh is about dropping parenthesis in variable assignment and about [[ instead of [', mostly because their code just works (if noshortloops isn't set ;), and users can just use the software (also, fpath-based plugins are currently innovative). That's why I submitted ZNT to OMZ and now await for merge of ZCA. I wonder if my email would offend Robby Russell. I really shown acceptance by submitting my projects to OMZ. But this doesn't change that we should care about breaking out of the stuck to seeing that Zsh is about e.g. patterns, not lack of parenthesis in assignment. Best regards, Sebastian Gniazdowski ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-13 8:38 ` Sebastian Gniazdowski @ 2016-01-14 0:13 ` Daniel Shahaf 2016-01-14 6:54 ` Bart Schaefer 0 siblings, 1 reply; 25+ messages in thread From: Daniel Shahaf @ 2016-01-14 0:13 UTC (permalink / raw) To: Sebastian Gniazdowski; +Cc: Zsh hackers list Sebastian Gniazdowski wrote on Wed, Jan 13, 2016 at 09:38:54 +0100: > I saw this different, as an occasion to somewhat introduce Github > community to original Zsh mainstream. I think the opposite is true too: I think some users don't appreciate that "zsh" and "oh-my-zsh" are not the same thing. (I.e., think the choice is between bash and oh-my-zsh.) Perhaps that has something to do with the fact that the zsh default setup is rather minimal: no cwd in PS1, no history tracking, etc.. (Actually, with StartupFiles/zshrc, I can't get even «rsync --<TAB>» to work, even though it calls compinit.) And features like the _match completer aren't easily discoverable... even if $framework sets them, that wouldn't have the user know he can «rsync --*links<TAB>». > I think there's a crack between > that mainstream and the community, e.g. OMZ. Maybe I'm wrong as > zsh-syntax-highlighting was successfully introduced to Zsh-users on > Github. > > If one could easily see a generated text document that > would enumerate which options, zstyles, aliases, etc. a plugin sets or > creates, then it would be possible to still own the system despite > dropping naive (or innocent:) plugins into it. So one of the things a "plugin infrastructure" could do is standardise a documentation format, so if you had N plugins installed, each plugin could register the styles and parameters it cares about, and then you could look them up, or enumerate them, in a unified way. Vim has something similar: the ':help' command indexes the core's documentation, all plugins' documentations, and a list of locally-installed plugins (:h local-additions). > That said I accept OMZ, zgen, antigen Another one is prezto. Cheers, Daniel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-14 0:13 ` Daniel Shahaf @ 2016-01-14 6:54 ` Bart Schaefer 2016-01-15 6:26 ` Daniel Shahaf 0 siblings, 1 reply; 25+ messages in thread From: Bart Schaefer @ 2016-01-14 6:54 UTC (permalink / raw) To: Zsh hackers list On Jan 14, 12:13am, Daniel Shahaf wrote: } } Perhaps that has something to do with the fact that the zsh default } setup is rather minimal: no cwd in PS1, no history tracking, etc.. I've been noodling about with a set of default styles to set for compsys, not (obviously) to be incorporated into the C code but to be distributed as a source-able (or potentially autoloadable) file. It would replace the zstyle stuff at the end of StartupFiles/zshrc. } (Actually, with StartupFiles/zshrc, I can't get even "rsync --<TAB>" to } work, even though it calls compinit.) That's interesting. It works for me. Had you noticed that there is a "return 0" at the very top of StartupFiles/zshrc that you must edit out? } So one of the things a "plugin infrastructure" could do is standardise } a documentation format, so if you had N plugins installed, each plugin } could register the styles and parameters it cares about, and then you } could look them up, or enumerate them, in a unified way. Of course the original example for this is the prompt themes system, where each file name follows a pattern and each file defines functions that also are conventionally named, which includes a "help" function. This could probably be improved upon. As for Sebastian's grumble about "flooding $fpath" ... there's really no [default] way to avoid using fpath entries without populating the shell process memory with a full function definition. As is often the case, the problem is bootstrapping -- first a hook to the plugin has to be found in some standard place, and then that hook informs how the rest of the plugin is found. $fpath is the well-known way to identify all of those places. There is a sort of workaround; instead of fpath=(/path/to/the/plugin $fpath) autoload some_function_from_plugin the plugin initializer might instead do function some_function_from_plugin { local FPATH=/path/to/the/plugin autoload -X } This wastes some space in the function definition (a value for FPATH is stored in every "not yet defined" function), but it avoids putting anything in the global $fpath and it guarantees the function is loaded from the same place regardless of $fpath order (one of Ray's bugaboos from last summer). However, you still have to bootstrap before these functions can exist; so there at least has to be a single fpath entry where all the plugins agree to deposit their equivalent of "promptinit" (or where the user of the plugin is instructed to put a link to that, or whatever). ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-14 6:54 ` Bart Schaefer @ 2016-01-15 6:26 ` Daniel Shahaf 0 siblings, 0 replies; 25+ messages in thread From: Daniel Shahaf @ 2016-01-15 6:26 UTC (permalink / raw) To: Bart Schaefer; +Cc: Zsh hackers list Bart Schaefer wrote on Wed, Jan 13, 2016 at 22:54:02 -0800: > On Jan 14, 12:13am, Daniel Shahaf wrote: > } > } Perhaps that has something to do with the fact that the zsh default > } setup is rather minimal: no cwd in PS1, no history tracking, etc.. > > I've been noodling about with a set of default styles to set for > compsys, not (obviously) to be incorporated into the C code but to > be distributed as a source-able (or potentially autoloadable) file. > It would replace the zstyle stuff at the end of StartupFiles/zshrc. > Nice. Having that would let people opt-in to a more useful default. (Vim does something similar: it a conservative default and an opt-in to a less conservative default.) Somewhat related: From time to time I run into snippets that I would consider including in some collection of "useful styles", but I don't know of a good place to add those snippets to. I'm not sure StartupFiles/zshrc is that place (do users ever see it?). Where, then? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-01 0:37 backward-kill-shell-word widget Daniel Shahaf ` (2 preceding siblings ...) 2016-01-10 15:50 ` Sebastian Gniazdowski @ 2016-01-10 17:17 ` Bart Schaefer 2016-01-10 19:53 ` Daniel Shahaf ` (2 more replies) 2016-01-11 11:53 ` Sebastian Gniazdowski 4 siblings, 3 replies; 25+ messages in thread From: Bart Schaefer @ 2016-01-10 17:17 UTC (permalink / raw) To: zsh-workers On Jan 1, 12:37am, Daniel Shahaf wrote: } } This widget is like ^W but for "shell words" rather than } whitespace-separated words, so } } % echo foo "bar baz" <CURSOR>^W } becomes } % echo foo <CURSOR> As of 5.0.8 you can do this with: backward-kill-shell-word() { zle select-in-shell-word ((++CURSOR)) # adjust for vi vs. emacs region zle kill-region } I'm not sure if that CURSOR adjustment is a a bug or just a necessary evil because of using vi binding in the emacs keymap. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-10 17:17 ` Bart Schaefer @ 2016-01-10 19:53 ` Daniel Shahaf 2016-01-12 7:54 ` Bart Schaefer 2016-04-14 16:21 ` Bart Schaefer 2016-07-08 14:19 ` Oliver Kiddle 2 siblings, 1 reply; 25+ messages in thread From: Daniel Shahaf @ 2016-01-10 19:53 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers Bart Schaefer wrote on Sun, Jan 10, 2016 at 09:17:44 -0800: > On Jan 1, 12:37am, Daniel Shahaf wrote: > } > } This widget is like ^W but for "shell words" rather than > } whitespace-separated words, so > } > } % echo foo "bar baz" <CURSOR>^W > } becomes > } % echo foo <CURSOR> > > As of 5.0.8 you can do this with: > > backward-kill-shell-word() { > zle select-in-shell-word > ((++CURSOR)) # adjust for vi vs. emacs region > zle kill-region I'd add: LBUFFER+=" " Without that, LBUFFER[-1] after the widget is the last character of the preceding word. > } > > I'm not sure if that CURSOR adjustment is a a bug or just a necessary > evil because of using vi binding in the emacs keymap. Thanks for the additional solution! ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-10 19:53 ` Daniel Shahaf @ 2016-01-12 7:54 ` Bart Schaefer 0 siblings, 0 replies; 25+ messages in thread From: Bart Schaefer @ 2016-01-12 7:54 UTC (permalink / raw) To: zsh-workers On Jan 10, 7:53pm, Daniel Shahaf wrote: } } Bart Schaefer wrote on Sun, Jan 10, 2016 at 09:17:44 -0800: } > } > backward-kill-shell-word() { } > zle select-in-shell-word } > ((++CURSOR)) # adjust for vi vs. emacs region } > zle kill-region } } I'd add: } LBUFFER+=" " } } Without that, LBUFFER[-1] after the widget is the last character of the } preceding word. If you don't kill the space, select-in-shell-word won't identify the correct word on a repeated call. Other problems I've noted with this approach are that multiple calls add to the kill ring but do not append to CUTBUFFER, and that this kills the whole word under the cursor not just the part to the left. So it needs some work. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-10 17:17 ` Bart Schaefer 2016-01-10 19:53 ` Daniel Shahaf @ 2016-04-14 16:21 ` Bart Schaefer 2016-07-08 14:19 ` Oliver Kiddle 2 siblings, 0 replies; 25+ messages in thread From: Bart Schaefer @ 2016-04-14 16:21 UTC (permalink / raw) To: Zsh hackers list On Sun, Jan 10, 2016 at 9:17 AM, Bart Schaefer <schaefer@brasslantern.com> wrote: > > As of 5.0.8 you can do this with: > > backward-kill-shell-word() { > zle select-in-shell-word > ((++CURSOR)) # adjust for vi vs. emacs region > zle kill-region > } > > I'm not sure if that CURSOR adjustment is a a bug or just a necessary > evil because of using vi binding in the emacs keymap. Following up to this because select-in-shell-word has just been fixed to make the increment of CURSOR unnecessary, so as of 5.3 that line should be dropped from the above example function. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-10 17:17 ` Bart Schaefer 2016-01-10 19:53 ` Daniel Shahaf 2016-04-14 16:21 ` Bart Schaefer @ 2016-07-08 14:19 ` Oliver Kiddle 2 siblings, 0 replies; 25+ messages in thread From: Oliver Kiddle @ 2016-07-08 14:19 UTC (permalink / raw) To: zsh-workers On 10 Jan, Bart wrote: > As of 5.0.8 you can do this with: > > backward-kill-shell-word() { > zle select-in-shell-word > ((++CURSOR)) # adjust for vi vs. emacs region > zle kill-region > } > > I'm not sure if that CURSOR adjustment is a a bug or just a necessary > evil because of using vi binding in the emacs keymap. It ought to have adjusted the cursor internally for emacs mode. It's hard to say exactly how the widget should behave from insert mode exactly but this patch also fixes select-in/a-word to select further words when invoked repeatedly from emacs mode. Note that select-in-shell-word can't unfortunately do that even from vi mode. I've also tried to consider weird combinations of virangeflag, invicmdmode() and region_active but may have missed one. Note that select-in-shell-word will select forwards in some circumstances which might be unexpected for a backward-kill- widget. Sorry for taking so long to reply to this. Oliver diff --git a/Src/Zle/textobjects.c b/Src/Zle/textobjects.c index 9b3277a..3db0781 100644 --- a/Src/Zle/textobjects.c +++ b/Src/Zle/textobjects.c @@ -1,5 +1,5 @@ /* - * textobjects.c - ZLE module implementing Vim style text objects + * textobjects.c - ZLE widgets implementing Vim style text objects * * This file is part of zsh, the Z shell. * @@ -54,11 +54,7 @@ selectword(UNUSED(char **args)) int sclass = viclass(zleline[zlecs]); int doblanks = all && sclass; - if (!invicmdmode()) { - region_active = 1; - mark = zlecs; - } - if (!region_active || zlecs == mark) { + if (!region_active || zlecs == mark || mark == -1) { /* search back to first character of same class as the start position * also stop at the beginning of the line */ mark = zlecs; @@ -207,8 +203,12 @@ selectword(UNUSED(char **args)) /* Adjustment: vi operators don't include the cursor position, in insert * or emacs mode the region also doesn't but for vi visual mode it is * included. */ - if (zlecs && zlecs > mark && !virangeflag) - DECCS(); + if (!virangeflag) { + if (!invicmdmode()) + region_active = 1; + else if (zlecs && zlecs > mark) + DECCS(); + } return 0; } @@ -315,7 +315,7 @@ selectargument(UNUSED(char **args)) } /* Adjustment: vi operators don't include the cursor position */ - if (!virangeflag) + if (!virangeflag && invicmdmode()) DECCS(); return 0; ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-01 0:37 backward-kill-shell-word widget Daniel Shahaf ` (3 preceding siblings ...) 2016-01-10 17:17 ` Bart Schaefer @ 2016-01-11 11:53 ` Sebastian Gniazdowski 2016-01-12 6:59 ` Bart Schaefer 4 siblings, 1 reply; 25+ messages in thread From: Sebastian Gniazdowski @ 2016-01-11 11:53 UTC (permalink / raw) To: Daniel Shahaf; +Cc: Zsh hackers list On 1 January 2016 at 01:37, Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > If you use zsh 5.1.1 or older, comment the 'zle -f' line. (Without that To support various zsh versions/file names, the line could '"$ZSH_NAME" -f'? Best regards, Sebastian Gniazdowski ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-11 11:53 ` Sebastian Gniazdowski @ 2016-01-12 6:59 ` Bart Schaefer 2016-01-12 7:49 ` Sebastian Gniazdowski 0 siblings, 1 reply; 25+ messages in thread From: Bart Schaefer @ 2016-01-12 6:59 UTC (permalink / raw) To: Zsh hackers list On Jan 11, 12:53pm, Sebastian Gniazdowski wrote: } Subject: Re: backward-kill-shell-word widget } } On 1 January 2016 at 01:37, Daniel Shahaf <d.s@daniel.shahaf.name> wrote: } > If you use zsh 5.1.1 or older, comment the 'zle -f' line. (Without that } } To support various zsh versions/file names, the line could '"$ZSH_NAME" -f'? This is referring to "zle" not "zsh". So, no. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: backward-kill-shell-word widget 2016-01-12 6:59 ` Bart Schaefer @ 2016-01-12 7:49 ` Sebastian Gniazdowski 0 siblings, 0 replies; 25+ messages in thread From: Sebastian Gniazdowski @ 2016-01-12 7:49 UTC (permalink / raw) To: Zsh hackers list On 12 January 2016 at 07:59, Bart Schaefer <schaefer@brasslantern.com> wrote: > This is referring to "zle" not "zsh". So, no. Ah right, sorry. The recently popular on this mailing list "zsh -f" made me see what wasn't there Best regards, Sebastian Gniazdowski ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2016-07-08 14:24 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-01-01 0:37 backward-kill-shell-word widget Daniel Shahaf 2016-01-10 7:42 ` Sebastian Gniazdowski 2016-01-10 7:54 ` Sebastian Gniazdowski 2016-01-10 20:13 ` Daniel Shahaf 2016-01-10 13:37 ` Sebastian Gniazdowski 2016-01-10 19:59 ` Daniel Shahaf 2016-01-10 21:06 ` Bart Schaefer 2016-01-12 8:23 ` Bart Schaefer 2016-01-10 15:50 ` Sebastian Gniazdowski 2016-01-10 20:19 ` Daniel Shahaf 2016-01-11 8:05 ` Sebastian Gniazdowski 2016-01-12 10:36 ` Sebastian Gniazdowski 2016-01-13 1:18 ` Daniel Shahaf 2016-01-13 8:38 ` Sebastian Gniazdowski 2016-01-14 0:13 ` Daniel Shahaf 2016-01-14 6:54 ` Bart Schaefer 2016-01-15 6:26 ` Daniel Shahaf 2016-01-10 17:17 ` Bart Schaefer 2016-01-10 19:53 ` Daniel Shahaf 2016-01-12 7:54 ` Bart Schaefer 2016-04-14 16:21 ` Bart Schaefer 2016-07-08 14:19 ` Oliver Kiddle 2016-01-11 11:53 ` Sebastian Gniazdowski 2016-01-12 6:59 ` Bart Schaefer 2016-01-12 7:49 ` Sebastian Gniazdowski
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).