On 20/06/09 19:58, björn wrote: > > 2009/6/20 Tony Mechelynck: >> >> On Jun 19, 11:22 pm, björn<[email protected]> wrote: >> [...] >>> I'm afraid I know way too little about text rendering to fix this, so >>> until somebody else fixes it in core Vim the problem will remain. I >>> would highly suggest that you take up the rendering problem on the >>> vim_dev mailing list (just send a text file with 한 as the content and >>> ask why it renders as three glyphs). >>> >>> Sorry, >>> Björn >> >> The OP's problem was about a file with 한 as (part of) the filename, >> not as the content. > > Tony, > > I appreciate that you reply to my post, but there really is no need in > stating the painfully obvious. The problem appears when the filename > is displayed in the command line (as a result of opening the file) and > as such you run into the same problem if you have that character as > part of the contents of a file. > >> I'm on Linux, so what I see may be different from what you see on >> MacVim; but in gvim I see 한 (when in the content of a file) as one >> glyph (U+D55C, corresponding to three bytes, hex ED 95 9C). Are you >> sure you have 'encoding' correctly set? (I use utf-8). > > I tried it myself on Linux and had the same problem and realized that > the problem has to do with how you represent 한. If done as you > suggest with U+D55C it works (both Linux and MacVim), but if > represented by U+1112, U+1161, U+11AB then Vim will render it as three > glyphs but here the Cocoa text system combines these into one glyph > and that is where the problem in MacVim appears. (By the way: MacVim > defaults to use utf-8 for 'encoding'.)
Ah, I see. I entered it in Vim by copy-paste from your previous post in the vim_mac Google Group page in my browser. Vim is obviously unaware of hangul jamo decomposition / recomposition and IIUC will render each of them as one glyph. I'm not sure how to have them be treated as "one spacing + (in this case) 2 composing characters" though IIUC it would be "the right way" to do it. > > So in a way the problem is related to having 한 in a filename since Mac > OS X apparently represents it as U+1112, U+1161, U+11AB instead of as > U+D55C. Still, if one were to enter those three characters separately > in a buffer the same problem would arise. As far as I see it this > only means that the Cocoa text system is not suitable for this purpose > which only means that we will have to migrate to the ATSUI or CoreText > renderers sometime in the future. > > To conclude: it seems that this is a problem with the Cocoa text > system and not that something in Vim has to be "fixed" as I stated in > my previous post (unless Vim should do the same as Cocoa and > automatically render ᄒ,ᅡ,ᆫ as 한). > > Björn Well, sorry I can't help you. Best regards, Tony. -- Really heard in court in the U.S.A.: Q.: Doctor, before you started the autopsy, did you check the pulse? A.: No, I didn't. Q.: Did you test the blood pressure? A.: No, I didn't. Q.: Did you check the breathing? A.: No, I didn't. Q.: Then there is a possibility that you autopsied a living person? A.: No, there isn't. Q.: How can you be so sure, Doctor? A.: Because his brain was in a jar on my desk. Q.: I see. But couldn't the patient be still alive nevertheless? A.: Hm, yes, he could still be alive, practicing as a lawyer. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_mac" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
