From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Ehud Karni" Newsgroups: gmane.emacs.devel Subject: Re: Buffer names with R2L characters Date: Tue, 21 Jun 2011 20:59:51 +0300 Organization: Mivtach-Simon Insurance agencies Message-ID: <201106211759.p5LHxpiT008325@beta.mvs.co.il> References: <838vswwk2b.fsf@gnu.org> <201106211652.p5LGqIGr016636@beta.mvs.co.il> <83wrgfumh7.fsf@gnu.org> Reply-To: ehud@unix.mvs.co.il NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1308684232 23733 80.91.229.12 (21 Jun 2011 19:23:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 21 Jun 2011 19:23:52 +0000 (UTC) Cc: stephen@xemacs.org, miles@gnu.org, monnier@iro.umontreal.ca, cloos@jhcloos.com, emacs-devel@gnu.org To: eliz@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 21 21:23:46 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QZ6Y4-0000zB-Vw for ged-emacs-devel@m.gmane.org; Tue, 21 Jun 2011 21:23:45 +0200 Original-Received: from localhost ([::1]:59031 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ6Y3-0004H6-M6 for ged-emacs-devel@m.gmane.org; Tue, 21 Jun 2011 15:23:43 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:41568) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ5F5-0004vZ-Ph for emacs-devel@gnu.org; Tue, 21 Jun 2011 14:00:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QZ5F3-000159-AI for emacs-devel@gnu.org; Tue, 21 Jun 2011 14:00:03 -0400 Original-Received: from [193.16.147.12] (port=38426 helo=unix.mvs.co.il) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ5F0-00014e-Ju; Tue, 21 Jun 2011 13:59:59 -0400 Original-Received: from beta.mvs.co.il (beta [10.253.0.3]) by unix.mvs.co.il (8.13.8/8.13.7) with ESMTP id p5LHxrYM028637; Tue, 21 Jun 2011 20:59:53 +0300 Original-Received: from beta.mvs.co.il (localhost [127.0.0.1]) by beta.mvs.co.il (8.14.1/8.14.1) with ESMTP id p5LHxrq1008328; Tue, 21 Jun 2011 20:59:53 +0300 Original-Received: (from root@localhost) by beta.mvs.co.il (8.14.1/8.14.1/Submit) id p5LHxpiT008325; Tue, 21 Jun 2011 20:59:51 +0300 In-reply-to: <83wrgfumh7.fsf@gnu.org> (message from Eli Zaretskii on Tue, 21 Jun 2011 20:24:04 +0300) X-Mailer: Emacs 21.3.1 rmail (send-msg 1.109) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 2) X-Received-From: 193.16.147.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:140797 Archived-At: On Tue, 21 Jun 2011 20:24:04 +0300, Eli Zaretskii wrote: > > First, why do we need the LRM at the beginning? The mode line is > formatted with L2R "paragraph direction", so the leading LRM is > unneeded (though won't do any harm). The "*Buffer List*" buffer is > forced to use L2R paragraph direction as well, so the leading LRM is > not needed there as well. The 1st LRM may be unneeded but I will add it any way for the general implementation - any substring that contain R2L character and indented to be used in L2R paragraph will be enclosed on both sides by LRM, so it can be inserted without introducing new problems. I think that we need a new functions, something like R2L-quote and L2R-quote that will produce strings that will not cause problem when used in R2L (or L2R) reading direction. > And second, what do you mean by "zero width"? The current facilities > let me change the LRM display only globally, so I cannot make these > LRM characters zero-width only in the mode line -- they will be > displayed as such in all the buffers and strings. Moreover, I'm not > sure TTYs support zero-width. > > Instead, I propose to make the LRM invisible. This is supported on > all display types. May be we need 2 LRMs (and 2 RLMs), the normal "real" one, which is part of the user text, and a "virtual" one, which is always invisible, ignored by search, and never saved. This will solve many problems, but will create others. May be use the "virtual" LRM/RLM only on non saved text (like the mode-line, dired buffer and so on). > > I think Eli is wrong here. An example will help, a file with the > > (logical) name "/abc/def GHIK/LMNO qrst" when uniquified will appear > > as: "def ONML|KIHG qrst" which is clearly wrong. > > > > My way to solve it is as above, i.e. add zero width LRM on both sides > > of the separator (/ or |) in addition to the enclosing LRMs. > > I think this is beginning to become gross. But it is a general solution that is easily implemented. > > The problem is even greater in `dired' with files that have ALL Hebrew > > names. If you have a Hebrew locale, the date has Hebrew in it (the > > month name) then it has some digits and ":" (all neutrals and weak > > L2R ) and then the file name. The bidi algorithm actually exchange > > the month and file name. > > Yes, Dired (and other similar modes) will "need work" (TM) to give a > plausible display with bidi. Patches are welcome. -- Ehud Karni Tel: +972-3-7966-561 /"\ Mivtach - Simon Fax: +972-3-7976-561 \ / ASCII Ribbon Campaign Insurance agencies (USA) voice mail and X Against HTML Mail http://www.mvs.co.il FAX: 1-815-5509341 / \ GnuPG: 98EA398D Better Safe Than Sorry