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

Full log


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)]

This bug report was last modified 13 days ago.

Previous Next


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