[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#70914: 29.3; Crashes often on Windows
From: |
Simen Endsjø |
Subject: |
bug#70914: 29.3; Crashes often on Windows |
Date: |
Thu, 16 May 2024 09:05:44 +0200 |
> And why is the value of $LANG "en_US"? It's supposed to be "ENU" on
> Windows.
>> 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).
>> 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.
Found out why I set this. Hunspell gives the error
(Hunspell error (is $LANG unset?): Can't open affix or dictionary
files for dictionary named "default".)
So I probably fixed this by setting LANG=en_US in the system variable.
But isn't it strange that it cannot find LANG? I see LANG=ENU for the emacs
process -- shouldn't this automatically get into the hunspell subprocess when
forked..? If I set LANG explicitly `(setenv "LANG" "ENU")` it works (although
hunspell complains as there is no dictionary for ENU).
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 ;-)
- bug#70914: 29.3; Crashes often on Windows, (continued)
- bug#70914: 29.3; Crashes often on Windows, Simen Endsjø, 2024/05/14
- bug#70914: 29.3; Crashes often on Windows, Eli Zaretskii, 2024/05/14
- bug#70914: 29.3; Crashes often on Windows, Simen Endsjø, 2024/05/15
- bug#70914: 29.3; Crashes often on Windows, Simen Endsjø, 2024/05/15
- bug#70914: 29.3; Crashes often on Windows, Simen Endsjø, 2024/05/15
- bug#70914: 29.3; Crashes often on Windows, Eli Zaretskii, 2024/05/15
- bug#70914: 29.3; Crashes often on Windows, Eli Zaretskii, 2024/05/15
- bug#70914: 29.3; Crashes often on Windows, Simen Endsjø, 2024/05/15
- bug#70914: 29.3; Crashes often on Windows, Eli Zaretskii, 2024/05/15
- bug#70914: 29.3; Crashes often on Windows, Simen Endsjø, 2024/05/15
- bug#70914: 29.3; Crashes often on Windows,
Simen Endsjø <=
- bug#70914: 29.3; Crashes often on Windows, Eli Zaretskii, 2024/05/16
- bug#70914: 29.3; Crashes often on Windows, Simen Endsjø, 2024/05/24
- bug#70914: 29.3; Crashes often on Windows, Simen Endsjø, 2024/05/15
- bug#70914: 29.3; Crashes often on Windows, Eli Zaretskii, 2024/05/15
- bug#70914: 29.3; Crashes often on Windows, Simen Endsjø, 2024/05/15
- bug#70914: 29.3; Crashes often on Windows, Simen Endsjø, 2024/05/15
- bug#70914: 29.3; Crashes often on Windows, Simen Endsjø, 2024/05/15
- bug#70914: 29.3; Crashes often on Windows, Eli Zaretskii, 2024/05/15
- bug#70914: 29.3; Crashes often on Windows, Simen Endsjø, 2024/05/15
- bug#70914: 29.3; Crashes often on Windows, Simen Endsjø, 2024/05/15