Zsh Mailing List Archive
Messages sorted by:
Re: PATCH: zle input changes for Unicode
- X-seq: zsh-workers 20826
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx (Zsh hackers list)
- Subject: Re: PATCH: zle input changes for Unicode
- Date: Fri, 18 Feb 2005 16:59:46 +0000
- In-reply-to: <200502181350.j1IDobbt031241@xxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <200502181350.j1IDobbt031241@xxxxxxxxxxxxxx>
On Feb 18, 1:50pm, Peter Stephenson wrote:
} Please tell me if you think I'm doing something wrong
My only wish is that you might have tagged the repository before the
commit (e.g. "cvs tag pre-unicode-input" or some such). I'm not sure
I have an uncorrupted sandbox from which I can do so. Maybe a checkout
by date ...
} I moved the definitions from system.h to the more appropriate zle.h.
I heartily approve.
} Note also that lastchar, and its new companion lastchar_wide, are now
} set by the routines that actually read the character. This is obviously
} neater and it was hard to see from the code if there was a good reason
} why it wasn't done before, but I strongly suspect there wasn't.
The obvious question is whether there is any case where getkey() was
called but lastchar was not updated. Scanning through the patch I see
two places where that might have been true -- in deltochar() and in
getkeybuf() -- and one where it appears really to be true, that is, in
getzlequery(). But maybe the callers fix up something thereafter, I
didn't look carefully at the whole context.
} Note that I've renamed some functions with "getkey" to "getbyte" to
} reflect the function better.
I generally think this sort of thing is a good idea, if for no other
reason than that it means the compiler will point a lot of the places
that you might need to do other special handling.
Is last_widechar_valid set to 1 too soon in getrestchar()?
Sometimes you assign 1 to last_widechar_valid, and sometimes TRUE.
Nothing else jumps out at me.
Messages sorted by: