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,gmane.emacs.bidi Subject: Now: Paragraph Direction Detection and Harmonization -- Was: Re: Bidirectional editing in Emacs -- main design decisions Date: Tue, 26 Apr 2011 10:22:39 +0900 Message-ID: <87sjt5ajs0.fsf@uwakimon.sk.tsukuba.ac.jp> References: <83bpkgl113.fsf@gnu.org> <8362qbsj7p.fsf@gnu.org> <83y636grgj.fsf@gnu.org> <838vuy9prx.fsf@gnu.org> <834o5m9mxs.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: dough.gmane.org 1303780625 22821 80.91.229.12 (26 Apr 2011 01:17:05 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 26 Apr 2011 01:17:05 +0000 (UTC) Cc: Eli Zaretskii , emacs-bidi@gnu.org, emacs-devel@gnu.org To: Mohsen BANAN Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 26 03:17:01 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 1QEWtg-00009O-Kh for ged-emacs-devel@m.gmane.org; Tue, 26 Apr 2011 03:17:00 +0200 Original-Received: from localhost ([::1]:54347 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEWtg-0005Mn-3t for ged-emacs-devel@m.gmane.org; Mon, 25 Apr 2011 21:17:00 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:59060) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEWte-0005Mh-2S for emacs-devel@gnu.org; Mon, 25 Apr 2011 21:16:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QEWtc-0003vL-VJ for emacs-devel@gnu.org; Mon, 25 Apr 2011 21:16:58 -0400 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:44835) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEWtZ-0003u9-Mx; Mon, 25 Apr 2011 21:16:54 -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 84F513FA0596; Tue, 26 Apr 2011 10:16:50 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id EFE261A304E; Tue, 26 Apr 2011 10:22:39 +0900 (JST) In-Reply-To: X-Mailer: VM 8.1.93a under 21.5 (beta29) "garbanzo" eac2e6bd5b2c+ 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:138772 gmane.emacs.bidi:877 Archived-At: Mohsen BANAN writes: > Eli> So the Emacs display is correct, is that > Eli> what you are saying? > > I am saying that emacs display is correct Oh, why is there no period here? > but that there are interoperability problems. Please, let's not go there. We know one good path (not perfect, but good) to interoperability: Implement UTR#9. The other paths are the road to interoperability hell, most likely. So it's too bad for the users of the other application, then, unless they're programmers capable of hacking the code themselves. As a 20-year veteran of the Japanese interoperability disaster, which was two decades in progress when I joined it and which continues to this very day, please, have patience, for five years if it takes that long. (< 5 40) => t! The thing is, every concession to broken implementations delays true harmony (by which I mean "reliable interoperability", not "pedantic standards conformance"). Not to mention strengthening proprietary software, which often seeks to exploit the "tippiness" induced by interoperability problems. > The nature of bidi text is such that it demands > harmony. True, but overly specific. s/bidi// ;-) Everybody thinks their problem is special. Of course it is in one way, but in another, it's not. > Eli> I don't care about Firefox > > I have a different view. I see Emacs and Firefox as joint sisters. Of course users care. But user wishes don't generate code. Eli cares about users; he's proved that amply over the years. So if he says he "doesn't care", that's not just making obscene gestures at the users, that's his expert judgment that it's not worth doing. He may not be able to "prove" it, but his expertise is proven to me by 2 decades of acquaintance. If you have the ability to code, Eli will help. I can testify to that, too. But "don't care" means Eli isn't going to do it himself, it's too much work compared to the gains possible by working on other areas. And it's not like the Firefox developers don't care, either. It would be much better to concentrate on lobbying them. They *want* to be correct, and will be made happier once Firefox conforms to the standard. > I think the solution is to generate html and > specify paragraph direction explicitly in html. That's OK IMO, although somewhat undesirable. (It will slow the adoption of correct and full implementations of the bidi algorithm.) That's not an Emacs problem, though. That's an MUA problem. I guess you're talking to the right person on that, since RMail is still the official Emacs MUA, and Eli uses and (sometimes, at least) contributes to RMail. But if you want other people, who use a wide variety of MUAs, to do it that way, you'll need to talk to larsi and/or Ted Zlatanov (Gnus/message-mode) and Uday Reddy (VM), at least. > Beyond the basic bidi capability in emacs, there > are several layers above it that we now need to > cultivate. +1 on that, though. I hope Eli will focus on that, personally. (But that's 'cause I'm a standards geek, so you can multiply that by about 0.1 importance factor -- I have no personal need for bidi, or experience with it. Someday ... :-)