Hi Bram,
2016/8/22 Mon 2:29:28 UTC+9 Bram Moolenaar wrote:
> 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".
No, the conversion will not be applied to `:cbuffer` and `:cexpr`.
As I wrote in the help, it will be applied to:
`:make`, `:lmake`, `:grep`, `:lgrep`, `:grepadd`, `:lgrepadd`,
`:cfile`, `:cgetfile`, `:caddfile`, `:lfile`, `:lgetfile`, and
`:laddfile`.
(Oh, I didn't mention 'cenc' in each of them, only in `:make` and `:lmake`.)
My patch only adds the conversion to the function qf_get_next_file_line()
which is used only when reading from a file. (Note that `:make` and `:grep`
also use a file.)
Hm, is it confusing that 'cmdencoding' also applies to `:[cl].*file`?
`:cbuffer` calls qf_get_next_buf_line(), I think.
> 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.
Do you mean `:grep` and `:make` should have different encoding options?
Maybe a user can create wrapper commands which set 'cenc' before executing
`:grep` or `:make`.
Of course, it would be nice if Vim supports it natively, but I have no idea
how to implement it.
Regards,
Ken Takata
--
--
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.
