Multibyte input and Mac OS X

Multibyte input and Mac OS X

[Jordan Breeding]

[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]

I wrote in some time ago about multibyte input not working the way I  
would expect it to on Mac OS X.  I have a little bit of further  
information on this front.  Basically if I build from CVS with "-- 
disable-multibye" then my OS native keyboard entry method for  
multibyte input works, but the zsh binary doesn't work well with  
trying to do something like delete a character from the current  
command line, it will work but sometimes the display gets off by a  
character or two.  If I use "--enable-multibyte" then everything  
works great for editing but zsh seems to be grabbing characters at  
such a low level that my OS native keyboard entry method doesn't  
work.  Both work in modern bash (3.2) but I like zsh more than I like  
bash.

Is there a way to get just the multibyte display and editing  
(arrowing, deleting, etc.) of multibyte characters, but to bypass the  
new zsh entry method and just let me use my OS entry method?

Oh yeah, I tried what several people suggested before about zle and  
mapping keys, unfortunately the OS isn't sending the raw keys for the  
keys I am trying to send, so while that would be less than ideal  
anyway I have yet to get it to work.  Using the real input method for  
my keyboard layout (option-6 then e for ê) would be the best solution  
in my opinion.

Thanks,
Jordan

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2429 bytes --]

Re: Multibyte input and Mac OS X

[Peter Stephenson]

Jordan Breeding wrote:
> If I use "--enable-multibyte" then everything
> works great for editing but zsh seems to be grabbing characters at
> such a low level that my OS native keyboard entry method doesn't
> work.

Unfortunately, I don't even know what this means.  zsh simply looks at
groups of bytes to see if they form a complete multibye character or not.
I'm sure it's fixable without too much trouble by someone who knows
about the idiosyncracies of Mac OS, but I've been hoping in vain for
someone to work on that for a while now.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: Multibyte input and Mac OS X

[Bart Schaefer]

On Dec 10,  1:27am, Jordan Breeding wrote:
}
} If I use "--enable-multibyte" then everything works great for editing
} but zsh seems to be grabbing characters at such a low level that my OS
} native keyboard entry method doesn't work.

There's nothing different about the "level" at which zsh "grabs"
characters that is dependent on compiling with multibyte or not.  The
only difference is that, with --enable-multibyte, if zsh sees a
character that is the beginning of a valid multibyte sequence, it
continues reading characters until it has consumed up to the end of
the valid multibyte sequence, then treats the whole result as one
character.  With --disable-multibyte, it reads one byte at a time and
each byte is treated as one character.

As far as I can tell, this is exactly what readline-5.1 (the editing
library used by bash) does as well.  There's a non-zero probability
that Apple has modified readline to behave differently under MacOS X,
which would be an advantage that zsh does not have.

} Is there a way to get just the multibyte display and editing  
} (arrowing, deleting, etc.) of multibyte characters, but to bypass the  
} new zsh entry method and just let me use my OS entry method?

There is no new zsh entry method.  It's the same old entry method that
it always has been; all that has changed is how it handles the bytes
after they've already been entered.  So no, there isn't.

I haven't had a chance yet to check on MacOS, but the only difference 
on linux between the tty input settings for bash and zsh is that bash
turns off both input and output conversions of newline/carriage-return,
whereas zsh leaves both conversions on.

} Oh yeah, I tried what several people suggested before about zle and  
} mapping keys, unfortunately the OS isn't sending the raw keys for the  
} keys I am trying to send

I think you may have misunderstood.  I wasn't suggesting that you bind
the raw keys -- I was suggesting that you bind whatever it is that the
OS really sends.

} Using the real input method for my keyboard layout (option-6 then e
} for ê) would be the best solution in my opinion.

Try this:

Start zsh -f.
Type control-v to begin a literal input.
Type option-6.  If you see anything appear, make a note of it.
Type e.  What do you see displayed at this point?

If something was displayed when you typed option-6, then the "real input
method" sends a byte when option-6 is pressed and expects the program
underneath to know to behave the way zsh does on insert-composed-char.

If nothing was displayed until you typed "e", then whatever *was*
displayed is a clue to what you need to bind.  Try the experiment again
except run "bindkey -m" immediately after starting zsh -f, so that the
multibyte translation is disabled.  Both with and without bindkey -m,
let us know what you find.

Re: Multibyte input and Mac OS X

[Vincent Lefevre]

On 2006-12-10 01:27:21 -0600, Jordan Breeding wrote:
> I wrote in some time ago about multibyte input not working the way I  
> would expect it to on Mac OS X.  I have a little bit of further  
> information on this front.  Basically if I build from CVS with "-- 
> disable-multibye" then my OS native keyboard entry method for  
> multibyte input works, but the zsh binary doesn't work well with  
> trying to do something like delete a character from the current  
> command line, it will work but sometimes the display gets off by a  
> character or two. 

I have such problems with combining characters (I don't know if
multibyte is enabled or not), but that's not related to character
input (such combining characters came from completion).

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)