2614Re: Failed to drag&drop-open a file with wide-chars in its filename
- Jun 20, 2009On 20/06/09 19:58, björn wrote:
>Ah, I see. I entered it in Vim by copy-paste from your previous post in
> 2009/6/20 Tony Mechelynck:
>> On Jun 19, 11:22 pm, björn<bjorn.winck...@...> 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).
>> The OP's problem was about a file with 한 as (part of) the filename,
>> not as the content.
> 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'.)
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.
>Well, sorry I can't help you.
> 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 한).
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_multibyte" maillist.
For more information, visit http://www.vim.org/maillist.php
- << Previous post in topic Next post in topic >>