bug#58281: 27.1; windows mangles encoding on command line

bug#58281: 27.1; windows mangles encoding on command line

[Wayne Harris]

I run emacs -Q.  I open eshell.  Then I try to use fossil (which is a
version control system like git) and try to put accented letters on the
commit message.  No choice of encoding seems to avoid the mangling.

c:/my/path $ alias fs 'fossil $*'
c:/my/path $ echo kkk >> encoding.txt 
c:/my/path $ fs changes
EDITED     encoding.txt

c:/my/path $ (print default-process-coding-system)
(undecided-dos . undecided-unix)

c:/my/path $ (or buffer-file-coding-system "it is nil")
it is nil

c:/my/path $ fs commit -m 'Naiveté'
[...]
Sync done, wire bytes sent: 3234  received: 309  ip: 5.161.138.46

c:/my/path $ fs timeline -n 1
=== 2022-10-02 ===
13:11:20 [febbbf0441] *CURRENT* Naiveté (user: mer tags: trunk)
--- entry limit (1) reached ---
c:/my/path $ 

Commit message has been mangled.  I then tried to set the ESHELL buffer
to utf-8 to no avail.  Eli Zaretskii kindly helped me to investigate
this in the help-gnu-emacs@gnu.org maillist.  First message was 

  <86wn9jd3sw.fsf@protonmail.com>

with subject 

  on ESHELL, utf-8 and fossil command-line commit message

--8<---------------cut here---------------start------------->8---
> Who is mangling my command-line arguments and why?  Thank you!

You cannot use UTF-8 for encoding command-line arguments of
subprocesses on MS-Windows.  Use your system's codepage instead.  This
means make sure the Eshell buffer's value of buffer-file-coding-system
is your system codepage, not UTF-8.
--8<---------------cut here---------------end--------------->8---


In GNU Emacs 27.1 (build 1, x86_64-w64-mingw32)
 of 2020-08-21 built on CIRROCUMULUS
Repository revision: 86d8d76aa36037184db0b2897c434cdaab1a9ae8
Repository branch: HEAD
Windowing system distributor 'Microsoft Corp.', version 10.0.19041
System Description: Microsoft Windows 10 Enterprise (v10.0.2004.19041.388)

Configured using:
 'configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LC_ALL: C
  value of $LANG: en_US
  locale-coding-system: cp1252

Major mode: Article

Minor modes in effect:
  shell-dirtrack-mode: t
  electric-pair-mode: t
  show-paren-mode: t
  recentf-mode: t
  save-place-mode: t
  winner-mode: t
  display-time-mode: t
  global-eldoc-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
c:/sys/emacs/usr/.emacs.d/elpa/pos-tip-20191227.1356/pos-tip hides c:/sys/emacs/share/emacs/site-lisp/my-pos-tip/pos-tip
c:/sys/emacs/usr/.emacs.d/elpa/pos-tip-20191227.1356/pos-tip-pkg hides c:/sys/emacs/share/emacs/site-lisp/my-pos-tip/pos-tip-pkg
c:/sys/emacs/usr/.emacs.d/elpa/pos-tip-20191227.1356/pos-tip-autoloads hides c:/sys/emacs/share/emacs/site-lisp/my-pos-tip/pos-tip-autoloads
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-xp hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-xp
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-xp-complete hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-xp-complete
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-wsl hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-wsl
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-visit hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-visit
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-util hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-util
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-unicode-input-method hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-unicode-input-method
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-stepper hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-stepper
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-smart-open hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-smart-open
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-show hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-show
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-repl hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-repl
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-repl-buffer-name hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-repl-buffer-name
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-profile hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-profile
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-ppss hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-ppss
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-parens hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-parens
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-mode hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-mode
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-logger hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-logger
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-keywords-and-builtins hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-keywords-and-builtins
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-indent hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-indent
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-imenu hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-imenu
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-font-lock hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-font-lock
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-eldoc hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-eldoc
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-edit hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-edit
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-doc hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-doc
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-describe hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-describe
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-debug hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-debug
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-custom hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-custom
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-complete hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-complete
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-common hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-common
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-collection hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-collection
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-cmd hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-cmd
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-bug-report hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-bug-report
c:/sys/emacs/usr/.emacs.d/elpa/racket-mode-20201022.1304/racket-browse-url hides c:/sys/emacs/share/emacs/site-lisp/my-racket-mode/racket-browse-url
c:/sys/emacs/usr/.emacs.d/elpa/seq-2.23/seq hides c:/sys/emacs/share/emacs/27.1/lisp/emacs-lisp/seq

Features:
(shadow emacsbug sendmail qp gnus-html help-fns radix-tree url-cache
vc-git diff-mode mhtml-mode css-mode smie eww mm-url url-queue color js
imenu cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align
cc-engine cc-vars cc-defs sgml-mode pcmpl-unix em-unix em-term term
ehelp em-script em-prompt em-ls em-hist em-pred em-glob em-dirs esh-var
em-cmpl em-basic em-banner em-alias esh-mode eshell esh-cmd esh-ext
esh-opt esh-proc esh-io esh-arg esh-module esh-groups esh-util ibuf-ext
ibuffer ibuffer-loaddefs mm-archive pp canlock warnings nnir mule-util
sort gnus-cite mail-extr gnus-async gnus-bcklg gnus-ml nndraft nnmh
nnfolder gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg
gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-cache gnus-sum
url url-proxy url-privacy url-expand url-methods url-history mailcap shr
url-cookie url-domsuf url-util svg xml dom gnutls network-stream nsm
nntp gnus-group gnus-undo cl gnus-start gnus-cloud nnimap nnmail
mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range message rmc
puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg epg-config
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader gnus-win gnus nnheader gnus-util rmail rmail-loaddefs rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils rx text-property-search
thingatpt compile cl-extra help-mode python tramp-sh tramp
tramp-loaddefs trampver tramp-integration files-x tramp-compat shell
pcomplete parse-time iso8601 format-spec comint ansi-color misearch
multi-isearch time-date paredit edmacro kmacro easy-mmode finder-inf
info elec-pair paren recentf tree-widget wid-edit saveplace winner ring
windmove server time my package easymenu browse-url url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table
term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads w32notify w32
lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 446989 94601)
 (symbols 48 29224 2)
 (strings 32 128086 11600)
 (string-bytes 1 3901474)
 (vectors 16 51405)
 (vector-slots 8 2463639 186586)
 (floats 8 535 466)
 (intervals 56 16557 934)
 (buffers 1000 64))

bug#58281: 27.1; windows mangles encoding on command line

[Eli Zaretskii]

> From: Wayne Harris <dbastos@toledo.com>
> Date: Mon, 03 Oct 2022 22:18:35 -0300
> 
> 
> I run emacs -Q.  I open eshell.  Then I try to use fossil (which is a
> version control system like git) and try to put accented letters on the
> commit message.  No choice of encoding seems to avoid the mangling.
> 
> c:/my/path $ alias fs 'fossil $*'
> c:/my/path $ echo kkk >> encoding.txt 
> c:/my/path $ fs changes
> EDITED     encoding.txt
> 
> c:/my/path $ (print default-process-coding-system)
> (undecided-dos . undecided-unix)
> 
> c:/my/path $ (or buffer-file-coding-system "it is nil")
> it is nil
> 
> c:/my/path $ fs commit -m 'Naiveté'
> [...]
> Sync done, wire bytes sent: 3234  received: 309  ip: 5.161.138.46
> 
> c:/my/path $ fs timeline -n 1
> === 2022-10-02 ===
> 13:11:20 [febbbf0441] *CURRENT* Naiveté (user: mer tags: trunk)
> --- entry limit (1) reached ---
> c:/my/path $ 

Where did you download Fossil for MS-Windows?  Is it a native Windows
program, or a Cygwin program?  Is 'fs' a program (i.e. fs.exe) or some
kind of shell script, and if the latter, can you post the script?

Also, do you know whether Fossil expects the message text in some
particular encoding?

bug#58281: 27.1; windows mangles encoding on command line

[Daniel Bastos]

On Tue, Oct 4, 2022 at 7:02 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Wayne Harris <dbastos@toledo.com>
> > Date: Mon, 03 Oct 2022 22:18:35 -0300
> >
> > I run emacs -Q.  I open eshell.  Then I try to use fossil (which is a
> > version control system like git) and try to put accented letters on the
> > commit message.  No choice of encoding seems to avoid the mangling.
> >
> > c:/my/path $ alias fs 'fossil $*'
> > c:/my/path $ echo kkk >> encoding.txt
> > c:/my/path $ fs changes
> > EDITED     encoding.txt
> >
> > c:/my/path $ (print default-process-coding-system)
> > (undecided-dos . undecided-unix)
> >
> > c:/my/path $ (or buffer-file-coding-system "it is nil")
> > it is nil
> >
> > c:/my/path $ fs commit -m 'Naiveté'
> > [...]
> > Sync done, wire bytes sent: 3234  received: 309  ip: 5.161.138.46
> >
> > c:/my/path $ fs timeline -n 1
> > === 2022-10-02 ===
> > 13:11:20 [febbbf0441] *CURRENT* Naiveté (user: mer tags: trunk)
> > --- entry limit (1) reached ---
> > c:/my/path $
>
> Where did you download Fossil for MS-Windows?  Is it a native Windows
> program, or a Cygwin program?  Is 'fs' a program (i.e. fs.exe) or some
> kind of shell script, and if the latter, can you post the script?

I went to

  https://fossil-scm.org/home/uv/download.html

and chose the last one --- Windows64 ---, which is the ZIP at

  https://fossil-scm.org/home/uv/fossil-w64-2.19.zip

Inside this ZIP, there's a fossil.exe binary.  All evidence points to
a native Windows program, not a Cygwin program.

%file c:/my/path/fossil.exe
c:/my/path/fossil.exe: PE32+ executable (console) x86-64, for MS Windows
%

There's no fs.exe and no script fs.  (Sorry about that.)  That's just
my alias in ESHELL.  You can safely assume that /fs/ just means
/fossil/.  (I shouldn't have used the alias in this bug report.
Sorry.)

> Also, do you know whether Fossil expects the message text in some
> particular encoding?

That I don't know.  I've looked into the documentation, but I did not
find anything that looked relevant.  I did find old commit messages in
the repository of fossil itself that little by little the developers
have been adding UTF-8 support to it.  But I can't say it expects any
particular encoding.

Thank you for looking into this issue.

bug#58281: 27.1; windows mangles encoding on command line

[Eli Zaretskii]

> From: Daniel Bastos <dbastos@id.uff.br>
> Date: Thu, 6 Oct 2022 09:03:50 -0300
> Cc: Wayne Harris <dbastos@toledo.com>, 58281@debbugs.gnu.org
> 
> On Tue, Oct 4, 2022 at 7:02 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > > From: Wayne Harris <dbastos@toledo.com>
> > > Date: Mon, 03 Oct 2022 22:18:35 -0300
> > >
> > > I run emacs -Q.  I open eshell.  Then I try to use fossil (which is a
> > > version control system like git) and try to put accented letters on the
> > > commit message.  No choice of encoding seems to avoid the mangling.
> > >
> > > c:/my/path $ alias fs 'fossil $*'
> > > c:/my/path $ echo kkk >> encoding.txt
> > > c:/my/path $ fs changes
> > > EDITED     encoding.txt
> > >
> > > c:/my/path $ (print default-process-coding-system)
> > > (undecided-dos . undecided-unix)
> > >
> > > c:/my/path $ (or buffer-file-coding-system "it is nil")
> > > it is nil
> > >
> > > c:/my/path $ fs commit -m 'Naiveté'
> > > [...]
> > > Sync done, wire bytes sent: 3234  received: 309  ip: 5.161.138.46
> > >
> > > c:/my/path $ fs timeline -n 1
> > > === 2022-10-02 ===
> > > 13:11:20 [febbbf0441] *CURRENT* Naiveté (user: mer tags: trunk)
> > > --- entry limit (1) reached ---
> > > c:/my/path $
> >
> > Where did you download Fossil for MS-Windows?  Is it a native Windows
> > program, or a Cygwin program?  Is 'fs' a program (i.e. fs.exe) or some
> > kind of shell script, and if the latter, can you post the script?
> 
> I went to
> 
>   https://fossil-scm.org/home/uv/download.html
> 
> and chose the last one --- Windows64 ---, which is the ZIP at
> 
>   https://fossil-scm.org/home/uv/fossil-w64-2.19.zip
> 
> Inside this ZIP, there's a fossil.exe binary.  All evidence points to
> a native Windows program, not a Cygwin program.
> 
> %file c:/my/path/fossil.exe
> c:/my/path/fossil.exe: PE32+ executable (console) x86-64, for MS Windows
> %
> 
> There's no fs.exe and no script fs.  (Sorry about that.)  That's just
> my alias in ESHELL.  You can safely assume that /fs/ just means
> /fossil/.  (I shouldn't have used the alias in this bug report.
> Sorry.)
> 
> > Also, do you know whether Fossil expects the message text in some
> > particular encoding?
> 
> That I don't know.  I've looked into the documentation, but I did not
> find anything that looked relevant.  I did find old commit messages in
> the repository of fossil itself that little by little the developers
> have been adding UTF-8 support to it.  But I can't say it expects any
> particular encoding.

I think you said at some point that using non-ASCII commit log
messages from a shell outside of Emacs did succeed?  If so, can you
describe how you do that, i.e. which shell do you use and how you type
'Naiveté' from the shell?  Also, what does the command "chcp" report
in that shell, if you invoke it with no arguments?

bug#58281: 27.1; windows mangles encoding on command line

[Daniel Bastos]

On Wed, Oct 12, 2022 at 5:45 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Daniel Bastos <dbastos@id.uff.br>
> > Date: Thu, 6 Oct 2022 09:03:50 -0300
> > Cc: Wayne Harris <dbastos@toledo.com>, 58281@debbugs.gnu.org
> >
> > On Tue, Oct 4, 2022 at 7:02 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > > > From: Wayne Harris <dbastos@toledo.com>
> > > > Date: Mon, 03 Oct 2022 22:18:35 -0300
> > > >
> > > > I run emacs -Q.  I open eshell.  Then I try to use fossil (which is a
> > > > version control system like git) and try to put accented letters on the
> > > > commit message.  No choice of encoding seems to avoid the mangling.
> > > >
> > > > c:/my/path $ alias fs 'fossil $*'
> > > > c:/my/path $ echo kkk >> encoding.txt
> > > > c:/my/path $ fs changes
> > > > EDITED     encoding.txt
> > > >
> > > > c:/my/path $ (print default-process-coding-system)
> > > > (undecided-dos . undecided-unix)
> > > >
> > > > c:/my/path $ (or buffer-file-coding-system "it is nil")
> > > > it is nil
> > > >
> > > > c:/my/path $ fs commit -m 'Naiveté'
> > > > [...]
> > > > Sync done, wire bytes sent: 3234  received: 309  ip: 5.161.138.46
> > > >
> > > > c:/my/path $ fs timeline -n 1
> > > > === 2022-10-02 ===
> > > > 13:11:20 [febbbf0441] *CURRENT* Naiveté (user: mer tags: trunk)
> > > > --- entry limit (1) reached ---
> > > > c:/my/path $
> > >
> > > Where did you download Fossil for MS-Windows?  Is it a native Windows
> > > program, or a Cygwin program?  Is 'fs' a program (i.e. fs.exe) or some
> > > kind of shell script, and if the latter, can you post the script?
> >
> > I went to
> >
> >   https://fossil-scm.org/home/uv/download.html
> >
> > and chose the last one --- Windows64 ---, which is the ZIP at
> >
> >   https://fossil-scm.org/home/uv/fossil-w64-2.19.zip
> >
> > Inside this ZIP, there's a fossil.exe binary.  All evidence points to
> > a native Windows program, not a Cygwin program.
> >
> > %file c:/my/path/fossil.exe
> > c:/my/path/fossil.exe: PE32+ executable (console) x86-64, for MS Windows
> > %
> >
> > There's no fs.exe and no script fs.  (Sorry about that.)  That's just
> > my alias in ESHELL.  You can safely assume that /fs/ just means
> > /fossil/.  (I shouldn't have used the alias in this bug report.
> > Sorry.)
> >
> > > Also, do you know whether Fossil expects the message text in some
> > > particular encoding?
> >
> > That I don't know.  I've looked into the documentation, but I did not
> > find anything that looked relevant.  I did find old commit messages in
> > the repository of fossil itself that little by little the developers
> > have been adding UTF-8 support to it.  But I can't say it expects any
> > particular encoding.
>
> I think you said at some point that using non-ASCII commit log
> messages from a shell outside of Emacs did succeed?  If so, can you

Not from a shell but from a regular GNU EMACS buffer.  I then showed
an ESHELL session where I don't specify the commit message on the
command-line and then emacsclientw was invoked.  In the buffer that
opened, I typed an UTF-8 encoded message and that was not mangled.

--8<---------------cut here---------------start------------->8---
However, if instead of the command-line, I use a regular GNU EMACS
buffer, it works just fine.

%echo kkk >> encoding.txt

%fs commit
Pull from https://mer@somewhere.edu/test
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, wire bytes sent: 437  received: 2118  ip: 5.161.138.46
emacsclientw ./ci-comment-A2803F45F10B.txt
Waiting for Emacs...
Pull from https://mer@somewhere.edu/test
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, wire bytes sent: 441  received: 2118  ip: 5.161.138.46
New_Version: 09ea1b5d5b8d776d61a74bb412cd58bd8b6f82323c2f539a1eb0d915f7026f20
Sync with https://mer@somewhere.edu/test
Round-trips: 1   Artifacts sent: 2  received: 0
Sync done, wire bytes sent: 2496  received: 309  ip: 5.161.138.46

%fs timeline
=== 2022-10-01 ===
14:09:39 [09ea1b5d5b] *CURRENT* Naiveté. (user: mer tags: trunk)
--8<---------------cut here---------------end--------------->8---

> describe how you do that, i.e. which shell do you use and how you type
> 'Naiveté' from the shell?  Also, what does the command "chcp" report
> in that shell, if you invoke it with no arguments?

I had not tested with a different shell.  I'm testing it with cmd.exe
below.  The encoding is not mangled, but I don't know which encoding
is applied there because I have no idea how cmd.exe works.  The
command chcp reports code page 850.

--8<---------------cut here---------------start------------->8---
c:\my\path>chcp
Active code page: 850

c:\my\path>fossil commit -m 'Naiveté'
Pull from https://mer@somewhere.edu/mer
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, wire bytes sent: 438  received: 3250  ip: 5.161.138.46
New_Version: 8cce649b5236e507e84ce8114ab273e3b9ea246dd00e42484b47ab86517cf028
Sync with https://mer@somewhere.edu/mer
Round-trips: 1   Artifacts sent: 2  received: 0
Sync done, wire bytes sent: 3615  received: 307  ip: 5.161.138.46

c:\my\path>fossil timeline -n 1
=== 2022-10-12 ===
11:31:30 [8cce649b52] *CURRENT* 'Naiveté' (user: mer tags: trunk)
--- entry limit (1) reached ---

c:\my\path>
--8<---------------cut here---------------end--------------->8---

However, there is some evidence that UTF-8 is the encoding used by
cmd.exe.  I committed again with the message "água aaaaa".

--8<---------------cut here---------------start------------->8---
c:\my\path>fossil timeline -n 1
=== 2022-10-12 ===
11:38:30 [148c174ad3] *CURRENT* água aaaaa (user: mer tags: trunk)
--- entry limit (1) reached ---
--8<---------------cut here---------------end--------------->8---

I know "á" encodes to the two-byte c3 a1 in UTF-8.  Asking /od/ to
show me the byte sequence, I see the c3 a1 in there.  First notice the
position of the two-byte sequence of interest --- it's in line 0000060
at the 4th column.

--8<---------------cut here---------------start------------->8---
c:\my\path>fossil timeline -n 1 | od -t c
0000000   =   =   =       2   0   2   2   -   1   0   -   1   2       =
0000020   =   =  \n   1   1   :   3   8   :   3   0       [   1   4   8
0000040   c   1   7   4   a   d   3   ]       *   C   U   R   R   E   N
0000060   T   *       Ã   ¡   g   u   a       a   a   a   a   a       (
[...]
--8<---------------cut here---------------end--------------->8---

If we look at which bytes are there, we find c3 a1.  I do not
understand this: I have no idea why my cmd.exe is UTF-8 encoding
anything.

--8<---------------cut here---------------start------------->8---
c:\my\path>fossil timeline -n 1 | od -t x1
0000000 3d 3d 3d 20 32 30 32 32 2d 31 30 2d 31 32 20 3d
0000020 3d 3d 0a 31 31 3a 33 38 3a 33 30 20 5b 31 34 38
0000040 63 31 37 34 61 64 33 5d 20 2a 43 55 52 52 45 4e
0000060 54 2a 20 c3 a1 67 75 61 20 61 61 61 61 61 20 28
[...]
--8<---------------cut here---------------end--------------->8---

Feel free to ask me any further questions. Thank you!

bug#58281: 27.1; windows mangles encoding on command line

[Eli Zaretskii]

> From: Daniel Bastos <dbastos@id.uff.br>
> Date: Wed, 12 Oct 2022 08:49:32 -0300
> Cc: 58281@debbugs.gnu.org
> 
> > I think you said at some point that using non-ASCII commit log
> > messages from a shell outside of Emacs did succeed?  If so, can you
> 
> Not from a shell but from a regular GNU EMACS buffer.  I then showed
> an ESHELL session where I don't specify the commit message on the
> command-line and then emacsclientw was invoked.  In the buffer that
> opened, I typed an UTF-8 encoded message and that was not mangled.
> 
> --8<---------------cut here---------------start------------->8---
> However, if instead of the command-line, I use a regular GNU EMACS
> buffer, it works just fine.
> 
> %echo kkk >> encoding.txt
> 
> %fs commit
> Pull from https://mer@somewhere.edu/test
> Round-trips: 1   Artifacts sent: 0  received: 0
> Pull done, wire bytes sent: 437  received: 2118  ip: 5.161.138.46
> emacsclientw ./ci-comment-A2803F45F10B.txt
> Waiting for Emacs...
> Pull from https://mer@somewhere.edu/test
> Round-trips: 1   Artifacts sent: 0  received: 0
> Pull done, wire bytes sent: 441  received: 2118  ip: 5.161.138.46
> New_Version: 09ea1b5d5b8d776d61a74bb412cd58bd8b6f82323c2f539a1eb0d915f7026f20
> Sync with https://mer@somewhere.edu/test
> Round-trips: 1   Artifacts sent: 2  received: 0
> Sync done, wire bytes sent: 2496  received: 309  ip: 5.161.138.46
> 
> %fs timeline
> === 2022-10-01 ===
> 14:09:39 [09ea1b5d5b] *CURRENT* Naiveté. (user: mer tags: trunk)
> --8<---------------cut here---------------end--------------->8---

I don't understand what that means, sorry.  There's a lot of stuff
that isn't relevant to the issue at hand (and I'm not familiar with
fossil, so its detailed output makes no difference to me).  But
there's no description of what you did in plain English, which I could
read and understand.

I'm guessing that emacsclientw was invoked to edit a file with the
commit log message, and the commit command then used that edited
file.  If that is true, then there's no wonder this works: the problem
you experience only happens if the commit log message is passed to
fossil through the command-line arguments, not through a disk file.

> > describe how you do that, i.e. which shell do you use and how you type
> > 'Naiveté' from the shell?  Also, what does the command "chcp" report
> > in that shell, if you invoke it with no arguments?
> 
> I had not tested with a different shell.  I'm testing it with cmd.exe
> below.  The encoding is not mangled, but I don't know which encoding
> is applied there because I have no idea how cmd.exe works.  The
> command chcp reports code page 850.

If chcp says codepage 850, then cmd.exe uses that codepage to encode.
And my reading of the fossil source code is that it converts the
command-line arguments from the codepage-encoding to UTF-8 internally.

> 
> --8<---------------cut here---------------start------------->8---
> c:\my\path>chcp
> Active code page: 850
> 
> c:\my\path>fossil commit -m 'Naiveté'
> Pull from https://mer@somewhere.edu/mer
> Round-trips: 1   Artifacts sent: 0  received: 0
> Pull done, wire bytes sent: 438  received: 3250  ip: 5.161.138.46
> New_Version: 8cce649b5236e507e84ce8114ab273e3b9ea246dd00e42484b47ab86517cf028
> Sync with https://mer@somewhere.edu/mer
> Round-trips: 1   Artifacts sent: 2  received: 0
> Sync done, wire bytes sent: 3615  received: 307  ip: 5.161.138.46
> 
> c:\my\path>fossil timeline -n 1
> === 2022-10-12 ===
> 11:31:30 [8cce649b52] *CURRENT* 'Naiveté' (user: mer tags: trunk)
> --- entry limit (1) reached ---
> 
> c:\my\path>
> --8<---------------cut here---------------end--------------->8---

So now the question is why Eshell doesn't use the cp850 encoding when
you tell it?  What happens if you say

  C-x RET f cp850 RET

in the Eshell buffer before invoking the commit command?

> However, there is some evidence that UTF-8 is the encoding used by
> cmd.exe.  I committed again with the message "água aaaaa".
> 
> --8<---------------cut here---------------start------------->8---
> c:\my\path>fossil timeline -n 1
> === 2022-10-12 ===
> 11:38:30 [148c174ad3] *CURRENT* água aaaaa (user: mer tags: trunk)
> --- entry limit (1) reached ---
> --8<---------------cut here---------------end--------------->8---
> 
> I know "á" encodes to the two-byte c3 a1 in UTF-8.  Asking /od/ to
> show me the byte sequence, I see the c3 a1 in there.  First notice the
> position of the two-byte sequence of interest --- it's in line 0000060
> at the 4th column.
> 
> --8<---------------cut here---------------start------------->8---
> c:\my\path>fossil timeline -n 1 | od -t c
> 0000000   =   =   =       2   0   2   2   -   1   0   -   1   2       =
> 0000020   =   =  \n   1   1   :   3   8   :   3   0       [   1   4   8
> 0000040   c   1   7   4   a   d   3   ]       *   C   U   R   R   E   N
> 0000060   T   *       Ã   ¡   g   u   a       a   a   a   a   a       (
> [...]
> --8<---------------cut here---------------end--------------->8---
> 
> If we look at which bytes are there, we find c3 a1.  I do not
> understand this: I have no idea why my cmd.exe is UTF-8 encoding
> anything.

It doesn't.  What you see is the result of fossil's internal
conversion to UTF-8, not what cmd.exe passed to fossil.

bug#58281: 27.1; windows mangles encoding on command line

[Eli Zaretskii]

> From: Daniel Bastos <dbastos@id.uff.br>
> Date: Wed, 12 Oct 2022 08:49:32 -0300
> Cc: 58281@debbugs.gnu.org

In addition to what I just wrote, please try this: As soon as you
start Emacs, type:

  M-: (setq default-process-coding-system '(undecided-dos . cp850-dos)) RET

Then enter Eshell and try the fossil command you tried before.  See if
this solves the problem.

I think I found a bug in Eshell that the above workaround should
side-step.

bug#58281: 27.1; windows mangles encoding on command line

[Eli Zaretskii]

> Cc: 58281@debbugs.gnu.org
> Date: Wed, 12 Oct 2022 19:54:27 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Daniel Bastos <dbastos@id.uff.br>
> > Date: Wed, 12 Oct 2022 08:49:32 -0300
> > Cc: 58281@debbugs.gnu.org
> 
> In addition to what I just wrote, please try this: As soon as you
> start Emacs, type:
> 
>   M-: (setq default-process-coding-system '(undecided-dos . cp850-dos)) RET
> 
> Then enter Eshell and try the fossil command you tried before.  See if
> this solves the problem.
> 
> I think I found a bug in Eshell that the above workaround should
> side-step.

I've now installed a change for Emacs 29 that I think should fix your
problems.  So if you can try the current master branch of the Emacs
Git repository, please do, and see if your problem with Fossil are
solved there.

Thanks.

bug#58281: 27.1; windows mangles encoding on command line

[Eli Zaretskii]

Ping!  Did you have a chance to test the changes I installed?

> Cc: 58281@debbugs.gnu.org
> Date: Sat, 15 Oct 2022 14:02:16 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Cc: 58281@debbugs.gnu.org
> > Date: Wed, 12 Oct 2022 19:54:27 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > > From: Daniel Bastos <dbastos@id.uff.br>
> > > Date: Wed, 12 Oct 2022 08:49:32 -0300
> > > Cc: 58281@debbugs.gnu.org
> > 
> > In addition to what I just wrote, please try this: As soon as you
> > start Emacs, type:
> > 
> >   M-: (setq default-process-coding-system '(undecided-dos . cp850-dos)) RET
> > 
> > Then enter Eshell and try the fossil command you tried before.  See if
> > this solves the problem.
> > 
> > I think I found a bug in Eshell that the above workaround should
> > side-step.
> 
> I've now installed a change for Emacs 29 that I think should fix your
> problems.  So if you can try the current master branch of the Emacs
> Git repository, please do, and see if your problem with Fossil are
> solved there.
> 
> Thanks.
> 
> 
> 
> 

bug#58281: 27.1; windows mangles encoding on command line

[Daniel Bastos]

Pong!  I'm so sorry I've delayed this so much.  (It's been in my
inbox, though, so it would not be forgotten.)

On Sun, Nov 6, 2022 at 4:20 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> Ping!  Did you have a chance to test the changes I installed?
>
> > Cc: 58281@debbugs.gnu.org
> > Date: Sat, 15 Oct 2022 14:02:16 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> >
> > > Cc: 58281@debbugs.gnu.org
> > > Date: Wed, 12 Oct 2022 19:54:27 +0300
> > > From: Eli Zaretskii <eliz@gnu.org>
> > >
> > > > From: Daniel Bastos <dbastos@id.uff.br>
> > > > Date: Wed, 12 Oct 2022 08:49:32 -0300
> > > > Cc: 58281@debbugs.gnu.org
> > >
> > > In addition to what I just wrote, please try this: As soon as you
> > > start Emacs, type:
> > >
> > >   M-: (setq default-process-coding-system '(undecided-dos . cp850-dos)) RET
> > >
> > > Then enter Eshell and try the fossil command you tried before.  See if
> > > this solves the problem.

It did not.  I ran emacs -Q, evaluated the code above and tried this:

c:/my/path $ (print default-process-coding-system)
(undecided-dos . cp850-dos)

c:/my/path $ fossil changes
ADDED      hello.txt

c:/my/path $ fossil commit -m 'Naiveté.'
Pull from https://mer@somewhere.edu/mer
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, wire bytes sent: 439  received: 3830  ip: 5.161.138.46
New_Version: 092b3d5d04247d6b0784957dee568958838788585417e5be474ed8d67a15d9b8
Sync with https://mer@somewhere.edu/mer
Round-trips: 1   Artifacts sent: 2  received: 0
Sync done, wire bytes sent: 4206  received: 308  ip: 5.161.138.46

c:/my/path $ fossil timeline -n 1
=== 2022-11-07 ===
18:39:38 [092b3d5d04] *CURRENT* Naivet‚. (user: mer tags: trunk)
--- entry limit (1) reached ---

So the accented letter came out as a comma and a period.

> > > I think I found a bug in Eshell that the above workaround should
> > > side-step.
> >
> > I've now installed a change for Emacs 29 that I think should fix your
> > problems.  So if you can try the current master branch of the Emacs
> > Git repository, please do, and see if your problem with Fossil are
> > solved there.

I'm not sure which is "Emacs 29".  I took the master branch

  https://git.savannah.gnu.org/cgit/emacs.git/

right now --- November 7th, 15h EST --- and followed nt/INSTALL.W64 to
compile it using MSYS32 in a MINGW64 shell.  After building the
runemacs.exe, I ran it with the option -Q and I see the version is

  GNU Emacs 29.0.50 (build 1, x86_64-w64-mingw32) of 2022-11-07

I get the following behavior:

c:/my/path $ fossil commit -m 'Naiveté.'
Pull from https://mer@somewhere.edu/mer
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, wire bytes sent: 438  received: 3908  ip: 5.161.138.46
New_Version: e3d8a268759a5e968f132043404eecb4ea5068135fcebd0d35b6b668eb8404a2
Sync with https://mer@somewhere.edu/mer
Round-trips: 1   Artifacts sent: 2  received: 0
Sync done, wire bytes sent: 4297  received: 309  ip: 5.161.138.46
c:/my/path $ fossil timeline -n 1
=== 2022-11-07 ===
19:29:10 [e3d8a26875] *CURRENT* Naiveté. (user: mer tags: trunk)
--- entry limit (1) reached ---

As a second try, I'm going to set the variable
default-process-coding-system as you suggested above and try again,
restarting the GNU EMACS first --- just in case. Restarted, ran ESHELL
and...

c:/my/path $ (print default-process-coding-system)
(undecided-dos . undecided-unix)

c:/my/path $ (setq default-process-coding-system '(undecided-dos . cp850-dos))
(undecided-dos . cp850-dos)

c:/my/path $ (print default-process-coding-system)
(undecided-dos . cp850-dos)
c:/my/path $ # it's set

c:/my/path $ fossil commit -m 'Naiveté.'
Pull from https://mer@somewhere.edu/mer
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, wire bytes sent: 440  received: 3984  ip: 5.161.138.46
New_Version: c51f1ff698f2964f2f06b7e4ca1ae672fb12f6e3e0599f616ff24658930185d2
Sync with https://mer@somewhere.edu/mer
Round-trips: 1   Artifacts sent: 2  received: 0
Sync done, wire bytes sent: 4341  received: 309  ip: 5.161.138.46

c:/my/path $ fossil timeline -n 1
=== 2022-11-07 ===
19:35:10 [c51f1ff698] *CURRENT* Naiveté. (user: mer tags: trunk)
--- entry limit (1) reached ---

It seems to me we get the same result.  Thank you.  I can test and
retest this.  Just let me know.  It will be easier for me now because
I already have all that it takes to compile the GNU EMACS here.  Thank
you.

bug#58281: 27.1; windows mangles encoding on command line

[Eli Zaretskii]

> From: Daniel Bastos <dbastos@id.uff.br>
> Date: Mon, 7 Nov 2022 16:40:04 -0300
> Cc: 58281@debbugs.gnu.org
> 
> > > I've now installed a change for Emacs 29 that I think should fix your
> > > problems.  So if you can try the current master branch of the Emacs
> > > Git repository, please do, and see if your problem with Fossil are
> > > solved there.
> 
> I'm not sure which is "Emacs 29".  I took the master branch
> 
>   https://git.savannah.gnu.org/cgit/emacs.git/
> 
> right now --- November 7th, 15h EST --- and followed nt/INSTALL.W64 to
> compile it using MSYS32 in a MINGW64 shell.  After building the
> runemacs.exe, I ran it with the option -Q and I see the version is
> 
>   GNU Emacs 29.0.50 (build 1, x86_64-w64-mingw32) of 2022-11-07
> 
> I get the following behavior:
> 
> c:/my/path $ fossil commit -m 'Naiveté.'
> Pull from https://mer@somewhere.edu/mer
> Round-trips: 1   Artifacts sent: 0  received: 0
> Pull done, wire bytes sent: 438  received: 3908  ip: 5.161.138.46
> New_Version: e3d8a268759a5e968f132043404eecb4ea5068135fcebd0d35b6b668eb8404a2
> Sync with https://mer@somewhere.edu/mer
> Round-trips: 1   Artifacts sent: 2  received: 0
> Sync done, wire bytes sent: 4297  received: 309  ip: 5.161.138.46
> c:/my/path $ fossil timeline -n 1
> === 2022-11-07 ===
> 19:29:10 [e3d8a26875] *CURRENT* Naiveté. (user: mer tags: trunk)

What do you see if you run "fossil timeline -n 1" from the shell
outside of Emacs? does it show "Naiveté" as expected?  If it does,
then what you see above is a secondary and much less serious problem;
the repository is OK.

If that doesn't work, then I can only say that I tested this change
with a program other than fossil, assuming fossil uses the system
codepage.  It worked for me with that other program: any text I wrote
on the command line was received and processed by the program as I
expected.  Maybe fossil doesn't use the system codepage, in which case
it doesn't play by the rules of a Windows console program, and I don't
know what else we could do with this.  Sorry.

bug#58281: 27.1; windows mangles encoding on command line

[Eli Zaretskii]

> From: Daniel Bastos <dbastos@id.uff.br>
> Date: Mon, 7 Nov 2022 16:40:04 -0300
> Cc: 58281@debbugs.gnu.org
> 
> > > I've now installed a change for Emacs 29 that I think should fix your
> > > problems.  So if you can try the current master branch of the Emacs
> > > Git repository, please do, and see if your problem with Fossil are
> > > solved there.
> 
> I'm not sure which is "Emacs 29".  I took the master branch
> 
>   https://git.savannah.gnu.org/cgit/emacs.git/
> 
> right now --- November 7th, 15h EST --- and followed nt/INSTALL.W64 to
> compile it using MSYS32 in a MINGW64 shell.  After building the
> runemacs.exe, I ran it with the option -Q and I see the version is
> 
>   GNU Emacs 29.0.50 (build 1, x86_64-w64-mingw32) of 2022-11-07
> 
> I get the following behavior:

Btw, what is the value of locale-coding-system in this case for you in
Emacs 29?

bug#58281: 27.1; windows mangles encoding on command line

[Daniel Bastos]

On Mon, Nov 7, 2022 at 5:10 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Daniel Bastos <dbastos@id.uff.br>
> > Date: Mon, 7 Nov 2022 16:40:04 -0300
> > Cc: 58281@debbugs.gnu.org
> >
> > > > I've now installed a change for Emacs 29 that I think should fix your
> > > > problems.  So if you can try the current master branch of the Emacs
> > > > Git repository, please do, and see if your problem with Fossil are
> > > > solved there.
> >
> > I'm not sure which is "Emacs 29".  I took the master branch
> >
> >   https://git.savannah.gnu.org/cgit/emacs.git/
> >
> > right now --- November 7th, 15h EST --- and followed nt/INSTALL.W64 to
> > compile it using MSYS32 in a MINGW64 shell.  After building the
> > runemacs.exe, I ran it with the option -Q and I see the version is
> >
> >   GNU Emacs 29.0.50 (build 1, x86_64-w64-mingw32) of 2022-11-07
> >
> > I get the following behavior:
> >
> > c:/my/path $ fossil commit -m 'Naiveté.'
> > Pull from https://mer@somewhere.edu/mer
> > Round-trips: 1   Artifacts sent: 0  received: 0
> > Pull done, wire bytes sent: 438  received: 3908  ip: 5.161.138.46
> > New_Version: e3d8a268759a5e968f132043404eecb4ea5068135fcebd0d35b6b668eb8404a2
> > Sync with https://mer@somewhere.edu/mer
> > Round-trips: 1   Artifacts sent: 2  received: 0
> > Sync done, wire bytes sent: 4297  received: 309  ip: 5.161.138.46
> > c:/my/path $ fossil timeline -n 1
> > === 2022-11-07 ===
> > 19:29:10 [e3d8a26875] *CURRENT* Naiveté. (user: mer tags: trunk)
>
> What do you see if you run "fossil timeline -n 1" from the shell
> outside of Emacs? does it show "Naiveté" as expected?  If it does,
> then what you see above is a secondary and much less serious problem;
> the repository is OK.

Great.  I see it correctly when I run "fossil timeline -n 1" from the
shell outside of Emacs.

C:\my\path>fossil timeline -n 1
=== 2022-11-07 ===
19:35:10 [c51f1ff698] *CURRENT* Naiveté. (user: mer tags: trunk)
--- entry limit (1) reached ---

[...]

bug#58281: 27.1; windows mangles encoding on command line

[Daniel Bastos]

On Mon, Nov 7, 2022 at 5:24 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Daniel Bastos <dbastos@id.uff.br>
> > Date: Mon, 7 Nov 2022 16:40:04 -0300
> > Cc: 58281@debbugs.gnu.org
> >
> > > > I've now installed a change for Emacs 29 that I think should fix your
> > > > problems.  So if you can try the current master branch of the Emacs
> > > > Git repository, please do, and see if your problem with Fossil are
> > > > solved there.
> >
> > I'm not sure which is "Emacs 29".  I took the master branch
> >
> >   https://git.savannah.gnu.org/cgit/emacs.git/
> >
> > right now --- November 7th, 15h EST --- and followed nt/INSTALL.W64 to
> > compile it using MSYS32 in a MINGW64 shell.  After building the
> > runemacs.exe, I ran it with the option -Q and I see the version is
> >
> >   GNU Emacs 29.0.50 (build 1, x86_64-w64-mingw32) of 2022-11-07
> >
> > I get the following behavior:
>
> Btw, what is the value of locale-coding-system in this case for you in
> Emacs 29?

On *scratch*, I say

  locale-coding-system C-u M-x eval-last-sexp

and I get

  cp1252

I did something similar while in ESHELL and I got the same cp1252.

bug#58281: 27.1; windows mangles encoding on command line

[Eli Zaretskii]

> From: Daniel Bastos <dbastos@id.uff.br>
> Date: Mon, 7 Nov 2022 19:38:35 -0300
> Cc: 58281@debbugs.gnu.org
> 
> > > 19:29:10 [e3d8a26875] *CURRENT* Naiveté. (user: mer tags: trunk)
> >
> > What do you see if you run "fossil timeline -n 1" from the shell
> > outside of Emacs? does it show "Naiveté" as expected?  If it does,
> > then what you see above is a secondary and much less serious problem;
> > the repository is OK.
> 
> Great.  I see it correctly when I run "fossil timeline -n 1" from the
> shell outside of Emacs.
> 
> C:\my\path>fossil timeline -n 1
> === 2022-11-07 ===
> 19:35:10 [c51f1ff698] *CURRENT* Naiveté. (user: mer tags: trunk)
> --- entry limit (1) reached ---

OK, so this means the solution "mostly" works, and the fact that you
see it garbled in Eshell is some kind of display problem.  Although I
don't understand why it happens; it looks like fossil for some reason
outputs UTF-8 encoded text.  Do you have some customization, either in
Emacs or in fossil, which could cause that?

bug#58281: 27.1; windows mangles encoding on command line

[Eli Zaretskii]

> From: Daniel Bastos <dbastos@id.uff.br>
> Date: Mon, 7 Nov 2022 19:42:32 -0300
> Cc: 58281@debbugs.gnu.org
> 
> On Mon, Nov 7, 2022 at 5:24 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: Daniel Bastos <dbastos@id.uff.br>
> > > Date: Mon, 7 Nov 2022 16:40:04 -0300
> > > Cc: 58281@debbugs.gnu.org
> > >
> > > > > I've now installed a change for Emacs 29 that I think should fix your
> > > > > problems.  So if you can try the current master branch of the Emacs
> > > > > Git repository, please do, and see if your problem with Fossil are
> > > > > solved there.
> > >
> > > I'm not sure which is "Emacs 29".  I took the master branch
> > >
> > >   https://git.savannah.gnu.org/cgit/emacs.git/
> > >
> > > right now --- November 7th, 15h EST --- and followed nt/INSTALL.W64 to
> > > compile it using MSYS32 in a MINGW64 shell.  After building the
> > > runemacs.exe, I ran it with the option -Q and I see the version is
> > >
> > >   GNU Emacs 29.0.50 (build 1, x86_64-w64-mingw32) of 2022-11-07
> > >
> > > I get the following behavior:
> >
> > Btw, what is the value of locale-coding-system in this case for you in
> > Emacs 29?
> 
> On *scratch*, I say
> 
>   locale-coding-system C-u M-x eval-last-sexp
> 
> and I get
> 
>   cp1252
> 
> I did something similar while in ESHELL and I got the same cp1252.

This is the expected value, so everything seems to work as I intended.

bug#58281: 27.1; windows mangles encoding on command line

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Daniel Bastos <dbastos@id.uff.br>
>> Date: Mon, 7 Nov 2022 19:38:35 -0300
>> Cc: 58281@debbugs.gnu.org
>>
>> > > 19:29:10 [e3d8a26875] *CURRENT* Naiveté. (user: mer tags: trunk)
>> >
>> > What do you see if you run "fossil timeline -n 1" from the shell
>> > outside of Emacs? does it show "Naiveté" as expected?  If it does,
>> > then what you see above is a secondary and much less serious problem;
>> > the repository is OK.
>>
>> Great.  I see it correctly when I run "fossil timeline -n 1" from the
>> shell outside of Emacs.
>>
>> C:\my\path>fossil timeline -n 1
>> === 2022-11-07 ===
>> 19:35:10 [c51f1ff698] *CURRENT* Naiveté. (user: mer tags: trunk)
>> --- entry limit (1) reached ---
>
> OK, so this means the solution "mostly" works, and the fact that you
> see it garbled in Eshell is some kind of display problem.  Although I
> don't understand why it happens; it looks like fossil for some reason
> outputs UTF-8 encoded text.  Do you have some customization, either in
> Emacs or in fossil, which could cause that?

No further updates within 9 months.  Eli made some fixes, that seems to
have improved the situation.  It also seems like the fault here
ultimately was with a program called "fossil", and not with Emacs.

I'm therefore going to assume that there's nothing more we can do here,
and I'm therefore closing this bug report.  If this conclusion is
incorrect, please reply to this email (use "Reply to all" in your email
client) and we can reopen the bug report.