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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Then why not encode in UTF-8, for example?

How about (or file-name-coding-system default-file-name-coding-system)
instead?  AFAICT, that's what ENCODE_FILE does.

> If some program other than Emacs is the target of the drop, raw bytes
> produced from raw-text will not be meaningful for it.

Why not?  Aren't those bytes equivalent to a C string describing a file
name that can be passed to `open'?

I wrote that code according to how C_STRINGs are already encoded in
select.el:

           ((eq type 'C_STRING)
            ;; According to ICCCM Protocol v2.0 (para 2.7.1), C_STRING
            ;; is a zero-terminated sequence of raw bytes that
            ;; shouldn't be interpreted as text in any encoding.
            ;; Therefore, if STR is unibyte (the normal case), we use
            ;; it as-is; otherwise we assume some of the characters
            ;; are eight-bit and ensure they are converted to their
            ;; single-byte representation.
            (or (null (multibyte-string-p str))
                (setq str (encode-coding-string str 'raw-text-unix))))

> I actually don't understand why you don't use ENCODE_FILE for files
> and ENCODE_SYSTEM for everything else -- this is the only encoding
> which we know to be generally suitable for any operation that calls
> low-level C APIs whose implementation is not in Emacs.  Bonus points
> for adhering to selection-coding-system when that is non-nil.
>
> Are there any known problems with using these two system encodings in
> this case?

Yes: the entire selection mechanism is implemented in Lisp, and moving
parts to C specifically would require some rethinking of the C code
involved, and wouldn't be backwards-compatible.

The FILE_NAME target has existed for decades in Lisp for programs that
comply with the ICCCM and also deals with all kinds of file name
encodings (see the call to `xselect--encode-string' in
`xselect-convert-to-filename'), so I don't see why this code cannot.