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

Problems with national characters in the file-path

Expand Messages
  • Valery Kondakoff
    Hello, Bram! Wednesday, September 1, 2004, 1:31:48 AM, you wrote: BM The problem probably is that the console uses another encoding. Vim BM gets the file
    Message 1 of 6 , Sep 1, 2004
    • 0 Attachment
      Hello, Bram!

      Wednesday, September 1, 2004, 1:31:48 AM, you wrote:

      BM> The problem probably is that the console uses another encoding. Vim
      BM> gets the file name in that encoding, but expects it to be in UTF-8.
      BM> That won't work.

      BM> I don't see a good way for gvim to detect what encoding the arguments
      BM> are in. They might as wel be in UTF-8, when started from a UTF-8
      BM> capable shell. Not that this is very likely to happen on MS-Windows.

      BM> A solution could be (although it's not that reliable) to check the name
      BM> for invalid UTF-8 characters, and if there are any assume the file name
      BM> is in the active codepage. Main problem with this would be that the
      BM> encoding used in a console might very well differ from the active code
      BM> page (as in MS-DOS versus MS-Windows encodings).

      I think this solution is better than nothing. Maybe it is possible to
      create another one option to set the codepage encoding (say,
      'codepage')? This will allow to use a construct like this:

      if has("gui_running")
      set codepage=cp1251
      else
      set codepage=cp866
      endif



      --
      Best regards,
      Valery Kondakoff mailto:strauss@...

      PGP key: mailto:pgp-public-keys@...?subject=GET%20strauss@...
    • Antoine J. Mechelynck
      ... There are already encoding and termencoding . In console vim, I would expect encoding to be set automatically at startup to whatever the terminal
      Message 2 of 6 , Sep 1, 2004
      • 0 Attachment
        Valery Kondakoff <strauss@...> wrote:
        > Hello, Bram!
        >
        > Wednesday, September 1, 2004, 1:31:48 AM, you wrote:
        >
        > > The problem probably is that the console uses another encoding. Vim
        > > gets the file name in that encoding, but expects it to be in UTF-8.
        > > That won't work.
        >
        > > I don't see a good way for gvim to detect what encoding the
        > > arguments are in. They might as wel be in UTF-8, when started from
        > > a UTF-8 capable shell. Not that this is very likely to happen on
        > > MS-Windows.
        >
        > > A solution could be (although it's not that reliable) to check the
        > > name for invalid UTF-8 characters, and if there are any assume the
        > > file name is in the active codepage. Main problem with this would
        > > be that the encoding used in a console might very well differ from
        > > the active code page (as in MS-DOS versus MS-Windows encodings).
        >
        > I think this solution is better than nothing. Maybe it is possible to
        > create another one option to set the codepage encoding (say,
        > 'codepage')? This will allow to use a construct like this:
        >
        > if has("gui_running")
        > set codepage=cp1251
        > else
        > set codepage=cp866
        > endif

        There are already 'encoding' and 'termencoding'. In console vim, I would
        expect 'encoding' to be set automatically at startup to whatever the
        terminal screen supports; and I suspect that moving it away from there would
        be a source of unending problems. Or did I miss something?

        Regards,
        Tony.
      Your message has been successfully submitted and would be delivered to recipients shortly.