Ken Takata wrote:
> 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?
That's a lot of new options, but it's probably needed. An alternative
is to make a comma separated list, but that's hard to use by plugins.
e.g. if a plugin uses ":cfile" it probably wants to save, set and
restore an option.
I would use 'menc' encoding for all commands when 'genc' and 'eenc' are
empty. On MS-Windows you probably want to set it to the system
codepage.
--
hundred-and-one symptoms of being an internet addict:
176. You lie, even to user-friends, about how long you were online yesterday.
/// 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.
