bug#70914: 29.3; Crashes often on Windows

[Eli Zaretskii <eliz@gnu.org>]

> From: Simen Endsjø <simendsjo@gmail.com>
> Date: Tue, 14 May 2024 15:58:48 +0200
> Cc: 70914@debbugs.gnu.org
> 
> I'm not really sure why I've added these anymore. I've added them over time
> since 2016 first using Spacemacs, then Doom Emacs.
> 
> >>   ;; Windows doesn't set this, but some packages might depend on the variable
> >>   (setenv "LANG" "en_US")
> >
> > The comment is not correct.  To see for yourself, ensure LANG is not
> > set in the system-wide environment, start "emacs -Q", and then type
> >
> >  M-: (getenv "LANG") RET
> 
> That's interesting. I usually just { M-x getenv }, and LANG isn't listed there.
> (getenv "LANG") returns "ENU" though. Looking at the environment variables for
> the process, I see LANG listed there. How is getenv *not* listing the variable?
> Has it marked it special somehow and filter it out?

It's a Windows-specific trick: we ad a few environment variables at
startup such that getenv can access them, but don't want it to appear
in process-environment explicitly, and so the function that prompts
for the variable when you invoke getenv interactively doesn't know
about them.

> > This is a very bad idea, IME.  The clipboard on Windows uses UTF-16,
> > and Emacs knows how to decode it correctly.  Customizing
> > clipboard-coding-system to something else just gets in the way.
> 
> Probably something I did after changing Windows to use utf-8, which also
> includes the clipboard.
> 
> > I don't know where does the comment about latin-1 by default come from
> > (maybe from Windows 9X days?), but it is not true on Windows for a
> > very long time.  The default value of selection-coding-system on
> > Windows is utf-16le-dos, you can again verify that in "emacs -Q".
> 
> Maybe I broke something else when trying to get text to work properly and added
> that hack as a workaround..? I really have no idea. Don't want to dig through my
> git commits to find out ;)
> 
> > Again, I'm not sure this is relevant to the crashes.  But it doesn't
> > do any harm to make your Emacs configuration healthier ;-)
> 
> Yes, thanks a lot for the help! I'm a bit scared to remove these hacks I've
> accumulated over time as I probably added them there for a reason though. But
> hopefully the workarounds was just for some symptoms and not the root cause --
> we'll see.

I suggest to remove them, and see if the crashes keep happening.

If removing these hacks make something stop working, describe the
problems with the details: there are definitely ways to solve them
without these dangerous customizations.