Ken Takata wrote:
> 2016/9/9 Fri 0:30:00 UTC+9 Ken Takata wrote:
> > Hi,
> >
> > 2016/9/7 Wed 3:08:50 UTC+9 Bram Moolenaar wrote:
> > > 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.
> >
> > I wrote a patch to implement this. Please check the attached patch.
> > I haven't add a test for this yet. It's not so easy.
>
> I have updated the patch. Now, it includes tests.
> I think that the patch is ready to be included.
Looking at the documentation for the new options, I wonder if we really
need three options. One might argue that :grep and :make may have a
different output, but then running :make with two different compilers
(e.g., in two windows or directories) also may require a different
encoding.
And to make things more complicated, the :make command may run several
tools with more than one encoding. This would require adding the format
in 'errorformat' and 'grepformat'. That may be difficult to implement
though.
Back to the original problem: When 'encoding' in Vim differs from the
system encoding, the conversion is needed. And that is just one
encoding, thus we won't need three options. Perhaps we can just use
'makeencoding' and use it for all commands.
--
hundred-and-one symptoms of being an internet addict:
194. Your business cards contain your e-mail and home page address.
/// 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.
