Ken Takata wrote:
> > > > > I wrote a patch for the following todo item:
> > > > >
> > > > > > Win32: When running ":make" and 'encoding' differs from the system
> > > > > > locale, the
> > > > > > output should be converted. Esp. when 'encoding' is "utf-8".
> > > > > > (Yongwei Wu)
> > > > > > Should we use 'termencoding' for this?
> > > > >
> > > > > I think using 'termencoding' for this is not so good. Normally
> > > > > the encoding of a command output is the same as the encoding of
> > > > > the terminal, but not always the same. I hear that some commands
> > > > > on Windows use utf-8 instead of the current codepage. So I added
> > > > > a new option 'cmdencoding' ('cenc').
> > > > > What do you think of this?
> > > >
> > > > Seems reasonable. It's not nice that it's yet another option. But in
> > > > case you know the compiler output is in a certain encoding it's the only
> > > > way to make it work.
> > > >
> > > > Why they "char" value? It's using the system locale, wouldn't "system"
> > > > be better? Hmm, I don't see where "char" is recognized.
> > >
> > > At least, GNU libiconv supports "char".
> > >
> > > See: https://www.gnu.org/software/libiconv/
> > > | Locale dependent, in terms of `char' or `wchar_t' (with machine
> > > dependent
> > > | endianness and alignment, and with OS and locale dependent semantics)
> > > | char, wchar_t
> > > | The empty encoding name "" is equivalent to "char": it denotes the
> > > locale
> > > | dependent character encoding.
> > >
> > > I don't know about other iconv implementations.
> >
> > I found a few, but they all say that the name supported are system
> > dependent. Perhaps someone can dig deeper?
>
> I hear that the "char" encoding would be a GNU extension. So the description
> in options.txt would be:
>
> This would be mostly useful when you use MS-Windows and set 'encoding'
> to "utf-8". If GNU libiconv is available, setting 'cmdencoding' to
> "char" has the same effect as setting to the system locale encoding.
> Example: >
> :set encoding=utf-8
> :set cmdencoding=char " system locale is used
>
> On Japanese Windows, `set cenc=char` has the same effect as `set cenc=cp932`.
> (I suppose the Vim 8.0 win32 installer will contain GNU libiconv.)
Looking at this patch, I think it also applies the conversion to
":cbuffer". That should not happen. Also ":cexpr".
In general, whether the conversion is needed depends on the command
used. E.g. for :grep and :make it might be different. Not sure how to
deal with that.
--
hundred-and-one symptoms of being an internet addict:
43. You tell the kids they can't use the computer because "Daddy's got work to
do" and you don't even have a job.
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
You received this message from the "vim_dev" 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
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
