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 21:34:46 +0200 Message-ID: <83k32b6u5l.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 X-Trace: ger.gmane.org 1417462524 18839 80.91.229.3 (1 Dec 2014 19:35:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Dec 2014 19:35:24 +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 Mon Dec 01 20:35:17 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 1XvWke-0007IE-VR for ged-emacs-devel@m.gmane.org; Mon, 01 Dec 2014 20:35:17 +0100 Original-Received: from localhost ([::1]:33553 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvWke-0003wV-Cy for ged-emacs-devel@m.gmane.org; Mon, 01 Dec 2014 14:35:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39233) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvWkC-0003lQ-4a for emacs-devel@gnu.org; Mon, 01 Dec 2014 14:34:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XvWk6-0003bM-7T for emacs-devel@gnu.org; Mon, 01 Dec 2014 14:34:47 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:50829) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvWk5-0003ah-WF; Mon, 01 Dec 2014 14:34:42 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NFX00M004TNP000@a-mtaout20.012.net.il>; Mon, 01 Dec 2014 21:34:39 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NFX00MFU51RF870@a-mtaout20.012.net.il>; Mon, 01 Dec 2014 21:34:39 +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.166 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:178638 Archived-At: > Date: Mon, 01 Dec 2014 14:15:41 -0500 > From: Richard Stallman > CC: larsi@gnus.org, emacs-devel@gnu.org > > 1. A way for a Lisp program to get, for a specified region, a > short description of the outside bidi context that affects bidi > treatment of that region. > > The result should be a small amount of data, computed solely from the > text outside the specified region. The result should encapsulate > everything about the text outside the specified region that can > possibly affect the bidi treatment of whatever text might be inside > the region. > > Thus, any change in the text outside the specified region, which gives > the same encapsulated data, will not affect bidi treatment of text > inside the region. > > Ideally, this data should have a transparent documented format. > > It could be called 'bidi-context'. > > If this can't be done in a way that is independent of the text inside > the specified region, as a fallback it could be done in a way that > works only for the current text inside that region. > > 2. Given such encapsulated context data, a straightforward way to > create an equivalent bidi context in the current buffer. I expect it > would work by inserting some magic bidi characters. (Can all such > contexts be replicated by inserting some magic bidi characters?) > > It could be called 'replicate-bidi-context'. > > Are these feasible to implement? The first one sounds pretty complicated. I need to think about its feasibility. It could require analysis of a very large chunk of buffer text, at least in theory. What's more, the UBA specifies how to reorder text given the contents, but not how to do the reverse. Anyway, what's more important: you can have 2 without 1. The trick is to capture the visual order of the text you want to copy (can be done by looking at the current glyph matrix), and then create a string whose logical order is identical to the captured visual order, and embed that string in LRO..PDF, which will ensure the visual order will not change on display. The disadvantage of this is that you recreate the order, but not the reordering, so e.g. cursor motion will be different -- you won't see the jumps as in the URL phishing example.