From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: bidi-display-reordering is now non-nil by default Date: Thu, 18 Aug 2011 13:13:40 -0400 Message-ID: <87k4aaej7f.fsf@stupidchicken.com> References: <4E48D309.6050503@acdlabs.ru> <83hb5jujjs.fsf@gnu.org> <874o1j10zv.fsf@fencepost.gnu.org> <8362lyvcli.fsf@gnu.org> <87fwl2r0l4.fsf@stupidchicken.com> <83zkjatnkz.fsf@gnu.org> <877h6et8oi.fsf@stupidchicken.com> <83vctxua2y.fsf@gnu.org> <87r54le4rd.fsf@stupidchicken.com> <8362lxtfeb.fsf@gnu.org> <87d3g56llz.fsf@stupidchicken.com> <8339h0tur0.fsf@gnu.org> <87ippvwtwx.fsf@stupidchicken.com> <83liurruz4.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1313687631 9044 80.91.229.12 (18 Aug 2011 17:13:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 18 Aug 2011 17:13:51 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 18 19:13:47 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 1Qu6A6-00076f-UZ for ged-emacs-devel@m.gmane.org; Thu, 18 Aug 2011 19:13:47 +0200 Original-Received: from localhost ([::1]:43061 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qu6A6-0006Pq-FA for ged-emacs-devel@m.gmane.org; Thu, 18 Aug 2011 13:13:46 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:48627) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qu6A4-0006Pl-Lj for emacs-devel@gnu.org; Thu, 18 Aug 2011 13:13:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qu6A3-0003lN-PG for emacs-devel@gnu.org; Thu, 18 Aug 2011 13:13:44 -0400 Original-Received: from vm-emlprdomr-04.its.yale.edu ([130.132.50.145]:41442) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qu6A2-0003l9-F4; Thu, 18 Aug 2011 13:13:42 -0400 Original-Received: from furball (dhcp-128-36-14-148.central.yale.edu [128.36.14.148]) (authenticated bits=0) by vm-emlprdomr-04.its.yale.edu (8.14.4/8.14.4) with ESMTP id p7IHDet3030863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 18 Aug 2011 13:13:41 -0400 In-Reply-To: <83liurruz4.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 18 Aug 2011 11:21:03 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-Scanned-By: MIMEDefang 2.71 on 130.132.50.145 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.132.50.145 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:143412 Archived-At: Eli Zaretskii writes: > What happens next is the redisplay engine realizes that the stop > position was missed, so it scans back to find the last "stop position" > preceding `E' (since there could be other text properties or overlays > in-between), and then handles it using the handlers in it_props[]; see > handle_stop_backwards for how this is done. Then it can deliver `E' > with the right attributes, and continue delivering all the successive > characters, until it crosses some "stop position" again, either going > forward or backward. Thanks for the explanation; I think I understand the problem. But if this is a fundamental limitation, that would be extremely disappointing. The use of HTML spans for bidi segmentation is (IIUC) fairly well-known, and character properties are the most straightforward analog in Emacs. Here's another rough idea: when handle_stop is computing the next stop position, it could call another function (analogous to compute_stop_pos) to find and record the boundary of the next bidi-segmenting character property---i.e. a "bidi stop position". Then the reordering function could look at this to help figure out the segmentation breaks, thus avoiding advancing past this position. Would something like that work? > Amount of work is the least of my concerns in this regard. I'm > worried about the effect the temporarily incorrect display will have > on users. I don't recall the last time I ran into a problem with deferred font-lock. I seriously doubt this is a real issue.