2618Re: Failed to drag&drop-open a file with wide-chars in its filename
- Jun 23, 2009Hi Björn,
> As far as I can tell (from searching around) HFS+ always usesHFS+ uses a variant of NFD for filenames. (The HFS+ variant predates
> normalization form D (NFD) for filenames.
standardizatoin of NFD.) This requirement is enforced by the OS.
Windows uses NFC for filenames. I'm not sure if the Linux world settled on
NFC or NFK.
Amiga OS (at least the one I used) is ECMA 94 Latin 1 based (precursor to
> So as a workaround for the issue the OP had I now normalize filenamesNFC or NFKC? Those are different normalizations.
> to compatibility form C (NFKC) before passing the filename on to Vim
> and this takes care of the OP's problem.
Windows NTFS file system uses NFC. But it isn't enforced by the OS, yet.
> However, as I see it this really is a legitimate issue in Vim itselfI agree with your assessment.
> in that it does not handle NFD properly (the example above should
> always render as one glyph, not three as it does now if NFD is used).
> Either Vim should ensure that all buffers are normalized to composed
> form NFC/NFKC or it needs to be made "NFD aware".
> Does anybody on the vim_multibyte list (this mail goes to vim_mac asThe relevant Mac OS X routine APIs are:
> well) have any comments on this?
CFURLRef url =
char bufferUTF8[32768*4]; // Worst case scenario.
// As per Apple documentation, paths can be "up to 30,000 UTF-16
// encoding units long", with each component being up to 255 UTF-16
// encoding units long. Too bad there isn't an API to specify the
// exact buffer size /a priori/.
Boolean success =
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 >>