From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Buffer names with R2L characters Date: Tue, 21 Jun 2011 17:44:05 +0900 Message-ID: <87vcvz8tgq.fsf@uwakimon.sk.tsukuba.ac.jp> References: <838vswwk2b.fsf@gnu.org> <834o3kw6qg.fsf@gnu.org> <8762nzajxx.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: dough.gmane.org 1308645895 2280 80.91.229.12 (21 Jun 2011 08:44:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 21 Jun 2011 08:44:55 +0000 (UTC) Cc: cloos@jhcloos.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 21 10:44:49 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 1QYwZj-0002Em-Ux for ged-emacs-devel@m.gmane.org; Tue, 21 Jun 2011 10:44:48 +0200 Original-Received: from localhost ([::1]:54954 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYwZi-0002ZC-OO for ged-emacs-devel@m.gmane.org; Tue, 21 Jun 2011 04:44:46 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:44471) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYwZP-0002Yo-M7 for emacs-devel@gnu.org; Tue, 21 Jun 2011 04:44:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QYwZM-00060x-BD for emacs-devel@gnu.org; Tue, 21 Jun 2011 04:44:26 -0400 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:33606) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYwZ4-0005zq-DS; Tue, 21 Jun 2011 04:44:06 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 715FC3FA0514; Tue, 21 Jun 2011 17:44:02 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id E043A1A26EF; Tue, 21 Jun 2011 17:44:05 +0900 (JST) In-Reply-To: X-Mailer: VM 8.1.93a under 21.5 (beta31) "ginger" cd1f8c4e81cd XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.223 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:140766 Archived-At: Eli Zaretskii writes: > However, I'm not sure what you are suggesting to rethink, > specifically. What I said is that in foo<1>, the "<1>" part is not a > markup, it's just part of a string that is a buffer name. Well, it's not markup in the sense of HTML (ie, display markup), but it is markup in the sense of XML (semantic markup). It's true that the appended string is arbitrary, and that the relationship to the "desired" buffer name is quite arbitrary (you could use alphabetic characters instead of numerals, for example). But it is used to disambiguate what to the user would otherwise be identical names, and the specific form clearly indicates that this is "metadata". Buffers on main.c and main.c~ clearly represent files with different names, while main.c and main.c<2> by convention represent files with the same name. It is this convention, not the use of "<>", that makes the uniquifer "<1>" into markup. [Each run of plain text in a markup buffer should be treated as a separate "stream" of text for bidi display purposes, or something like that.] > And it will be, when Emacs is taught to reorder non-plain text. OK. > I never said nor thought that we should reorder markup text as if > it were plain text -- that'd be terribly wrong. > But the necessary infrastructure is not yet in Emacs, and it won't be > there in time for Emacs 24.1. OK, that's what I wanted to say myself, but it wasn't clear to me that was your reasoning. > There's no major mode here to help us DTRT with a string that is part > of the mode line. Sure there is, "mode line mode". ;-) Mode lines have a syntax, and so do buffer-names (when uniquifying). The fact there there's no major mode we use in buffers that's like that is not really relevant. Of course if you paste a buffer-name into a buffer in some major mode, you may run into problems. But that's always the case when changing syntax models on the same object. > > However, this is an implementation detail. If life is easier if you > > consider every textual object (buffer or string) as a single stream to > > which the bidi algorithm should be applied, there's nothing wrong with > > that, either. > > Well, that won't solve the problem of displaying markup languages and > program sources, so it cannot be that simple ;-) That's exactly the kind of thing where (at least for the next year or so) I'm just gonna have to trust you. :-)