bug-gnu-emacs
[Top][All Lists]
Advanced

[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 ;-)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]