GNU bug report logs - #77994
30.1; Yanking paths or Kanji from Windows produces incorrect behaviour for pgtk build on WSL2

Previous Next

Package: emacs;

Reported by: Tim Jim <redemptiontea <at> gmail.com>

Date: Tue, 22 Apr 2025 17:26:02 UTC

Severity: normal

Found in version 30.1

To reply to this bug, email your comments to 77994 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#77994; Package emacs. (Tue, 22 Apr 2025 17:26:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tim Jim <redemptiontea <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Tue, 22 Apr 2025 17:26:03 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tim Jim <redemptiontea <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.1; Yanking paths or Kanji from Windows produces incorrect
 behaviour for pgtk build on WSL2
Date: Wed, 23 Apr 2025 01:12:15 +0900
[Message part 1 (text/plain, inline)]
Dear Dev Team,

I've compiled Emacs 30.1 on AlmaLinux 9 running in WSL2 with pgtk; as per
the subject, I'm seeing two separate bugs(?), I think.

I ran a quick comparison using `emacs -Q`, for Emacs compiled with and
without `--with-pgtk`.

1. When pasting a path copied from the address bar from Windows Explorer
into an Emacs buffer, the path is usually followed by a bunch of null
characters, such as ^@ and ^A. Based on my searching, this could be an
encoding issue, but I could not find an encoding setting which solves this.

2. Pasting in any Kanji will result in ???? appearing instead of the
characters. I can confirm that if I type in Japanese directly into the
buffer, it shows up fine. Just to check it wasn't a GTK on WSL problem, I
also fired up a gedit session and could successfully paste in the Kanji
there.

Both problems went away when I compiled without `--with-pgtk`. I.e. I could
paste in paths without extra null characters appearing and could paste in
Kanji successfully.

I'm unsure if this is a bug, or if it's a difference in how system
environmental variables are handled. Please could you give me some pointers
on how/if this can be resolved?

Thanks for all your efforts supporting and developing Emacs!

P.S. as a quick addendum to point 1, I had also posted an earlier variation
of the question that also included an issue that did turn out to be an
encoding issue (trying to paste a degree symbol). That part was solved
using `(setq selection-coding-system nil)`, but the path issue remained, so
I suspected it might be a different problem.
https://www.reddit.com/r/emacs/s/6w1L3CiyAU

If there is anything else I can add to help debug this please let me know.
Also, apologies if this is something obvious that I've missed in the
manual. I tried searching the bug tracker too for anything WSL-specific,
but I didn't see anything immediately relevant.

Regards,
Tim

Here's the build info:

In GNU Emacs 30.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.31,
 cairo version 1.17.4) of 2025-04-14 built on alma-1
Repository revision: 8ac894e2246f25d2a2a97d866b10e6e0b0fede5a
Repository branch: HEAD
System Description: AlmaLinux 9.5 (Teal Serval)

Configured using:
 'configure --prefix=/opt/emacs/emacs-30.1 'CFLAGS=-O0 -g3
 -march=native' --with-native-compilation --with-imagemagick
 --with-libsystemd --with-tree-sitter --with-pgtk'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
IMAGEMAGICK JPEG LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB

Important settings:
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/pgtk-win pgtk-win term/common-win touch-screen pgtk-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine 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 emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk pgtk
multi-tty move-toolbar make-network-process native-compile emacs)

Memory information:
((conses 16 49099 9416) (symbols 48 5333 0) (strings 32 13223 2649)
 (string-bytes 1 386103) (vectors 16 8669)
 (vector-slots 8 123257 9667) (floats 8 23 1) (intervals 56 373 21)
 (buffers 992 11))
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#77994; Package emacs. (Wed, 23 Apr 2025 11:40:04 GMT) Full text and rfc822 format available.

Message #8 received at 77994 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tim Jim <redemptiontea <at> gmail.com>, Po Lu <luangruo <at> yahoo.com>
Cc: 77994 <at> debbugs.gnu.org
Subject: Re: bug#77994: 30.1;
 Yanking paths or Kanji from Windows produces incorrect behaviour for
 pgtk build on WSL2
Date: Wed, 23 Apr 2025 14:39:31 +0300
> From: Tim Jim <redemptiontea <at> gmail.com>
> Date: Wed, 23 Apr 2025 01:12:15 +0900
> 
> I've compiled Emacs 30.1 on AlmaLinux 9 running in WSL2 with pgtk; as per the subject, I'm seeing two
> separate bugs(?), I think. 
> 
> I ran a quick comparison using `emacs -Q`, for Emacs compiled with and without `--with-pgtk`.
> 
> 1. When pasting a path copied from the address bar from Windows Explorer into an Emacs buffer, the path
> is usually followed by a bunch of null characters, such as ^@ and ^A. Based on my searching, this could be
> an encoding issue, but I could not find an encoding setting which solves this. 
> 
> 2. Pasting in any Kanji will result in ???? appearing instead of the characters. I can confirm that if I type in
> Japanese directly into the buffer, it shows up fine. Just to check it wasn't a GTK on WSL problem, I also fired
> up a gedit session and could successfully paste in the Kanji there.
> 
> Both problems went away when I compiled without `--with-pgtk`. I.e. I could paste in paths without extra null
> characters appearing and could paste in Kanji successfully.
> 
> I'm unsure if this is a bug, or if it's a difference in how system environmental variables are handled. Please
> could you give me some pointers on how/if this can be resolved? 
> 
> Thanks for all your efforts supporting and developing Emacs!
> 
> P.S. as a quick addendum to point 1, I had also posted an earlier variation of the question that also included
> an issue that did turn out to be an encoding issue (trying to paste a degree symbol). That part was solved
> using `(setq selection-coding-system nil)`, but the path issue remained, so I suspected it might be a different
> problem. https://www.reddit.com/r/emacs/s/6w1L3CiyAU
> 
> If there is anything else I can add to help debug this please let me know. Also, apologies if this is something
> obvious that I've missed in the manual. I tried searching the bug tracker too for anything WSL-specific, but I
> didn't see anything immediately relevant. 

Thanks.

We don't have experts on board who know how WSL2 works wrt
interoperability between Windows and Ubuntu, so what GTK does in that
case is a mystery to us, I think.  I've added Po Lu to the discussion
in the hope that he might have some suggestions.

I personally have only one idea: try

  C-x RET x utf-16-le RET

and see if this fixes the problems you see.

I suspect that WSL2 has some customization options which control how
the Windows clipboard is presented to GNU/Linux programs running in
Ubuntu.

Or maybe you need something to be installed, like xclip or
wl-clipboard.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#77994; Package emacs. (Wed, 23 Apr 2025 15:26:02 GMT) Full text and rfc822 format available.

Message #11 received at 77994 <at> debbugs.gnu.org (full text, mbox):

From: Tim Jim <redemptiontea <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Po Lu <luangruo <at> yahoo.com>, 77994 <at> debbugs.gnu.org
Subject: Re: bug#77994: 30.1; Yanking paths or Kanji from Windows produces
 incorrect behaviour for pgtk build on WSL2
Date: Wed, 23 Apr 2025 23:26:25 +0900
[Message part 1 (text/plain, inline)]
Dear Eli,

Thank you for the tips! I did try setting the encoding to utf-16-le (and a
few others for testing) but it just resulted in even more of the pasted
path becoming even more garbled.

I'm not sure why, but when running Emacs compiled without pgtk, the default
recording seems to handle the paste with no issues. Does the pgtk version
handle clipboard contents differently?

Also just to clarify, I want running Ubuntu but AlmaLinux (so closer to
Fedora/RHEL) - I think you might still be right though; it's probably
something missing rather than the exact distro causing issues.

Thank you for the ideas so far!

On Wed, 23 Apr 2025, 20:39 Eli Zaretskii, <eliz <at> gnu.org> wrote:

> > From: Tim Jim <redemptiontea <at> gmail.com>
> > Date: Wed, 23 Apr 2025 01:12:15 +0900
> >
> > I've compiled Emacs 30.1 on AlmaLinux 9 running in WSL2 with pgtk; as
> per the subject, I'm seeing two
> > separate bugs(?), I think.
> >
> > I ran a quick comparison using `emacs -Q`, for Emacs compiled with and
> without `--with-pgtk`.
> >
> > 1. When pasting a path copied from the address bar from Windows Explorer
> into an Emacs buffer, the path
> > is usually followed by a bunch of null characters, such as ^@ and ^A.
> Based on my searching, this could be
> > an encoding issue, but I could not find an encoding setting which solves
> this.
> >
> > 2. Pasting in any Kanji will result in ???? appearing instead of the
> characters. I can confirm that if I type in
> > Japanese directly into the buffer, it shows up fine. Just to check it
> wasn't a GTK on WSL problem, I also fired
> > up a gedit session and could successfully paste in the Kanji there.
> >
> > Both problems went away when I compiled without `--with-pgtk`. I.e. I
> could paste in paths without extra null
> > characters appearing and could paste in Kanji successfully.
> >
> > I'm unsure if this is a bug, or if it's a difference in how system
> environmental variables are handled. Please
> > could you give me some pointers on how/if this can be resolved?
> >
> > Thanks for all your efforts supporting and developing Emacs!
> >
> > P.S. as a quick addendum to point 1, I had also posted an earlier
> variation of the question that also included
> > an issue that did turn out to be an encoding issue (trying to paste a
> degree symbol). That part was solved
> > using `(setq selection-coding-system nil)`, but the path issue remained,
> so I suspected it might be a different
> > problem. https://www.reddit.com/r/emacs/s/6w1L3CiyAU
> >
> > If there is anything else I can add to help debug this please let me
> know. Also, apologies if this is something
> > obvious that I've missed in the manual. I tried searching the bug
> tracker too for anything WSL-specific, but I
> > didn't see anything immediately relevant.
>
> Thanks.
>
> We don't have experts on board who know how WSL2 works wrt
> interoperability between Windows and Ubuntu, so what GTK does in that
> case is a mystery to us, I think.  I've added Po Lu to the discussion
> in the hope that he might have some suggestions.
>
> I personally have only one idea: try
>
>   C-x RET x utf-16-le RET
>
> and see if this fixes the problems you see.
>
> I suspect that WSL2 has some customization options which control how
> the Windows clipboard is presented to GNU/Linux programs running in
> Ubuntu.
>
> Or maybe you need something to be installed, like xclip or
> wl-clipboard.
>
[Message part 2 (text/html, inline)]

This bug report was last modified today.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.