Re: master 6011d39b6a: Fix drag-and-drop of files with multibyte filenames

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't think I understand this change.  raw-text basically doesn't do
> any conversion, except if the text includes raw bytes.  Is that the
> problem here, and if so, how come a file name can include raw bytes in
> its name?

Encoding it as `raw-text-unix' is to satisfy the requirement in
xselect.c that strings returned by selection converters must be
unibyte.  IOW, it's the same as

  (string-as-unibyte (expand-file-name value))

except that we can't use `string-as-unibyte', because it's obsolete.

> And what does "Motif expects this to be STRING, but it treats the data
> as a sequence of bytes instead of a Latin-1 string" mean in this
> context?  The difference between raw bytes and Latin-1 strings is only
> meaningful to Emacs; how does Motif distinguish between them?

The selection property type STRING means a Latin-1 string, with some
minor extensions.  See this paragraph under "TEXT Properties" in the
ICCCM:

   STRING as a type or a target specifies the ISO Latin-1 character set
   plus the control characters TAB (octal 11) and NEWLINE (octal
   12). The spacing interpretation of TAB is context dependent. Other
   ASCII control characters are explicitly not included in STRING at the
   present time.

But Motif doesn't comply with the ICCCM meaning of STRING or use the
generic TEXT type when converting a drag-and-drop selection to
FILE_NAME.  It instead expects the type of the selection property to be
STRING, but the data is treated as raw bytes.