Consecutive delete-words do not get yanked consecutively

[eras]

Steps to reproduce:

1. enter "hello hello" to prompt
2. press ^W ^W, both hellos are removed
3. press ^Y and witness one 'hello' coming back

Expected behavior: "hello hello" would come back (works if zsh-syntax-highlighting is not enabled)

I sort of hoped #143 would have fixed this but no :).

[danielshahaf]

I'm inclined to call this a zsh bug. With zsh-5.1-1-ga9df6aa:

$ zsh -f
% bindkey -e
% f() { zle .backward-kill-word }
% zle -N backward-kill-word f
% echo foo bar<^W><^W><^Y>
% echo foo <CURSOR>

Without the f() wrapper, the last line has echo foo bar. (Thanks to @vincentbernat for pointing this out on #160.)

@eras @vincentbernat Would you mind reporting this to the zsh project?

[danielshahaf]

This seems to be caused by the ZLE_KILL flag, which is tested in the cuttext() C function in ZLE: backward-kill-word (used in emacs mode) has that flag, but the wrapper function f doesn't, nor does the vi mode equivalent vi-backward-kill-word. The lack of that flag causes $CUTBUFFER (cutbuf in C) to be emptied before inserting the second-deleted word to it.

So one way to solve the problem would be to use @Mikachu's zle -P / zle -f patches (reposted) to set the ZLE_KILL flag on the wrapper widgets which zsh-syntax-highlighting creates.

[danielshahaf]

Confirmed: Mikael's workers/36709 plus danielshahaf@bfa71c9 fix this issue.

Once Mikael's patch is merged to zsh, we can merge that bfa71c9 here and close this issue as fixed.

[edit: these patches fix issue #183 as well)

[danielshahaf]

workers/36709 was merged in zsh-users/zsh@a855d7b. The way forward is either:

• Test danielshahaf@bfa71c9 with older zsh versions, and merge it; or
• Wait for the redrawhook patch to be merged to zsh, and then teach zsh-syntax-highlighting to use it (as detailed in breaks tab expansion of xsel -o -b #154 (comment))

[ionsquare]

Any update on this? I tried adding danielshahaf/zsh-syntax-highlighting@bfa71c9 but get _zsh_highlight:100: bad option: -f whenever I kill words and I don't know enough to fix it.

[danielshahaf]

tl;dr: You need to upgrade zsh to 5.2.

The log message of that commit states that it depends on a zsh commit; that zsh commit was first released in 5.2 (more precisely, in the 5.1.1-test-* prereleases that preceded it):

% git log --grep=36709 
commit a855d7bd246ef44d5393c3088aae8214d41d2b85
Author: Mikael Magnusson <mikachu@gmail.com>
Date:   Tue Sep 29 06:11:24 2015 +0200

    36709: zle -f from inside widget to set flags and make yank start/end zle params writable
% git tag --contains=a855d7bd246ef44d5393c3088aae8214d41d2b85
5.1.1-test-2
zsh-5.1.1-test-1
zsh-5.1.1-test-2
zsh-5.1.1-test-3
zsh-5.2
⋮

[psprint]

Has the issue been resolved? I've tested HEAD and it doesn't seem to.

[danielshahaf]

The issue is not fixed on current master, but is fixed on the redrawhook branch, which is scheduled to be merged at some point after 0.7.0. (IIRC, this issue was fixed on master at some point, but the fix was later reverted; this is why this issue was closed and then reopened.)

[psprint]

OK, thanks.

[danielshahaf]

When redrawhook is merged, this issue will be closed as fixed, though the fix will require zsh 5.9 (not yet released). If anyone needs a fix for older versions of zsh, look into writing a pull request around zle -f (see above).