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: Long lines and bidi [Was: Re: bug#13623: ...] Date: Fri, 08 Feb 2013 18:05:47 +0200 Message-ID: <831ucq94f8.fsf@gnu.org> References: <877gmp5a04.fsf@ed.ac.uk> <83vca89izh.fsf@gnu.org> <5110906D.7020406@yandex.ru> <83fw1aac3d.fsf@gnu.org> <51120360.4060104@yandex.ru> <51127363.5030203@yandex.ru> <834nhp9u9j.fsf@gnu.org> <5114FEBB.8020201@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1360339598 5304 80.91.229.3 (8 Feb 2013 16:06:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Feb 2013 16:06:38 +0000 (UTC) Cc: dmantipov@yandex.ru, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 08 17:06:58 2013 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 1U3qTT-0003hT-Ai for ged-emacs-devel@m.gmane.org; Fri, 08 Feb 2013 17:06:51 +0100 Original-Received: from localhost ([::1]:42183 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3qTA-0006UN-B0 for ged-emacs-devel@m.gmane.org; Fri, 08 Feb 2013 11:06:32 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:59185) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3qT6-0006Tk-GB for emacs-devel@gnu.org; Fri, 08 Feb 2013 11:06:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U3qT1-0005OT-Gs for emacs-devel@gnu.org; Fri, 08 Feb 2013 11:06:28 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:58475) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3qT1-0005OG-8w for emacs-devel@gnu.org; Fri, 08 Feb 2013 11:06:23 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MHW00M00SJ00N00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Fri, 08 Feb 2013 18:05:47 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MHW00M0WSPN0G20@a-mtaout20.012.net.il>; Fri, 08 Feb 2013 18:05:47 +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:156893 Archived-At: > From: Stefan Monnier > Cc: Eli Zaretskii , Emacs development discussions > Date: Fri, 08 Feb 2013 10:33:08 -0500 > > > So the first question is: is it feasible/possible/desirable to detect > > that the buffer has no R2L text at all and automatically force > > bidi-paragraph-direction to left-to-right and bidi-display-reordering > > to nil? > > Would this speed things up by a constant factor, or would it actually > remove an O(N) factor? The former, because the bidi iteration is slower than the original unidirectional one by a constant factor, on the average. > I think a fix will need more than a constant factor speed up. Indeed. > Did you check both the truncate-lines=nil and the truncate-lines=t cases? > I think that for the truncate-lines=t case, we won't be able to avoid > the O(linelength) slowdown (but we should try and skip the non-displayed > part of lines faster, especially when there's no > `display/after/before-string' property). The problem is not with the part of text we actually display, because the number of characters shown in a window does not depend on whether we have truncate-lines=t or nil. The problem is that most redisplay operations always scan some text that is eventually not shown in the window. The longer the lines, the more text we scan that is outside of the window. For example, any redisplay that needs to scroll the window up (M-v etc.) needs to find the buffer position for the window start. To do that, we use move_it_vertically_backward, which moves N screen lines up (back) in the buffer. But what that function does is move N _buffer_lines_ back, and then moves forward by screen lines to find which position is N screen lines above where we started. If each line is hundreds or thousands of characters, it is clear that moving back N buffer lines will move much more than needed, and thereafter moving by screen lines back through all those thousands of characters wastes a lot of CPU cycles.