From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Inefficient redisplay Date: Mon, 12 Apr 2010 15:28:22 -0400 Message-ID: References: <83y6gsy4i0.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1271100521 25696 80.91.229.12 (12 Apr 2010 19:28:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 12 Apr 2010 19:28:41 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 12 21:28:39 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O1PJE-0004ha-UB for ged-emacs-devel@m.gmane.org; Mon, 12 Apr 2010 21:28:37 +0200 Original-Received: from localhost ([127.0.0.1]:38639 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1PJE-0003FN-BJ for ged-emacs-devel@m.gmane.org; Mon, 12 Apr 2010 15:28:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O1PJ9-0003F2-Dp for emacs-devel@gnu.org; Mon, 12 Apr 2010 15:28:31 -0400 Original-Received: from [140.186.70.92] (port=43521 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1PJ7-0003EX-Di for emacs-devel@gnu.org; Mon, 12 Apr 2010 15:28:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O1PJ6-0002Cz-4m for emacs-devel@gnu.org; Mon, 12 Apr 2010 15:28:29 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:30795 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1PJ1-0002AB-Ia; Mon, 12 Apr 2010 15:28:23 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOIQw0tMCqWu/2dsb2JhbACbO3K9JIJagjIEi0Y X-IronPort-AV: E=Sophos;i="4.52,192,1270440000"; d="scan'208";a="60699703" Original-Received: from 76-10-165-174.dsl.teksavvy.com (HELO pastel.home) ([76.10.165.174]) by ironport2-out.pppoe.ca with ESMTP; 12 Apr 2010 15:28:22 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 2C0E57F1B; Mon, 12 Apr 2010 15:28:22 -0400 (EDT) In-Reply-To: <83y6gsy4i0.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 12 Apr 2010 20:17:43 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:123536 Archived-At: >> One related problem (which can be witnessed firsthand from Elisp) is >> that all the text between point-min and the window's point is jit-locked >> (even though only the text visible in the window should need to be >> jit-locked). > I believe this is because of the following heuristics in jit-lock.el: > ;; Decide which range of text should be fontified. > ;; The problem is that START and NEXT may be in the > ;; middle of something matched by a font-lock regexp. > ;; Until someone has a better idea, let's start > ;; at the start of the line containing START and > ;; stop at the start of the line following NEXT. > (goto-char next) (setq next (line-beginning-position 2)) > (goto-char start) (setq start (line-beginning-position)) No, the trace I showed was for jit-lock-function which comes before this piece of code (jit-lock-function calls jit-lock-fontify-now). And even if that had some impact, it wouldn't explain the behavior, since line-beginning-position works fine: it find the buffer's \n chars and stops there, oblivious to the fact that they have a `display' property which makes them appear differently. >> This makes nhexl-mode completely unusable except on small buffers > I suggest, first of all, to understand why the display engine misses > the newlines you say you have in the before-strings. Given my lack of understanding of the redisplay code, this is more difficult. > The Emacs display code is known to behave very unfriendly when lines > are too long, so my first advice would be not to do what hurts. The buffer's actual text doesn't have long lines, and the display doesn't have long lines either, so it really *should* work fine. And of course there isn't much I can do about it: the whole point of the exercise is to make a hexl-mode variant which works only by modifying the display but not the buffer's text (so it doesn't mess with the undo-list, etc...). Stefan