From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Buffer names with R2L characters Date: Wed, 22 Jun 2011 18:27:14 -0400 Message-ID: References: <838vswwk2b.fsf@gnu.org> <201106211652.p5LGqIGr016636@beta.mvs.co.il> <83wrgfumh7.fsf@gnu.org> <201106211759.p5LHxpiT008325@beta.mvs.co.il> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1308781661 26429 80.91.229.12 (22 Jun 2011 22:27:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 22 Jun 2011 22:27:41 +0000 (UTC) Cc: eliz@gnu.org, miles@gnu.org, stephen@xemacs.org, 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 Thu Jun 23 00:27:36 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 1QZVtY-0000YU-33 for ged-emacs-devel@m.gmane.org; Thu, 23 Jun 2011 00:27:36 +0200 Original-Received: from localhost ([::1]:46389 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZVtW-00012v-Rk for ged-emacs-devel@m.gmane.org; Wed, 22 Jun 2011 18:27:34 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:38128) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZVtG-00012n-Ub for emacs-devel@gnu.org; Wed, 22 Jun 2011 18:27:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QZVtF-0002zV-Vj for emacs-devel@gnu.org; Wed, 22 Jun 2011 18:27:18 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:47414 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZVtE-0002zD-I6; Wed, 22 Jun 2011 18:27:16 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIHANhrAk5FxLeu/2dsb2JhbABSmEWOVniIc8Brhi0EnWyEJg X-IronPort-AV: E=Sophos;i="4.65,408,1304308800"; d="scan'208";a="116950827" Original-Received: from 69-196-183-174.dsl.teksavvy.com (HELO pastel.home) ([69.196.183.174]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 22 Jun 2011 18:27:14 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 85FF458EC9; Wed, 22 Jun 2011 18:27:14 -0400 (EDT) In-Reply-To: <201106211759.p5LHxpiT008325@beta.mvs.co.il> (Ehud Karni's message of "Tue, 21 Jun 2011 20:59:51 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:140888 Archived-At: > 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. That might be a good idea. At least it would let us encapsulate the solution to the problem, so we can change it later on. >> 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). Maybe another way to attack the problem is to say that the < and the > in that string are not neutral but "weak L2R" or something like that. Maybe this would also work for XML markup. We could specify such a thing via some char-table overriding the default bidi properties of specified chars. We would either need to be able to set this as a text-property over the "", or to have one for the mode-line. >> > 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. Indeed, for the buffer names it seems perfectly acceptable since we generate them ourselves and they don't go very far. I'm not sure why Eli doesn't like this solution. Stefan