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: Mon, 01 Dec 2014 18:18:23 +0200 Message-ID: <837fyb8htc.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> <87zjb8n6th.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1417450729 11358 80.91.229.3 (1 Dec 2014 16:18:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Dec 2014 16:18:49 +0000 (UTC) Cc: stephen@xemacs.org, 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 Mon Dec 01 17:18:42 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 1XvTgL-0006Cz-P1 for ged-emacs-devel@m.gmane.org; Mon, 01 Dec 2014 17:18:37 +0100 Original-Received: from localhost ([::1]:60752 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvTgL-00075t-7l for ged-emacs-devel@m.gmane.org; Mon, 01 Dec 2014 11:18:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44657) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvTgB-00075E-RI for emacs-devel@gnu.org; Mon, 01 Dec 2014 11:18:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XvTg3-0002lY-H7 for emacs-devel@gnu.org; Mon, 01 Dec 2014 11:18:27 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:54021) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvTg3-0002lF-8g; Mon, 01 Dec 2014 11:18:19 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NFW00M00VWMVS00@a-mtaout22.012.net.il>; Mon, 01 Dec 2014 18:18:18 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NFW00MBUVYHMD50@a-mtaout22.012.net.il>; Mon, 01 Dec 2014 18:18:18 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:178588 Archived-At: > Date: Mon, 01 Dec 2014 05:18:07 -0500 > From: Richard Stallman > CC: eliz@gnu.org, larsi@gnus.org, emacs-devel@gnu.org > > 1. There are magic bidi characters inside the URL. By "magic bidi characters" do you mean printable characters from RTL scripts, or do you mean the directional controls? (RTL characters are also "magic" in some sense, because they might cause reordering of surrounding text, e.g. if it contains numerical characters.) > 2. The bidi context of the URL could cause the URL to appear strangely > even though the URL itself does not contain any magic bidi characters. > > Mixing up these two cases has caused a lot of confusion in this > discussion. Things said about one of them were mistakenly applied to > the other, resulting in nonsense. > > I proposed checking the URL for bidi magic, for case 1, and someone > interpreted the suggestion based on case 2 and said it would be > ineffective. I, for one, don't understand how would such a check help us. As I wrote elsewhere, at least some parts of a legitimate URL can include such characters, and we shouldn't treat those as suspicious. Maybe you are talking only about some parts of the URL, like the host and the domain. > For case 2 I proposed the user could insert newlines around the URL to > see what it really says. Someone replied that this would be > ineffective because he interpreted it based on case 1. I think it's impractical to insert newlines before and after each URL. It will make Web pages and HTML mail all but illegible, because modern Web text includes URLs in the normal flow of text, which will be interrupted by these newlines. We might do that for URLs where we detect an attempt at spoofing/phishing, but once those are detected, there are better methods to undo the effects of phishing. They were suggested earlier in this thread, let me reiterate the alternatives: . modify the way the relevant directional controls are displayed to make them prominently apparent . allow the user to request a temporary display of the URL in its original logical order, before the reordering, or maybe do that automatically in a tooltip . replace the relevant directional controls with percent-hex encoded representation, which will as result disable the reordering . cover the relevant directional controls with a display property (e.g., with a display string " "), which will also disable reordering Let's pick up one of these alternatives and use it, or maybe allow the users choose any one of them.