[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bulk] Re: Texinfo Windows patch: Non-ASCII text output
From: |
Eli Zaretskii |
Subject: |
Re: [Bulk] Re: Texinfo Windows patch: Non-ASCII text output |
Date: |
Fri, 26 Dec 2014 10:37:09 +0200 |
> Date: Fri, 26 Dec 2014 11:44:26 +1000
> From: Jason Hood <address@hidden>
> CC: address@hidden
>
> On 26/12/2014 2:00, Eli Zaretskii wrote:
> > [...] when the output encoding,
> > as determined by the current console codepage, is UTF-8 or UTF-7. For
> > these 2 encodings, the _only_ way of delivering text to the Windows
> > console is by using the "wide" APIs, which accept UTF-16 encoded text.
>
> Actually, the problem here is that cputs/cprintf output one character at
> a time, not only making them really slow, but breaking UTF.
The speed is fine on my machines, and cputs does NOT write one
character at a time, it uses WriteConsole. Only cprintf writes one
character at a time.
And since these functions are no longer used in the UTF case, only the
speed issue remains.
> I would suggest dropping those functions in Windows, using
> WriteConsoleA instead.
OK, will do as a folloow-up. Thanks.
> > The patch also handles the calls to terminal_write_chars,
> > which Jason's patch left out.
>
> It wasn't used, so I didn't bother.
At least now it is used when displaying a line with a search match.
> I'm guessing it's still not used, otherwise you'd be dropping the
> last character (you should only do wlen - 1 when nbytes == -1).
Thanks, I will fix that blunder before committing.