From: Eli Zaretskii <eliz@gnu.org>
To: michal@0lock.xyz
Cc: 75207@debbugs.gnu.org
Subject: bug#75207: Fwd: bug#75207: 29.4; Path conversion from native codepage to UTF-8 fails when Windows is set by default to UTF-8
Date: Sat, 04 Jan 2025 11:30:34 +0200 [thread overview]
Message-ID: <867c7bexj9.fsf@gnu.org> (raw)
In-Reply-To: <86a5c7hqc4.fsf@gnu.org> (message from Eli Zaretskii on Fri, 03 Jan 2025 17:25:31 +0200)
> Cc: 75207@debbugs.gnu.org
> Date: Fri, 03 Jan 2025 17:25:31 +0200
> From: Eli Zaretskii <eliz@gnu.org>
>
> > I debugged a bit and it looks like w32_ansi_code_page is set to 1252 at some point.
>
> AFAICT, that happens when we load the pdumper file.
>
> > M-: w32-multibyte-code-page -> 0
> > M-: locale-coding-system -> cp65001
> > M-: file-name-coding-system -> nil
> > M-: default-file-name-coding-system -> cp65001
>
> OK, I think this confirms my hypothesis. I'll try to come up with a
> patch, probably tomorrow.
The patch is below, and it is for the master branch of the Emacs Git
repository.
> > > If I send you a C-level patch, are you able to build Emacs after patching it,
> > > preferably the master branch of our Git repository?
> >
> > Sure.
>
> OK, but you'll need to build Emacs with a different system codepage to
> see the effects of the fix.
This still stands: to fully test the patch, please change your system
codepage after building Emacs and then start Emacs and see if
everything works as expected.
diff --git a/src/emacs.c b/src/emacs.c
index c1e0c9f..896f219 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -1419,7 +1419,18 @@ android_emacs_init (int argc, char **argv, char *dump_file)
#ifdef HAVE_PDUMPER
if (attempt_load_pdump)
- initial_emacs_executable = load_pdump (argc, argv, dump_file);
+ {
+ initial_emacs_executable = load_pdump (argc, argv, dump_file);
+#ifdef WINDOWSNT
+ /* Reinitialize the codepage for file names, needed to decode
+ non-ASCII file names during startup. This is needed because
+ loading the pdumper file above assigns to those variables values
+ from the dump stage, which might be incorrect, if dumping was done
+ on a different system. */
+ if (dumped_with_pdumper_p ())
+ w32_init_file_name_codepage ();
+#endif
+ }
#else
ptrdiff_t bufsize;
initial_emacs_executable = find_emacs_executable (argv[0], &bufsize);
diff --git a/src/w32.c b/src/w32.c
index a493991..deeca03 100644
--- a/src/w32.c
+++ b/src/w32.c
@@ -1685,6 +1685,19 @@ w32_init_file_name_codepage (void)
{
file_name_codepage = CP_ACP;
w32_ansi_code_page = CP_ACP;
+#ifdef HAVE_PDUMPER
+ /* If we were dumped with pdumper, this function will be called after
+ loading the pdumper file, and needs to reset the following
+ variables that come from the dump stage, which could be on a
+ different system with different default codepages. Then, the
+ correct value of w32-ansi-code-page will be assigned by
+ globals_of_w32fns, which is called from 'main'. Until that call
+ happens, w32-ansi-code-page will have the value of CP_ACP, which
+ stands for the default ANSI codepage. The other variables will be
+ computed by codepage_for_filenames below. */
+ Vdefault_file_name_coding_system = Qnil;
+ Vfile_name_coding_system = Qnil;
+#endif
}
/* Produce a Windows ANSI codepage suitable for encoding file names.
next prev parent reply other threads:[~2025-01-04 9:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-30 12:12 bug#75207: 29.4; Path conversion from native codepage to UTF-8 fails when Windows is set by default to UTF-8 michal--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-30 19:13 ` Eli Zaretskii
[not found] ` <003001db5d81$a8f144b0$fad3ce10$@0lock.xyz>
2025-01-03 11:49 ` bug#75207: Fwd: " Michał Lach via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-03 13:23 ` Eli Zaretskii
2025-01-03 14:35 ` michal--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-03 15:25 ` Eli Zaretskii
2025-01-04 9:30 ` Eli Zaretskii [this message]
2025-01-04 17:37 ` michal--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-05 5:58 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=867c7bexj9.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=75207@debbugs.gnu.org \
--cc=michal@0lock.xyz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.