665Re: mbyte.c patch
- Jul 17, 2002Glenn Maynard wrote:
> However, notice that one of the HanExtTextOut calls only does anything whenThis indeed looks very broken. ImeGetTempComposition() will always
> ImeGetTempComposition returns non-NULL, and that only happens when
> bInComposition is TRUE.
> 01:35am glenn@.../2 [~/vim/src] grep bInComposition *.c
> gui_w32.c:static BOOL bInComposition=FALSE;
> gui_w32.c: if (bInComposition == TRUE)
> It looks like this was broken at some point. It's apparently written to
> try to display a partially-composed Korean character with the Korean IME
> in Windows.
> I don't remember if this code predates the newer IME code; it might no
> longer be necessary, now that the IME is being set up correctly.
> (Perhaps the fact that it's not working and nobody's complained is
return NULL. It already was like this in 6.0. I didn't hear specific
complaints about this. I suppose this means we might as well remove
> > We might as well do nothing. Most Japanese users are used to seeing theOh yes, the other way around it's not so nice.
> > yen symbol in the place of a backslash anyway.
> I view Japanese text in Vim daily, and I don't like seeing a backslash
> The backslash-fix code is a trivial addition to my font-repair code, whichIt even uses floating point numbers. Let's get rid of this.
> has other uses; in particular, fixing Unicode quotes in Japanese fonts.
> So I, at least, don't mind if the current backslash fix code goes
> away, since I have a replacement for it; and the current code is
> extremely special case (system-font-size only?), to the point of not
> really being useful. (And, like you said, if it *does* kick in, some
> users probably won't want it.)
> The solution to that is to use the system's conversions instead of iconvPerhaps it goes wrong when the codepage is set wrong? This is
> for codepages. You're always using iconv if it's available (in fileio),
> and never using MultiByteToWideChar in Windows. I'd blame Unicode problems
> in Windows on that.
> The only way I can see system conversions causing problems is if round-trip
> conversion fails. I don't know of any cases of this, but if anyone does I'd
> definitely like to know.
especially for 8-bit codepages where you probably don't notice the
mistake if you do use the right font. Conversion to Unicode will reveal
> I'll work on making fileio use MBtoWC for codepage<->Unicode conversionThat is a good thing. More people will be able to use different
> when possible. Even if you leave encodings as is, this will help.
encodings "out of the box".
Engineers will go without food and hygiene for days to solve a problem.
(Other times just because they forgot.)
(Scott Adams - The Dilbert principle)
/// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
/// Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim \\\
\\\ Project leader for A-A-P -- http://www.a-a-p.org ///
\\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
- << Previous post in topic Next post in topic >>