Re: Bug: bracketed-paste-magic + ztcp causes wrong pasted contents for CJK payloads

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Oct 15,  1:54pm, Bart Schaefer wrote:
}
} On Thu, Oct 15, 2015 at 6:54 AM, Chi Hsuan Yen <yan12125@xxxxxxxxx> wrote:
} > This bug is similar to zsh-worker 36763 but different. With zsh
} > commit 827d360, I have no problems in pasting CJK payloads with an
} > empty ~/.zshrc, while problems occur with my own ~/.zshrc. It's a
} > strange bug. Please tell me if you can't reproduce it. I'll test
} > on more platforms.
} 
} I am able to reproduce this, but not reliably.

Fixing the descriptor "leak" in ztcp.c did not help with this bug, so
I tried digging around a bit further.

I first discovered that I'd mis-remembered what self-insert-unmeta is
meant for.  It's not un-metafying in the zsh sense, it's clearing the
high-order bit -- so it's the wrong thing for bracketed-paste-magic
to use when inserting characters, except maybe for ^M.

However, that led to the question of why that branch of the "case"
in bracketed-paste-magic is even being taken.  The code is:

                case $REPLY in
                    (${~bpm_active}) function () {
                        emulate -L $bpm_emulate; set -$bpm_opts
                        zle $REPLY
                    };;
                    (*) zle .self-insert-unmeta;;
                esac

(where $REPLY comes from "zle .read-command").  $REPLY is "self-insert"
and $bpm_active is "self-*" so the first branch ought to be taken, and
indeed that is what happens if ztcp has never been invoked.

However, if ztcp is run in the correct order with respect to the auto-
load of bracketed-paste-magic, the case statement goes wrong and the
(*) condition is taken instead.

This is eerily similar to a situation I mentioned some while ago in
which patterns in zstyle sometimes fail to match.  I've never been
able to consistently reproduce that one either, and it also seemed
to be dependent on the order in which some operations were done.

This has me entirely confused.  valgrind finds nothing amiss so it's
not a memory management thing.  Some sort of clash in global variable
address space?  Anybody have an idea?