Re: transpose-words-match (Re: New widget "transpose-segments")

[Sebastian Gniazdowski <sgniazdowski@gmail.com>]

On 12 January 2016 at 07:26, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Jan 11,  2:13pm, Sebastian Gniazdowski wrote:
> }
> } Bart there already is "copy-prev-shell-word". It's good to not be
> } bound to global select-word-style setting.
>
> Just for the record, although there is a global select-word-style
> setting for convenience, you can also select different word styles
> for different contexts.  There are a few examples in the manual.
>
> The word styles can also handle things like swapping CapsLikeThis
> to CapsThisLike where the only "word break" is a case difference.

Tried googling but no success. Could you give name of the man page
and what to look for?

> Further, copy-prev-shell-word is a built-in widget; and it appears to
> have a bug when the previous shell word is a single character with no
> whitespace between it and the cursor.  (The transpose-words builtin
> has a similar difficulty with one-character words, I think.)

Really a bug, it reproduces here. Yesterday I switched to
copy-earlier-word (still bind copy-prev-shell-word to ^[M). It
integrates with insert-last-word and allows to copy arbitrary word
from arbitrary previous history event. For the record:

bindkey "^[." insert-last-word
autoload -Uz copy-earlier-word
zle -N copy-earlier-word
bindkey "^[m" copy-earlier-word

It's interesting that insert-last-word operates on shell words
although this is not stated in manual.

> } That said I tested your bksw and it doesn't fully work for following
> [...]
> } There is a space after "". When cursor is positioned after this space,
> } invoking bksw joins lines "" and a\ b instead of deleting "".
>
> select-in-shell-word is intended to emulate some vim functionality that
> excludes quotes (only selects what's inside them) so empty quotes might
> be expected to confuse it.

Other lines, when ended with space, will also cause the unexpected
behavior. I should have stated this that it's about space at the end.

> I have to thank you for this example, because it allowed me to realize
> why newlines confuse match-words-by-style.  It needs to be using the
> (Z:n:) flag rather than the (z) flag; the latter converts newlines into
> semicolons, but this wants newlines as whitespace.

Cool. I tested transpose-words with shell word style and now it works
on the multi line command I gave, e.g. I can transpose 'a\ b' with
'""' when I position cursor at 'a'.

I've missed the (Z) flag, wrote much code in transpose-shell-words to
track which arguments correspond to which spaces to be able to glue
the command back, and had to handle the "\n" -> ";" semicolons which
complicated things. Seems that (Z:n:) would discard the new lines like
any other white spaces and the code would be simpler. And this works
even in zsh 4.3.17.

BTW. I discovered that following multi line command can make various
versions of zsh hang on it:

a=${(j:,:)a}
a="${(r:100000:: _:)a}"
試句相當長
""
a\ b
c\ b

Does it reproduce to you? It was fully reproducible on my setup
however first it started to work for a second - and I thought that
it's connected to $SHLVL>1, then it worked again, and then pasting
broke up in my terminal, and I thought it might be connected to zle -N
self-insert url-quote-magic. Now pasting works and again it hangs
zsh-5.2-dev-0 and 5.0.8, even when I provide it with history
operations (cursor up). However, $SHLVL has to be 2 or more.

Best regards,
Sebastian Gniazdowski