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 05:45:07 +0200 Message-ID: <83iohw824c.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1417405553 13019 80.91.229.3 (1 Dec 2014 03:45:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Dec 2014 03:45:53 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lars Magne Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 01 04:45:47 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 1XvHvm-0006Sb-WD for ged-emacs-devel@m.gmane.org; Mon, 01 Dec 2014 04:45:47 +0100 Original-Received: from localhost ([::1]:52644 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvHvm-0005Ng-MM for ged-emacs-devel@m.gmane.org; Sun, 30 Nov 2014 22:45:46 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54360) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvHvD-0005Dz-68 for emacs-devel@gnu.org; Sun, 30 Nov 2014 22:45:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XvHv7-0004nQ-8h for emacs-devel@gnu.org; Sun, 30 Nov 2014 22:45:11 -0500 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:54354) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvHv6-0004k6-SW for emacs-devel@gnu.org; Sun, 30 Nov 2014 22:45:05 -0500 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NFV00200WAZ2000@mtaout28.012.net.il> for emacs-devel@gnu.org; Mon, 01 Dec 2014 05:42:36 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NFV00I9YWZ0G090@mtaout28.012.net.il>; Mon, 01 Dec 2014 05:42:36 +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.184 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:178560 Archived-At: > From: Lars Magne Ingebrigtsen > Cc: emacs-devel@gnu.org > Date: Sun, 30 Nov 2014 22:36:41 +0100 >=20 > Eli Zaretskii writes: >=20 > > Can we please take a step back and try to identify the real probl= em > > here? What exactly are we trying to detect and handle? Is it tr= ue > > that we are trying to detect URLs whose characters got their "nor= mal" > > bidirectional properties overridden by some directional control > > characters? If so, I can write a primitive that will take a regi= on of > > buffer text and examine it to detect this. >=20 > Oh, great. My impression was that such functionality was off the t= able. Why would it be off the table? Anyway, if you want this, please show the API of the function -- what it should return and how. > > Next, given that you have detected the spoofed URL, what do you w= ant > > to do with it? Do you want to highlight it, do you want to de-sp= oof > > (i.e. undo the spoofing) in some way, but still leave some indica= tion > > of the fact that it was spoofed, or maybe you want to remove any = trace > > of the spoofing as if it never happened (and leave the user obliv= ious > > to the fact it did)? >=20 > Yes, I want to unspoof the URL. Adding some markings to notify tha= t > this has been done would also be nice, perhaps by adding a 'warning= face > to the text or the like. Then putting a display property on the offending RLO might be the bes= t solution. > > Given the answers to those questions, there's any number of possi= ble > > solutions that do NOT require inserting more directional controls= . > > Some of the possible solutions were already mentioned in this thr= ead. > > Here's another: cover the offending RLO with a display property > > showing whatever you want -- a warning sign, a smiley, a string m= ade > > of a SPC character, anything. You can try it with your example: = you > > will see the spoofing gone immediately. Why is this worse than > > inserting directional controls whose effect on the surrounding te= xt > > can be far reaching? >=20 > RLOs are used legitimately, and I think they display you've selecte= d for > them now (a thin blank line) is good. Yes, but adding RLOs or LROs just to undo some evil effect is something I think we should avoid, because its effect is non-local an= d can frequently be surprising and unintended. It is better to use other means we have. > So I don't want to uglify mail mode buffers just to handle this > quite obscure URL UI problem. Where do you see uglification in my suggestions? > (Ok, bad example, but these overrides are used legitimately in the = bidi > community, if I understand my extensive research correctly.) They are meant for very specific situations, and this one isn't one o= f them. > And displaying =E2=80=AEhttp://myspace.com/#/segami/moc.koobecaf//:= sptth=E2=80=AC with a > couple of visible control characters doesn't really solve the probl= em, > because most people will still assume that that's a link to Faceboo= k, > not to Myspace. Most people are not even aware that this bidi stuf= f > exists. Under my suggestion to cover the overrides with a display property, the URL will not be reversed on display. Did you try that?