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

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

Expand Messages
  • björn
    Jun 20, 2009
    • 0 Attachment
      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'.)

      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

      --~--~---------~--~----~------------~-------~--~----~
      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