Re: Autocompletion doesn't work with kanji

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Dec 22,  1:50am, Benjamin R. Haskell wrote:
}
} > I noticed that I can rename _foo_bar to anything and the problem 
} > persists. However, removing the line with _foo_bar completely also makes 
} > the problem disappear. But removing this line would break the real grml 
} > .zshrc, so this is not a solution.
} 
} Something makes me doubt that's the essential line in the real grml
} .zshrc that's doing what you want.

I've just had a quick look at the grml zshrc, and the line in there is
_last_try="$HISTNO$BUFFER$CURSOR" (not _foo_bar).  The full context is:

        zstyle -e ':completion:*' completer '
            if [[ $_last_try != "$HISTNO$BUFFER$CURSOR" ]] ; then
                _last_try="$HISTNO$BUFFER$CURSOR"
                reply=(_complete _match _ignored _prefix _files)
            else
               ...
            fi'

Aside:  I think there's also an unrelated bug, this ...

    # allow one error for every three characters typed in approximate completer
    zstyle ':completion:*:approximate:'    max-errors 'reply=( $((($#PREFIX+$#SUFFIX)/3 )) numeric )'

... should also be using zstyle -e, otherwise the assignment to reply is
not really meaningful.

} I suspect you're somehow ending up with ISO-2022-JP encoding, where kanji 
} 'hon' and hiragana 'a' encode to the following sequences:
} 
} 0x672C  1b 24 42 4b 5c 1b 28 42  == \033$BK\033(B
} 0x3042  1b 24 42 24 22 1b 28 42  == \033$B$"\033(B
} 
} $BUFFER contains the line as edited thus far.  So, in one case, there's 
} an extra double-quote hanging about that messes things up.

No, that's not it.  Zsh will parse away the double quotes in the
string "$HISTNO$BUFFER$CURSOR" before ever expanding $BUFFER -- a
quote within the value of $BUFFER won't be treated as part of the
parse.
 
} It might be as simple as using 'setopt multibyte' somewhere.

This, however, may be true.  The doubling of the "A" may indicate that
something is not correctly counting the number of bytes in the buffer.

On the other hand, if removing the assignment fixes the problem, then
there may be memory corruption from miscounting during the assignment.

Christoph, can you try reproducing this with zsh built from the most
current sources?