Date: Sun, 17 May 2020 03:15:45 +0300 From: Yuri Pankov <ypankov@fastmail.com> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: freebsd-questions@freebsd.org Subject: Re: (character) Conversion error (in vi) ? Message-ID: <910485e6-a5bf-8da1-55bb-2bc632d657e3@fastmail.com> In-Reply-To: <ec8735ff-fcf1-7ee4-1aed-4aa9b87c655c@fastmail.com> References: <72173.1589672025@segfault.tristatelogic.com> <ec8735ff-fcf1-7ee4-1aed-4aa9b87c655c@fastmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Yuri Pankov wrote: > Ronald F. Guilmette wrote: >> In message <06696e14-e7e5-f212-4ef0-b89e7e78cde5@fastmail.com>, >> Yuri Pankov <ypankov@fastmail.com> wrote: >> >>> I'm interested in more details on this as I could be somewhat involved >>> (see PR 202290). What release did you upgrade from/to? Could you >>> provide a simple test case that shows the issue? >> >> Yuri, >> >> I've just read PR 202290 and I have added to it a one line attachment >> which is a test case that demonstrates the issue/problem I have been >> experiencing, which sounds like it is most probably the same issue >> as in PR 202290. (But I would like your opinion on that.) >> >> The test case is just a From: line from am email sent to me by a >> european correspondant of mine. (Note that I use NHM as a mail >> client, and that it in turn invokes vi to edit new outbound >> messages and replies, which is where I frequently encounter this >> issue/problem.) >> >> I'm too embarassed to tell you what versions of FreeBSD I last did >> an upgrade from. Let's just say that it was certifiably ancient. >> My last full upgrade was to 12.0-RELEASE and that date on my local >> vi is as follows: >> >> -r-xr-xr-x 6 root wheel 461872 Dec 6 2018 /usr/bin/vi >> >> I guess that I simply need to upgrade that in order to get your >> fix for this issue (?) >> >> (Yes, I tend to be altogether too lax in keeping this particular >> system upgraded.) > > No, it's not that bug after all. The issue is that (n)vi now (for quite > some time :-) defaults to UTF-8 when it can't reliably detect the file > encoding, so you'll just have to help it a bit adding the following to > ~/.nexrc: > > set fileencoding=iso8859-1 > > This way (n)vi will check if file encoding looks like UTF-8, and if not, > it will use ISO8859-1 as fallback. For the sake of correctness, re-reading the code, my reply was not entirely precise: (n)vi first checks if file is valid UTF-8, and if it isn't and fallback encoding (as shown above) is not set, uses your locale's encoding which I guess is UTF-8, hence failing.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?910485e6-a5bf-8da1-55bb-2bc632d657e3>