Re: fixing url-unhex-string for unicode/multi-byte charsets

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 6 Nov 2020 05:27:56 -0500
> From: Boruch Baum <boruch_baum@gmx.com>
> Cc: emacs-devel@gnu.org
> 
> > I made a suggestion in that discussion, I will repeat some of them
> > here:
> 
> Yeah, but they don't work.

I said "something like that", because I don't know the full context.
If "don't work" means "needs minor adaptations", the suggestions are
still valid.

> > So, for file names, something like the below should do the job
> > simpler:
> >
> >   (decode-coding-string (url-unhex-string STR)
> >                         (or file-name-coding-system
> > 			    (default-value 'file-name-coding-system)))
> 
> Try it.

I can't, not in full: I don't have a Freedesktop trash anywhere I have
access to.  I did try the 2 file names you posted, including the one
with Hebrew characters, and it did work for me, on the assumption that
file-name-coding-system is UTF-8.

> To reproduce, touch and then trash a file named some two Hebrew
> words delimited by a space. Navigate to the trash directory's 'info'
> sub-directory and extract the 'path' value from the file's meta-data
> .info file. That's the string we need to decode. Apply the string to
> your solution and see that you do not get the space-delimited two
> Hebrew words.

A stand-alone test case, which doesn't require an actual trash, would
be appreciated, so I could see which parrt doesn't work, and how to
fix it.

Alternatively, maybe you could explain why you needed to insert the
text into a temporary buffer and then extract it from there?  AFAIK,
we have the same primitives that work on decoding strings as we have
for decoding buffer text.