GNU bug report logs -
#77994
30.1; Yanking paths or Kanji from Windows produces incorrect behaviour for pgtk build on WSL2
Previous Next
Full log
Message #11 received at 77994 <at> debbugs.gnu.org (full text, mbox):
[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 13 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.