From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel,gmane.comp.gnu.core-utils.bugs Subject: Re: dired doesn't work properly with a multibyte locale Date: Mon, 3 Feb 2003 20:17:36 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200302031117.UAA25007@etlken.m17n.org> References: <200301151043.TAA09856@etlken.m17n.org> <200301230602.PAA07755@etlken.m17n.org> <200301250049.JAA11674@etlken.m17n.org> <200301270501.OAA14427@etlken.m17n.org> <200301271109.UAA14818@etlken.m17n.org> <200302030017.JAA24252@etlken.m17n.org> <200302030211.LAA24365@etlken.m17n.org> <200302030840.RAA24766@etlken.m17n.org> <200302030910.SAA24834@etlken.m17n.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1044271218 26806 80.91.224.249 (3 Feb 2003 11:20:18 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 3 Feb 2003 11:20:18 +0000 (UTC) Cc: miles@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18fee2-0006xx-00 for ; Mon, 03 Feb 2003 12:20:10 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18felb-0006Zt-00 for ; Mon, 03 Feb 2003 12:28:00 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18feem-0000EZ-03 for emacs-devel@quimby.gnus.org; Mon, 03 Feb 2003 06:20:56 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18fee6-0008HR-00 for emacs-devel@gnu.org; Mon, 03 Feb 2003 06:20:14 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18fedd-0007js-00 for emacs-devel@gnu.org; Mon, 03 Feb 2003 06:19:46 -0500 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18fedJ-00077g-00; Mon, 03 Feb 2003 06:19:26 -0500 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2])h13BHak14715; Mon, 3 Feb 2003 20:17:36 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) h13BHaR26271; Mon, 3 Feb 2003 20:17:36 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id UAA25007; Mon, 3 Feb 2003 20:17:36 +0900 (JST) Original-To: schwab@suse.de In-reply-to: (message from Andreas Schwab on Mon, 03 Feb 2003 12:00:09 +0100) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.2.92 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) Original-cc: d.love@dl.ac.uk Original-cc: bug-coreutils@gnu.org Original-cc: emacs-pretest-bug@gnu.org Original-cc: emacs-devel@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:11309 gmane.comp.gnu.core-utils.bugs:104 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:11309 Andreas Schwab writes: > |> Really? I thought ls's output counts columns, thus, for > |> instnace, the filename "=C0" is counted as 1, not 2. > |> Otherwise, the current dired should work well. > The dired offsets are explicitly documented as counting bytes, *note > (coreutils)What information is listed::. Ah, yes, I know that. What I meant was "that buggy ls's output counts columns". Miles Bader writes: > You seem to be correct, if I create that file, then `ls --dired' says > it has a lengh of 1, but of course, it actually has a length of 2 bytes. Ok. Then what should we do? I think checking version of ls is too kludgy. Please try this workaround. It avoids setting `dired-filename' property if the next character of filename is not a newline. I think it detects the problem of "ls" in most cases by a low cost. --- Ken'ichi HANDA handa@m17n.org *** files.el.~1.632.~ 2003-02-01 00:16:47.000000000 +0900 --- files.el 2003-02-03 20:03:30.000000000 +0900 *************** *** 4106,4112 **** (while (< (point) end) (let ((start (+ beg (read (current-buffer)))) (end (+ beg (read (current-buffer))))) ! (put-text-property start end 'dired-filename t))) (goto-char end) (beginning-of-line) (delete-region (point) (progn (forward-line 2) (point))))) --- 4106,4117 ---- (while (< (point) end) (let ((start (+ beg (read (current-buffer)))) (end (+ beg (read (current-buffer))))) ! (if (=3D (char-after end) ?\n) ! (put-text-property start end 'dired-filename t) ! ;; It seems that we can't trust ls's output as to ! ;; byte positions of filenames. ! (put-text-property beg (point) 'dired-filename nil) ! (end-of-line)))) (goto-char end) (beginning-of-line) (delete-region (point) (progn (forward-line 2) (point)))))