bug#52295: 28.0.90; Killing text results in coding system complaint

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: 52295@debbugs.gnu.org
>> Date: Sun, 05 Dec 2021 17:26:11 +0800
>> 
>> >> >   selection-coding-system
>> >> >   next-selection-coding-system
>> >> 
>> >> Both variables are nil.
>> >
>> > That's the problem.  But I don't understand why is that so.  The value
>> > of selection-coding-system is set in globals_of_w32select, which is
>> > called during startup, and where we have this code:
>> >
>> >   ANSICP = GetACP ();
>> >   OEMCP = GetOEMCP ();
>> >
>> >   QANSICP = coding_from_cp (ANSICP);
>> >   QOEMCP = coding_from_cp (OEMCP);
>> >
>> >   if (os_subtype == OS_SUBTYPE_NT)
>> >     Vselection_coding_system = Qutf_16le_dos;
>> >   else if (inhibit_window_system)
>> >     Vselection_coding_system = QOEMCP;
>> >   else
>> >     Vselection_coding_system = QANSICP;
>> >
>> > On Windows 9X, this should assign the ANSI codepage to
>> > selection-coding-system.  Since your codepage seems to be 1252, it
>> > should assign the symbol 'cp1252-dos' to selection-coding-system, see
>> > coding_from_cp.
>> >
>> > Why doesn't this happen in your case?
>> 
>> Maybe that variable is dumped during the build process, with a value
>> appropriate for NT, and when Emacs starts on a 9X system some other code
>> sees that it is invalid and sets it to nil?
>
> No, the code above is run in the dumped Emacs, when it starts, not in
> temacs.  So the values should reflect what happens when you start
> Emacs on the Windows 9X system.

> Could you perhaps add some printf's there to see what actually
> happens?  It almost looks like that code doesn't get called (which
> would be strange by itself), since coding_from_cp cannot possibly
> return nil.  Or maybe the initial assignment does work, but then some
> code resets the variable back to nil?

`globals_of_w32select' is called, but QANSICP is nil:

  Fprint (QANSICP, Qexternal_debugging_output);

Prints "nil" onto the console.