From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Buffer names with R2L characters Date: Tue, 21 Jun 2011 21:10:54 +0300 Message-ID: <83vcvzukb5.fsf@gnu.org> References: <838vswwk2b.fsf@gnu.org> <201106211652.p5LGqIGr016636@beta.mvs.co.il> <83wrgfumh7.fsf@gnu.org> <201106211759.p5LHxpiT008325@beta.mvs.co.il> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1308683155 16960 80.91.229.12 (21 Jun 2011 19:05:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 21 Jun 2011 19:05:55 +0000 (UTC) Cc: stephen@xemacs.org, miles@gnu.org, monnier@iro.umontreal.ca, cloos@jhcloos.com, emacs-devel@gnu.org To: ehud@unix.mvs.co.il Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 21 21:05:50 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 1QZ6Gj-0000cs-Nx for ged-emacs-devel@m.gmane.org; Tue, 21 Jun 2011 21:05:49 +0200 Original-Received: from localhost ([::1]:41977 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ6Gi-0007Oz-DO for ged-emacs-devel@m.gmane.org; Tue, 21 Jun 2011 15:05:48 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:39848) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ5Pe-00086K-MC for emacs-devel@gnu.org; Tue, 21 Jun 2011 14:10:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QZ5Pd-0003RR-99 for emacs-devel@gnu.org; Tue, 21 Jun 2011 14:10:58 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:38729) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ5Pc-0003RE-Ry; Tue, 21 Jun 2011 14:10:57 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LN500E00JTBJ000@a-mtaout23.012.net.il>; Tue, 21 Jun 2011 21:10:55 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.124.66.211]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LN500EOKJU5IK10@a-mtaout23.012.net.il>; Tue, 21 Jun 2011 21:10:55 +0300 (IDT) In-reply-to: <201106211759.p5LHxpiT008325@beta.mvs.co.il> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.175 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:140794 Archived-At: > Date: Tue, 21 Jun 2011 20:59:51 +0300 > From: "Ehud Karni" > Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, cloos@jhcloos.com, > stephen@xemacs.org, miles@gnu.org > > 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. Patches are welcome. > > 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. The "never saved" part might need some new infrastructure, because the only one we have -- overlays -- does not affect reordering. Another idea would be to cover the real string with an overlay with display property that is a string computed from the covered text, and put the directional formatting codes in that display string. > May be use the "virtual" LRM/RLM only on non saved text (like the > mode-line, dired buffer and so on). Dired buffer can be saved, e.g. by write-region etc. Note that these decorations will have to be used in various additional places, like the prompt displayed by read-buffer ("(defalt FOOBAR)"), for example. > > > 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. I think it's gross, but I won't object to patches to that effect.