Hi Bram,
2016/8/23 Tue 20:00:50 UTC+9 Ken Takata wrote:
> 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.
I'm thinking this issue again.
Maybe we can do this by adding an parameter for encoding to qf_init() in
quickfix.c. I think we can use three options instead of 'cenc':
1. 'makeencoding', 'menc':
Option for `:make` and `:lmake`.
2. 'grepencoding', 'genc':
Option for `:grep`, `:grepadd`, `:lgrep` and `:lgrepadd`.
3. 'errfileencoding', 'eenc':
Option for `:cfile`, `:cgetfile`, `:caddfile`, `:lfile`, `:lgetfile`,
and `:laddfile`.
And I think these options should be global-local options.
What do you think?
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.
