[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24953: 25.1; Possible inefficiency in UTF-8
From: |
Eli Barzilay |
Subject: |
bug#24953: 25.1; Possible inefficiency in UTF-8 |
Date: |
Sun, 11 Dec 2016 05:53:33 -0500 |
On Mon, Nov 21, 2016 at 10:33 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Eli Barzilay <eli@barzilay.org>
>> Date: Mon, 21 Nov 2016 16:38:07 -0500
>> Cc: 24953@debbugs.gnu.org
>>
>> In the latter case, my shell has an explicit LANG setting and the
>> result is that Emacs opens that file fine, but in the first case,
>> when Emacs is started directly by windows, there is no LANG, and the
>> utf-8 file is not treated as such (looks like it opens it in
>> latin-1). I verified this with "emacs -Q" too.
>
> Emacs sets LANG internally, by using a suitable Windows API, when it
> runs on Windows (unless LANG is set in the shell), so the fact that
> LANG is not set is not a problem in itself.
>
> What you describe is expected with the default Windows settings: a
> file that is in no particular mode which requires UTF-8 will not be
> automatically decoded as UTF-8, without some customizations. You
> could also put file-local variables into the file.
I still didn't get to try and see if I can get the git problem, but the
problem seems to be moot for me: I use *both* Linux and Windows, a lot.
I synchronize files between the two, and I work with Linux mounts on
Windows. In short, I have a ton of files that are UTF-8, so it makes
sense to have it be my default on Windows too. In the around-month-or-
so which I used without it, I ran into several cases where the default
character encoding was broken, and OTOH, in years of using an explicit
UTF-8 I haven't had any problems...
--
((x=>x(x))(x=>x(x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
- bug#24953: 25.1; Possible inefficiency in UTF-8,
Eli Barzilay <=