backward-kill-shell-word widget

backward-kill-shell-word widget

[Daniel Shahaf]

[ 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

Re: backward-kill-shell-word widget

[Sebastian Gniazdowski]

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

Re: backward-kill-shell-word widget

[Sebastian Gniazdowski]

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

Re: backward-kill-shell-word widget

[Daniel Shahaf]

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

Re: backward-kill-shell-word widget

[Sebastian Gniazdowski]

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

Re: backward-kill-shell-word widget

[Daniel Shahaf]

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"?

Re: backward-kill-shell-word widget

[Bart Schaefer]

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.

Re: backward-kill-shell-word widget

[Bart Schaefer]

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.

Re: backward-kill-shell-word widget

[Sebastian Gniazdowski]

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

Re: backward-kill-shell-word widget

[Daniel Shahaf]

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

Re: backward-kill-shell-word widget

[Sebastian Gniazdowski]

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

Re: backward-kill-shell-word widget

[Sebastian Gniazdowski]

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

Re: backward-kill-shell-word widget

[Daniel Shahaf]

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

Re: backward-kill-shell-word widget

[Sebastian Gniazdowski]

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

Re: backward-kill-shell-word widget

[Daniel Shahaf]

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

Re: backward-kill-shell-word widget

[Bart Schaefer]

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).

Re: backward-kill-shell-word widget

[Daniel Shahaf]

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?

Re: backward-kill-shell-word widget

[Bart Schaefer]

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.

Re: backward-kill-shell-word widget

[Daniel Shahaf]

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!

Re: backward-kill-shell-word widget

[Bart Schaefer]

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.

Re: backward-kill-shell-word widget

[Bart Schaefer]

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.

Re: backward-kill-shell-word widget

[Oliver Kiddle]

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;

Re: backward-kill-shell-word widget

[Sebastian Gniazdowski]

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

Re: backward-kill-shell-word widget

[Bart Schaefer]

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.

Re: backward-kill-shell-word widget

[Sebastian Gniazdowski]

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