> Date: Fri, 26 Dec 2014 11:44:26 +1000 > From: Jason Hood <[email protected]> > CC: [email protected] > > 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.
