On Wed, Feb 16, 2005 at 07:20:35PM +0100, Jirka Bohac wrote:
> Now ... are there any more suggestions for any of the patches?
For the time being I look only at the diacr for unicode part.
The fragment below looks like a strange kludge.
> - if (diacr)
> - value = handle_diacr(vc, value);
> + if (diacr) {
> + v = handle_diacr(vc, value);
> +
> + if (kbd->kbdmode == VC_UNICODE) {
> + to_utf8(vc, v & 0xFFFF);
> + return;
> + }
> +
> + /*
> + * this makes at least latin-1 compose chars work
> + * even when using unicode keymap in non-unicode mode
> + */
> + value = v & 0xFF;
> + }
>
> if (dead_key_next) {
> dead_key_next = 0;
> @@ -637,7 +652,7 @@
> {
> if (up_flag)
> return;
> - diacr = (diacr ? handle_diacr(vc, value) : value);
> + diacr = (diacr ? handle_diacr(vc, value) & 0xff : value);
I see twice "& 0xff" but why?
I think this is broken.
Maybe the above "return" is broken as well. The original code
was good, so the only change should be to transport more than 8 bits.
Andries
On Wed, Feb 16, 2005 at 10:49:58PM +0100, Andries Brouwer wrote:
> On Wed, Feb 16, 2005 at 07:20:35PM +0100, Jirka Bohac wrote:
>
> For the time being I look only at the diacr for unicode part.
> The fragment below looks like a strange kludge.
>
> > - if (diacr)
> > - value = handle_diacr(vc, value);
> > + if (diacr) {
> > + v = handle_diacr(vc, value);
> > +
> > + if (kbd->kbdmode == VC_UNICODE) {
> > + to_utf8(vc, v & 0xFFFF);
> > + return;
> > + }
> > +
> > + /*
> > + * this makes at least latin-1 compose chars work
> > + * even when using unicode keymap in non-unicode mode
> > + */
> > + value = v & 0xFF;
> > + }
> >
> > if (dead_key_next) {
> > dead_key_next = 0;
> > @@ -637,7 +652,7 @@
> > {
> > if (up_flag)
> > return;
> > - diacr = (diacr ? handle_diacr(vc, value) : value);
> > + diacr = (diacr ? handle_diacr(vc, value) & 0xff : value);
I can't see your point ... you mean there is a problem that when
kbd->kbdmode == VC_UNICODE, then control will not reach the
"if (dead_key_next)"?
I don't think this is a problem. You have type a really strange sequence
of keypresses -- sth like: <a dead key><Compose> <a letter> in Unicode
mode ... then the behaviour would slightly differ from today's one.
If you think this is worth fixing, I can do it.
> I see twice "& 0xff" but why?
Ok, it's not needed, because it would have been done automatically, as
diacr and value are both unsigned chars. But at least we can clearly see
what's happening.
> The original code was good, so the only change should be to transport
> more than 8 bits.
You only want to transport more bits when handling a dead key. If the
put_queue at the end of the function was simply replaced by to_utf8, you
would modify the behaviour of normal KT_LATIN keys with value > 127;
Somebody may be rely on the current meaning.
regards,
--
Jirka Bohac <[email protected]>
SUSE Labs, SUSE CR