>> Vim doesn't set fileencoding when it reads stdin, but it still uses >> fileencodings >> to interpret the encoding of stdin, just like opening any other file. So if >> some >> latin1 text is valid utf8 text, Vim will interpret it as such if your >> fileencodings=utf8,latin1. Only if it is invalid as utf8 will Vim interpret >> it as >> latin1. In either case, it will be converted internally to the encoding of >> Vim's >> encoding option, as always. The odd thing is that since fileencoding isn't >> set, >> you can't tell which of the fileencodings Vim used to interpret stdin, even >> though >> it still does the detection as normal. > > If 'fileencoding' isn't set, it falls back on 'encoding'.
Yes. But this doesn't mean that was the encoding with which the input was read. I.e. you can pump latin1 or utf-8 encoded stdin into vim representing the same characters, and they will both be read correctly and converted if necessary (if enc!=utf-8 so we don't see the bug we've just discovered and mentioned in earlier posts of mine) but in both cases fenc will be unset. It will fall back to enc when the file is written, but gives no indication of how stdin was read. I think this is another bug. CCing vim_dev again. Bug: When reading stdin, fenc is not set (including when the encoding used to read stdin was different to enc). It should be set to indicate what encoding was used to interpret stdin. Cheers, Ben. P.S. Note my previous comments about non-rewindable stdin perhaps causing problems I believe to be bogus. It seems to work fine with non-rewindable stdin when enc=latin1 and it has to try multiple encodings, so the 'non-conversion even if invalid' problem should be easy enough to solve with a non-rewindable stdin, too. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
