From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: master 6011d39b6a: Fix drag-and-drop of files with multibyte filenames Date: Sun, 05 Jun 2022 19:42:49 +0800 Message-ID: <87v8tfz686.fsf@yahoo.com> References: <83r143a2j3.fsf@gnu.org> <87y1ybzaz9.fsf@yahoo.com> <83mter9zbl.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7130"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 05 13:53:21 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nxoor-0001ko-1c for ged-emacs-devel@m.gmane-mx.org; Sun, 05 Jun 2022 13:53:21 +0200 Original-Received: from localhost ([::1]:57406 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nxoop-0001VY-DP for ged-emacs-devel@m.gmane-mx.org; Sun, 05 Jun 2022 07:53:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40944) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nxoet-000560-9Q for emacs-devel@gnu.org; Sun, 05 Jun 2022 07:43:13 -0400 Original-Received: from sonic310-23.consmr.mail.ne1.yahoo.com ([66.163.186.204]:37852) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nxoep-0002sv-M2 for emacs-devel@gnu.org; Sun, 05 Jun 2022 07:43:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654429377; bh=zJfeYinjOP+GKYhFzhtSMniq+schJ1eVIkVZIM9s7F4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=HtN+dWobw+uYa3JHQ3m2BLrBPhS7U8pUnn0wGHRlUXusJ9jGbx02Yj9JYJF1SzcJdRfGjoUOWqoIXfKGgnJPH2Sz/qbRAtseUxELQe41jgzeaATLP06SBLGXnJLaD7VWSoFRymfsVAS3GqVIQXKcmHY0O/QaPSIvQg8HLxe1VW5BVWWqDnhC4hdS7r5MCbNd9cBqYluR+oqvB49UmpjITo5wYRpkgGjbZlTTr+T/EjbVCQxM0bjcG9yvlJbYowzJf+PU5TNe6v49ZHBuCmPYLv1rlpI80SUUP7RY8KniEBHWP4uDZiCpEyihZKon2D/7vhsKsqszsTE2BUtWntjwbg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654429377; bh=w7mzfbu6yPDpyR7O8Y87+FqYhBUbgWG0iS6Okr0UiOg=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=Wa6TGBwmdEO/PIYf6FmB4zw00ldEm/EdZ9eucz8HkkfVGv48F3bpRVPV5dTUA+vgx/kJRYQvyGi09VczWJ4krs7noHttwvK/hOTHNXcnXuqZaippSvSZzvPbdU3Neol8qspXMK24zrgUXAYrAElhh3f2rjew77a7dhmnj/fvY137cib3vOtPj+nYMrGHSfkOsIvYhZP4RuoZ0uruRPHgudWOJmXL/Jg77DZrSB5o57ZH9noi5ssl3D3qHIRIiapZa3crmE6w33SljBsYIVmEgm8FRKYpXCZb2iawrsmco1TNVbIbSWiNfhsWXm9aWo48RGSVL0HoafLiU2oORekHaQ== X-YMail-OSG: rB1ccWAVM1mryNjKgETHi6NN1OQGnywORFZvZV8pvd7cgEuA.1PlwEVDwauJPFG zruaDdO9iQhtewbNgVHiwTgLOSXfS55UtTWQnJFszsD.arwbuHFutySHxqS5MHTzNI4jfFFJprcI kprymXssKTQmHUjMQGZdhCkHpo9n_EnUqs4LTXDof6W_RSeraqWIRdRz_dmqsm_eyXsXneRDkNdc nbv4r4UuNSVpAsc1hh1unhiaFS16lUcmQDZ7xnGjfq3gecBVmWqYtCZ.qUaXfehTS_tMzknDq7O_ QbsSDgt_kf3XeZFDeleJB0oQMPSj.R.MepiTH8fyYwDXOu0kDnYYHKPXw48ffQchJEcLgha26qfG 9taCDCAgFcM2rKbZHHi30Txqr0kkRGrh1EqDVJtpJ140O0WABamWhJk9llahpTou_GbSG.YT.5n. LrpNnpDjjx_x6bdXXJnTQ.PXM4KRhzByhiHLkXk55VYQ1.Aoi3ksM5MmZuMe52j5KSHglnZ9yGJ0 JSDlBuzYyKfc8s5Q_nNNUS5G82wpNaBBgZWTYM3jsz70zyqTbkEdP3TQBnATyT89Y0oN9Z1GNb3T JAu2XWgJ9.heVBNo9lCqMZmPnPBy7ctpLZkzYVWOoXNkFOIl8TN4vPKfPja1UPr7yfZxxp4elMZ1 37lGkBYVJJxonkGMq3gptEGFiewUEXcN_FLBEwExcb8vFgm13aSVIe38EHbdvlM8gfD0F8vf_0n. 7Lu35F58LHqC7pYmRC0UYYpRQQ7lq6B2lf15C2Uss9MbSMHxA9Yq4nfBCP7ygpLFM2TI5KX.bt9x W5DPvTWCBJkPyltDvnBX5yrKYBUfAupwGrk12t25Yn X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Sun, 5 Jun 2022 11:42:57 +0000 Original-Received: by hermes--canary-production-sg3-5f7658c994-7rkj7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7e32205da36fa78003ede7187fd717e7; Sun, 05 Jun 2022 11:42:53 +0000 (UTC) In-Reply-To: <83mter9zbl.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 05 Jun 2022 13:31:10 +0300") X-Mailer: WebService/1.1.20225 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.186.204; envelope-from=luangruo@yahoo.com; helo=sonic310-23.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:290695 Archived-At: Eli Zaretskii 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.