bug#81489: 32.0.50; w32--terminal-is-conhost is nil in gui emacs.

> From: TAKAHASHI Yoshio <[email protected]>
> Cc: [email protected]
> Date: Mon, 27 Jul 2026 09:57:56 +0900
> 
> Eli-san,
> 
> Thank you for your time.
> 
> Eli Zaretskii <[email protected]> writes:
> 
> > What happens if you do this after starting a patched Emacs:
> >   M-: (setopt cjk-ambiguous-chars-are-wide t) RET
> > and _then_ visit the file a.el?
> 
> It returns 6.  Good!  I include latest a.el and the output in this mail.

OK, that's good to know.

> What I want to understand is the behavior before setting
> cjk-ambiguous-chars-are-wide after invoke a new gui emacs instance.
> Why corrent-column returns 5 with "MS gothic" font, before setting
> c-a-c-a-wide to t?
> The default value of c-a-c-a-wide is t, we need not to set/reset it if
> the default value is the same value as expectation.
> 
> > I don't see how bootstrap is relevant, since
> > cjk-ambiguous-chars-are-wide should be set at run time, not when Emacs
> > is built.  Setting up a CJK language-environment (which happens at
> > startup) should perform the correct initialization, because
> > use-cjk-char-width-table should be called when Japanese
> > language-environment is entered.  Doesn't that happen for you?
> 
> Call (set-language-environment 'Japanese) at the beginning of a.el does
> not change the result, still returns 5.

What happens if you add this at the beginning of a.el:

  (set-language-environment "English")
  (set-language-environment "Japanese")

Does that work then?

> My guess is:
> c-a-c-a-wide is defcustomed to t in characters.el.
> its set function is called during bootstrap.
> ambigous chars table are set to 1 because we have no window-system,
> and the table is dumped into emacs binary.
> dumped binary has c-a-c-a-wide is t, but ambigous chars' width is 1.

That is correct, but it is not the whole story.

When Emacs starts, startup.el calls set-locale-environment.
set-locale-environment looks at the environment variables "LC_ALL",
"LC_CTYPE", and "LANG", and uses the first one which has a non-nil
non-empty value.  It then calls set-language-environment with a
language derived from the locale found in these variables.  In your
case, the above should cause set-language-environment be called with
"Japanese" as the language.  If you run Emacs under GDB and put a
breakpoint in Fassoc_string (a function called by
set-language-environment), you should be able to see this call dureing
startup.

Now, in japanese.el you will see that the Japanese
language-environment defines setup-japanese-environment-internal as
the setup function, and that function issues this call:

  (use-cjk-char-width-table 'ja_JP)

Which should have set the character-width table according to
cjk-ambiguous-chars-are-wide, if you look at the code of
use-cjk-char-width-table.

I wonder why this doesn't work for you during startup.  Perhaps you
could look at the relevant codes and try figuring this out?  There's
probably something I'm missing here, but what?

Please tell the values of the variables current-locale-environment and
current-iso639-language in a GUI session of Emacs which you built with
the patched characters.el.  Also, what does 'M-: (getenv "LANG")'
produce in that session?

In an earlier message you wrote:

> And, my LANG is ja_JP.UTF-8.

But ja_JP.UTF-8 is not the way Windows designates the Japanese locale.
The above looks like a Posix locale string, so I wonder where did you
get it.  Is it possible that you are running Emacs from the MSYS2 Bash
window, which sets LANG to this string?  If so, could you please try
running from the Command Prompt window that runs cmd.exe?  I'm not
sure this is relevant, but it will reduce the number of unknowns.

> >From characters.el comment:
>                     ;; MS-Windows Terminal forces all ambiguous
>                     ;; characters to be narrow, even in CJK locales.
> 
> I'm not sure MS-Windows Terminal, what happends if a user uses font such
> as "MS Gothic" that has wide ambigous chars?
> Need to call (setopt c-a-c-a-wide t) explicitly?

Emacs does not control the fonts used by the Windows Terminal, and you
use a GUI session, so what Windows Terminal does is for now not
relevant.  The patch I sent, assuming you have rebuilt Emacs after
applying it, is supposed to make it so w32--terminal-is-conhost does
not affect GUI sessions of Emacs, only -nw sessions.