Re: Friendlier dired experience [CODE INCLUDED]

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 5 Nov 2020 03:54:40 -0500
> From: Boruch Baum <boruch_baum@gmx.com>
> Cc: Stefan Kangas <stefankangas@gmail.com>, Jean Louis <bugs@gnu.support>,
>  Emacs-Devel List <emacs-devel@gnu.org>
> 
> > I believe you must unhexlify the path in the .trashinfo. This is not
> > only because of Tramp. A local file "/tmp/file with space", trashed via
> > "M-x move-file-to-trash", has the entry
> >
> > Path=/tmp/file%20with%20space
> >
> > Calling "M-x diredc-trash-restore" restores it to "/tmp/file%20with%20space".
> 
> I was surprised that this turned out so difficult for me to do. The very
> simple case for 8-bit ascii was easily handled by unhexlifying, but that
> simple case got me thinking about unicode file names. Sure enough, the
> trash meta-data for such file names are also hex encoded, but the
> standard elisp commands I could find wouldn't handle them. Have I
> overlooked something? The following code snippet performs two alternate
> techniques (url-unhex-string, stolen-from-emacs-w3m-url-decode-string)
> first for a simple case of a file name with an embedded space, and then
> on a unicode file name. Only the function shamelessly stolen from the
> emacs-w3m package worked for both cases. Tell me I've overlooked
> something, please.

I'm not sure I understand exactly what you are trying to do, so what I
suggest below may not make sense.  But if I did understand, then the
dance with temporary buffer shouldn't be required; the below should
work (and does work with your 2 examples, assuming your file names are
encoded in UTF-8):

  (decode-coding-string
     (url-unhex-string STRING)
     (or file-name-coding-system
         (default-value 'file-name-coding-system)))