I forgot to say this, when I enter `chcp 857` and then enter emacs, the
problem still exists even though the system returns chcp 857.


On Mon, Jun 29, 2020 at 8:06 PM Yigit Emre Sahinoglu <yigitemres@gmail.com>
wrote:

>   C-x RET t cp857 RET
>>
>   C-x RET k cp857 RET
>
>
> Not helping. The problem still exists.
>
> This is Windows 10, right?  Do you per chance have the UTF-8 support
>> feature enabled?
>>
>
> I use Windows 10. I cannot find UTF-8 support feature (look from `Windows
> features on or off`  from Control Panel) but I'm pretty sure that UTF-8
> support feature exists. Only problematic software I'm aware of is `emacs
> -nw`.
>
>
> Yiğit Emre Şahinoğlu
>
>
> On Mon, Jun 29, 2020 at 6:51 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > Cc: 42099@debbugs.gnu.org
>> > From: Yigit Emre Sahinoglu <yigitemres@gmail.com>
>> > Date: Mon, 29 Jun 2020 17:42:13 +0300
>> >
>> > chcp returns "Active code page: 437"
>> >
>> > All chars displayed correctly on cmd.exe. It's something about Emacs
>> > Windows (maybe mingw do something finicky), I'm sure of that.
>>
>> As long as the codepage reported to Emacs is 437, you will not be able
>> to see nor input Turkish characters.  the question is why is this
>> codepage being returned, when the system evidently uses a different
>> encoding...
>>
>> This is Windows 10, right?  Do you per chance have the UTF-8 support
>> feature enabled?
>>
>> You could also try this, once inside Emacs:
>>
>>   C-x RET t cp857 RET
>>   C-x RET k cp857 RET
>>
>> Does that help?
>>
>