bug#70914: 29.3; Crashes often on Windows

[Simen Endsjø]

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?

> 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.

On Tue, May 14, 2024 at 2:30 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Simen Endsjø <simendsjo@gmail.com>
> > Date: Tue, 14 May 2024 14:08:52 +0200
> > Cc: 70914@debbugs.gnu.org
> >
> > I understood it as writing outside the stack space for a completion.
> > Could be caused by some incorrect handling of coding systems where too
> > little space was reserved as you note.
>
> That's unlikely, since (a) I see no encoding in all-completions, and
> (b) the encoding routines don't use the stack.  However, if I will see
> chkstk in all of your backtraces, I might change my mind about that.
>
> > I'm setting LANG to en_US both in the system environment and in my
> > emacs configuration.
>
> Why?  You shouldn't need to do that on Windows.  Emacs running on
> Windows determines the correct value of LANG from Windows-specific
> APIs, and sets LANG internally.  If your language environment is
> English, Emacs should set LANG to "ENU" on Windows.  "ENU" is the
> MS-Windows equivalent of the Posix en_US (the latter is not really
> supported on Windows).
>
> > I've also enabled UTF-8 everywhere on the systems (beta feature).
>
> I don't recommend that.  But even if you do set it for the rest of
> your system, it is not a good idea to do that in Emacs, especially for
> communications with sub-processes, where UTF-8 is not supported on
> Windows -- quite a lot of programs we are used to invoke from Emacs,
> especially ports of GNU software (and console programs in general)
> will not be able to interpret UTF-8 command-line arguments passed to
> them by Emacs, not in general anyway.
>
> > But it's better to use LANG=ENU and the default coding system?
>
> Yes.  And you shouldn't need to set any of these, neither LANG not the
> coding systems: Emacs will do that itself at startup, and should do it
> correctly.
>
> > Here's the relevant configuration from my init.el:
> >
> >   ;; 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
>
> >   ;; While the Windows clipboard shouldn't change the coding system,
> >   ;; I get latin-1 back when pasting in Emacs.
> >   ;; See `list-coding-systems'
> >   ;; NOTE: I've turned on the global utf8 beta feature in Windows,
> >   ;; and we thus don't need this
> >   ;;(set-clipboard-coding-system 'latin-1)
> >   (set-clipboard-coding-system 'utf-8)
>
> 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.  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".
>
> Again, I'm not sure this is relevant to the crashes.  But it doesn't
> do any harm to make your Emacs configuration healthier ;-)