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: Yet another redisplay question Date: Tue, 06 Aug 2013 19:42:34 +0300 Message-ID: <83siymvkhx.fsf@gnu.org> References: <51FB93C5.1020804@yandex.ru> <83bo5gyytp.fsf@gnu.org> <51FF378D.9000305@yandex.ru> <83siyow4i6.fsf@gnu.org> <83ob9cw04z.fsf@gnu.org> <5200A29C.6060704@yandex.ru> <8361vix46s.fsf@gnu.org> <52011E87.9060204@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1375807378 1314 80.91.229.3 (6 Aug 2013 16:42:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 6 Aug 2013 16:42:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 06 18:43:00 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 1V6kLb-0001ld-Kf for ged-emacs-devel@m.gmane.org; Tue, 06 Aug 2013 18:42:59 +0200 Original-Received: from localhost ([::1]:54881 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6kLb-0002GY-6G for ged-emacs-devel@m.gmane.org; Tue, 06 Aug 2013 12:42:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6kLT-0002G9-IL for emacs-devel@gnu.org; Tue, 06 Aug 2013 12:42:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V6kLM-0000rH-Q5 for emacs-devel@gnu.org; Tue, 06 Aug 2013 12:42:51 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:50804) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6kLM-0000oJ-Ge for emacs-devel@gnu.org; Tue, 06 Aug 2013 12:42:44 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MR400M00BQB2300@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Tue, 06 Aug 2013 19:42:26 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MR400LBJBQOVE50@a-mtaout22.012.net.il>; Tue, 06 Aug 2013 19:42:24 +0300 (IDT) In-reply-to: <52011E87.9060204@yandex.ru> 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:162450 Archived-At: > Date: Tue, 06 Aug 2013 20:04:23 +0400 > From: Dmitry Antipov > CC: emacs-devel@gnu.org > > AFAICS redisplay engine does a lot of iterator movements backward to BEGV > or forward to ZV. We don't currently have a way of moving the iterator backward, only forward. When we need to go back, we just scan through the text, and then re-seat the iterator at the new place and re-initialize it. > From the redisplay's point of view, how much of buffer text beyond > its visible boundaries (window-start) and (window-end) we should > process to be sure that the visible part is displayed correctly? It depends on what you mean by "redisplay". When the display engine has already decided where window-start should be, and is just redrawing the window, the answer is "none": it never processes any text outside of the visible portion of text. But in order to decide where the window should start, the display engine many times needs to look beyond the window edges. As a simple example, consider a case where point was moved to some arbitrary position outside of the window (e.g., with goto-char) -- how can the display engine know what should be the new window-start that will bring point back into view, when each line could be of different height? To do that, the display engine processes some text outside of the window until it finds buffer position that satisfies user requirements for this case (the various scroll-* variables). > In particular, when we're looking for the beginning of the previous line, > or the end of the current line, why not limit the search within the > visible part of text? Depends on why are we looking for the beginning of the line. Sometimes we can just start from the window-start position, in that case we don't need to search at all (because the window's start is part of the window object data). But if you want to know which character is the first character of the line (e.g., for determining the base direction of the paragraph for bidi display purposes), then you must go to the beginning of the line. Another example when you cannot stop at the beginning of the window is when you need to start from a known horizontal position, e.g. as part of vertical-motion: the only place in a line where the horizontal position is known in advance is the line's beginning. There are other cases. Search the sources for "start_display" -- almost all of its calls are needed to find buffer positions which satisfy some requirements, like given pixel coordinates. Many of these places examine text outside of the window, because at that point it is not yet known where the window will start and end. So to summarize, there are some cases where you cannot optimize these searches. Of course, looking for clever algorithms or caches that would optimize more cases than we have now is always welcome.