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: Bidirectional text and URLs Date: Sat, 06 Dec 2014 14:59:15 +0200 Message-ID: <83y4qlylwc.fsf@gnu.org> References: <87a93cngwv.fsf@uwakimon.sk.tsukuba.ac.jp> <837fyfml31.fsf@gnu.org> <874mtio7wh.fsf@uwakimon.sk.tsukuba.ac.jp> <83r3wml8kq.fsf@gnu.org> <83zjb9an0q.fsf@gnu.org> <831toka82r.fsf@gnu.org> <83oaro8km7.fsf@gnu.org> <83k32b6u5l.fsf@gnu.org> <83h9xf6rzs.fsf@gnu.org> <83wq6a5c1q.fsf@gnu.org> <83lhmo63a9.fsf@gnu.org> <83vblr4uqi.fsf@gnu.org> <83zjb22v4n.fsf@gnu.org> <83388t3czq.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1417870783 22030 80.91.229.3 (6 Dec 2014 12:59:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Dec 2014 12:59:43 +0000 (UTC) Cc: larsi@gnus.org, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 06 13:59:35 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XxExS-0004OB-Gw for ged-emacs-devel@m.gmane.org; Sat, 06 Dec 2014 13:59:34 +0100 Original-Received: from localhost ([::1]:54258 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxExS-00039B-2l for ged-emacs-devel@m.gmane.org; Sat, 06 Dec 2014 07:59:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38512) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxExJ-00038C-HP for emacs-devel@gnu.org; Sat, 06 Dec 2014 07:59:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XxExD-0006Zi-Iv for emacs-devel@gnu.org; Sat, 06 Dec 2014 07:59:25 -0500 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:36374) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxExD-0006Zc-5J; Sat, 06 Dec 2014 07:59:19 -0500 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NG500600VHC8F00@mtaout24.012.net.il>; Sat, 06 Dec 2014 14:51:32 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NG500198VPWMF40@mtaout24.012.net.il>; Sat, 06 Dec 2014 14:51:32 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.180 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:179173 Archived-At: > Date: Sat, 06 Dec 2014 07:06:50 -0500 > From: Richard Stallman > CC: larsi@gnus.org, emacs-devel@gnu.org > > > > In principle they might vary, but in practice I think most of them > > > will use the characters in the order they appear in the buffer. > > > That's true, but that still doesn't say how should each application > > show that to the user. > > I don't entirely understand what sort of variation you have in mind, > but I think we should make all such applications handle this > as uniformly as possible. The danger in using such obfuscated strings is different in each application. That's because each application assigns different semantics to the various portions of the string, and does different things with each portion. IOW, the semantics of these strings depends on the application, and thus our solution to warn the user about the dangers is probably going to be different in each case. Until now we had only one use case: the URL. For that use case, we understood the implications, and we now have the infrastructure to detect the obfuscation. We still don't know what will the application using URLs (in this case, eww) want to do to warn the user and ask for their permission. One way is to show the "real" URL to the user, which will automatically solve the obfuscation problem and display the URL in its "normal" form -- without the need to turn off the bidi reordering. Maybe there are other, better ways -- we just need to wait and see. And that's just a single application for which we have a use case we understand quite well. Other use cases are yet to come. When they do, we should analyze them as we did with this one. It could be that eventually we come to the conclusion you are proposing now: that we need a way to display some string in its logical order of characters. If and when we arrive to such a conclusion, there will be sufficient weight to it to justify the change in the code. We are not there yet, and it is not clear to me that we will indeed arrive at that conclusion. We have at least partial evidence that this might not be required: no other application out there does this, AFAIK.