Re: Multibyte input and Mac OS X

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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.