Loading ...
Sorry, an error occurred while loading the content.

2614Re: Failed to drag&drop-open a file with wide-chars in its filename

Expand Messages
  • Tony Mechelynck
    Jun 20 5:14 PM
      On 20/06/09 19:58, björn wrote:
      > 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).
      >>> 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,
      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
    • Show all 12 messages in this topic