On Jul 9, 1:51 pm, Tony Mechelynck <antoine.mechely...@...>
wrote:

> should be 'fileencodings' with s at the end. There are two different
> options, with and without s, and they don't have the same meaning.
> Without s, it's the encoding used on disk for one file at a time. With
> s, it's the heuristics to find what to use when opening an existing file.

Sorry, mistyped it. It's 'fileencodings' certainly, and 'ucs-bom' is
the list.


> > I don't think this problem is worth of Bram's attention since it's not
> > really wide-spread and the workaround is available.
>
> How can one know how widespread it is? Sounds like the age-old "Nobody
> uses it" used without proof by developers of some applications (not by
> Bram) when speaking of a feature they want to remove because they don't
> use it themselves and they don't want to support it.

I didn't mean that. I've made such decision because I searched a lot
for similar
problem and found almost nothing except your recent answers to 'Match
a BOM'
in a file. Which deals with different issue, but it made me think
about mine.

I wanted to say, that since this issue has a solution and isn't
reported by other developers,
people know how to live with it or don't care about it. It's just
about not wasting time on low priority stuff, IMHO.
I'm just glad to understand what the problem is.

>
> OK, so IIUC the problem seems to be: When a compiler errorfile starts
> with a BOM, Vim doesn't know how to handle it. I'm not sure if there's
> an 'errorfile' setting allowing to get over it because I've never looked
> into that option myself.
>

Yeah, you've got it right. Thank you for your time, I'll settle down
on LANG=en_US which is just ok for me.
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_multibyte" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---