Re: problems with 4.3.4 and Tru64

[Jordan Breeding <jordan.breeding@xxxxxxx>]

On Friday, May 11, 2007, at 11:24AM, "Jordan Breeding" <jordan.breeding@xxxxxxx> wrote:
>On Friday, May 11, 2007, at 04:29AM, "Peter Stephenson" <pws@xxxxxxx> wrote:
>>Phil Pennock wrote:
>>> > > If these display fine, then multibyte is working and parts of zle are
>>> > > working; the problem will be in input processing.  If these don't
>>> > > display, then the problem's not in the input processing.
>>> > 
>>> >  Touche, that works!
>>> > 
>>> >  Now, how to fix input processing?-)
>>
>>The fact they display doesn't tell you very much.  You also need to
>>check that once you've got them on the command line they behave like a
>>single character.  The easiest way is just to move the cursor and check
>>it doesn't go to far (which it will if doesn't recognise the two bytes
>>as a single character).
>>
>>If that's really working, input processing is quite involved to check.
>>The key function for this is getrestchar() in Src/Zle/zle_main.c.  This
>>should recognise the first byte is an incomplete character and the
>>second byte completes it.  I don't think this an easy way to avoid
>>debugging the insides.
>>
>
><snipped>
>
>Hello,
>
>I have been following this thread as it interests me since I have had trouble getting multibyte to work the way I would expect on OS X.  This thread inspired me to dig a little deeper since I can always see the characters, but with multibyte on echo/printf didn't seem to like the combined characters, and with multibyte off the line editor can't keep straight that it is one character.  I will file a bug report with Apple to turn on multibyte in zsh now since in zsh 4.3.4 it seems to work fine.  The other problems I was having were caused by preexec().  I had some print() statments in precmd() and preexec().  precmd() and chpwd() seem to have no effect on whether multibyte works or not, but this preexec():
>
>preexec() {
>  print -Pn "\e]2;%n@%m %0~ (%30>...>${1}%>>%)\a"
>}
>
>causes echo/print to misbehave.
>
>My test case was to do `echo h<combined character>lp` where the combined character is either <option-u>e or <ctrl-x k>e:
>
>with the preexec enabled I get:
><combined character>h<combined character>lp
>
>as the output, without it it just echoes exactly what it should.  So I think for the most part my problems are solved now.  It would be nice to still be able to use preexec, but I assume that hopefully that bug can be fixed in the future.
>
>Jordan
>
>

Sorry to reply to myself, but I just paid a little bit more attention and I figured out something else interesting.  The extra characters that appear in the Terminal itself just before the output from echo are the multibyte characters only, which are missing from the ${1} being inserted into the Terminal title.  This part seems to be OS X (Terminal.app) specific, as if I use zsh through a remote Terminal the behaviour will differ (putty will display h<character><character>lp in the title which I am assuming are just the bytes that it is seeing).  Anyway, I will probably just not use preexec() anymore for now.  Is there are way to display multibyte characters as the base singlebyte character for the preexec string?  Or possible just replace multibyte characters with "?" or something, just so my preexec would at least partially work?

Thanks,
Jordan