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

14876Re: Vim can't use filename having MBYTE

Expand Messages
  • Bram Moolenaar
    Aug 3, 2000
    • 0 Attachment
      Yasuhiro Matsumoto wrote:

      > Bram@... wrote:
      > > Changing the order of initializations is very dangerous. In this case the
      > > vimrc file can do just about anything with file specified in the command
      > > line, this it should be run with a valid set of arguments. But since
      > > 'isfname' can be set in the vimrc, expanding may work differently after
      > > it.
      > I hope that setting p_cc before calling "rem_backslash".
      > I do "set fileencoding=japan" in vimrc, Is it too later?

      You would set 'fileencoding' or 'charcode' (which are really the same thing)
      in your vimrc file. But in your vimrc file you may also want to check which
      arguments Vim got and they need to be expanded before sourcing the vimrc file.
      That won't work.

      A very clever solution would be not to expand wildcards in the arguments until
      they are used. Thus if you would set 'charcode' in your vimrc and then access
      an argument, the expansion would be done right there. I'm not sure if this is
      really possible though.

      > > This is a tough chicken-egg problem. I really don't know a good solution.
      > > Perhaps it would be sufficient to initialise chartab[] first, assuming that
      > > all characters above 0x80 are filename characters?
      > Japanese people use few characterset.
      > It is called "shift_jis", "euc-jp", etc.
      > Japanese MS-Windows use "shift_jis", but there is UNIX used "euc-jp".
      > They are composed with lead-byte and trail-byte.
      > If using "shift_jis", trail-byte don't have backslash.
      > But using "euc-jp", trail-byte may have backslash.
      > Thus, it is necessary for skipping trail-byte by lead-byte and way of
      > encoding. However, both have something in using non-ascii for lead-byte.

      I see the problem. It's near to impossible to guess that a backslash is
      really the second byte of a multi-byte character. Might have been a
      ISO-8859-1 character followed by a backslash.

      > So how about below solution?

      It might solve it in some cases, but not when the double-byte character that
      contains a backslash is followed by an ascii character. I don't think this is
      reliable enough.

      hundred-and-one symptoms of being an internet addict:
      78. You find yourself dialing IP numbers on the phone.

      /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
      \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
    • Show all 10 messages in this topic