On Tue, Mar 20, 2012 at 11:30 PM, wrote:
> I think There is a bug in MacVim regarding multibyte characters. It
> only happens when the Experimental Renderer is turned ON.
>
> To reproduce:
>
> 1. make a new folder "bar".
> 2. In bar, do "touch föo", where there is an umlaut over the first 'o'.
> 3. Start MacVim with mvim -u NONE -U NONE.
> 4. In MacVim, do "cd bar".
> 5. Now do ":r !ls".
> 6. Put a couple of blank lines after the result of that.
> 7. Now do :let @a=glob("*"), followed by :put a
>
> Expected behavior: There should be two instances of "föo" in the buffer.
>
> Actual behavior: Depending on what your value of 'gfn' is, you might see
> that one of the "föo" lacks an umlaut. For instance, if you use
> Consolas or Monaco, the one that was the result of "ls" (i.e., the top
> one) will lack an umlaut while the bottom one will look correct. If you
> use Courier New or Menlo, then both words have the umlaut.
>
> Actual behavior part 2: Here's where it gets weird. Navigate to each of
> the "o" that are supposed to have an umlaut (the first of each pair) and
> do "ga". Vim's feedback for the top-foo (which came from ls) is:
>
> <o> 111, Hex 6f, Octal 157 < ̈> 776, Hex 0308, Octal 1410
>
> Vim's feedback for the bottom-foo (which came from glob()) is:
>
> <ö> 246, Hex 00f6, Octal 366
This has to do with Unicode normalization [1]. The output from !ls is
not composed, whereas when you paste it in Vim it is composed. The
problem arises because you are piping characters from an external
command.
I suppose we could try to normalize all input from external commands
but the problem is that it need not be in Unicode format so this may
cause new problems and/or be slower. I'll put a note on my todo list.
Björn
[1] http://en.wikipedia.org/wiki/Unicode_equivalence#Normalization
--
You received this message from the "vim_mac" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
