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: Mon, 20 Jun 2011 14:00:34 -0400 Message-ID: References: <838vswwk2b.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1308592869 15394 80.91.229.12 (20 Jun 2011 18:01:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 20 Jun 2011 18:01:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 20 20:01:05 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 1QYimV-0004qN-Vz for ged-emacs-devel@m.gmane.org; Mon, 20 Jun 2011 20:01:04 +0200 Original-Received: from localhost ([::1]:38863 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYimU-00068P-S4 for ged-emacs-devel@m.gmane.org; Mon, 20 Jun 2011 14:01:03 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:35418) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYim7-00066p-Fo for emacs-devel@gnu.org; Mon, 20 Jun 2011 14:00:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QYim6-0003s0-EH for emacs-devel@gnu.org; Mon, 20 Jun 2011 14:00:39 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:36773 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYim4-0003rM-14; Mon, 20 Jun 2011 14:00:36 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJOJ/01FpYrD/2dsb2JhbABTpmF4iHO/aYYqBJ1ZhCI X-IronPort-AV: E=Sophos;i="4.65,395,1304308800"; d="scan'208";a="116700583" Original-Received: from 69-165-138-195.dsl.teksavvy.com (HELO pastel.home) ([69.165.138.195]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 20 Jun 2011 14:00:34 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 403DA59011; Mon, 20 Jun 2011 14:00:34 -0400 (EDT) In-Reply-To: <838vswwk2b.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 20 Jun 2011 19:21:00 +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:140728 Archived-At: > Once I had this half-working, the first thing I tested was visiting > files whose names include R2L characters. It works, but there's one > problem: the "" tails we attach to buffer names to make them > unique. The problem is that the '<' and '>' characters are "other > neutral", or "ON", in the UAX#9 parlance, and so their directionality > depends on the surrounding characters. As result, a buffer name typed > as ABCDEF<2> is displayed in the mode line like this: > 2> FEDCBA> Sounds like the same kind of issue as the one brought up a while ago about bidi+XML (or any other mark up). Another important case is when you use uniquify (in which case the above will happen less frequently since file buffers add the directory info to disambiguate the name, but may be replace by similar problems if the separator between the file and directory part (typically /, or \, or |) doesn't have the "right" bidi behavior). > I verified this with the Unicode Reference Implementation, and there's > no bug in bidi.c: this is the correct reordering according to the > Unicode Bidirectional Algorithm. > appending a suitable character to the end of the string (after the > numeric tail) and making it invisible with text properties. But this Hmm, I would have expected that adding something at the end of the string would not work ("too late"), whereas adding it between "ABCDEF" and "<2>" would have felt very natural to me. I guess it just shows how little I know of bidi, Stefan