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: Thu, 15 Apr 2010 00:38:16 -0400 Message-ID: References: <83y6gsy4i0.fsf@gnu.org> <83pr24xuio.fsf@gnu.org> <83bpdlyk9v.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 1271306406 16367 80.91.229.12 (15 Apr 2010 04:40:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 15 Apr 2010 04:40:06 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 15 06:40:05 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 1O2Gs0-0000Up-Uq for ged-emacs-devel@m.gmane.org; Thu, 15 Apr 2010 06:40:05 +0200 Original-Received: from localhost ([127.0.0.1]:34343 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O2Grz-0008QT-Vp for ged-emacs-devel@m.gmane.org; Thu, 15 Apr 2010 00:40:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O2GqR-00083B-Rt for emacs-devel@gnu.org; Thu, 15 Apr 2010 00:38:27 -0400 Original-Received: from [140.186.70.92] (port=50098 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O2GqP-00081p-JL for emacs-devel@gnu.org; Thu, 15 Apr 2010 00:38:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O2GqN-0007ey-RJ for emacs-devel@gnu.org; Thu, 15 Apr 2010 00:38:25 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:16395 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O2GqI-0007eG-FD; Thu, 15 Apr 2010 00:38:18 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAY1xktMCpxH/2dsb2JhbACbW3K+NIUNBIta X-IronPort-AV: E=Sophos;i="4.52,210,1270440000"; d="scan'208";a="60911320" Original-Received: from 76-10-156-71.dsl.teksavvy.com (HELO pastel.home) ([76.10.156.71]) by ironport2-out.pppoe.ca with ESMTP; 15 Apr 2010 00:38:17 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id B6D197F1B; Thu, 15 Apr 2010 00:38:16 -0400 (EDT) In-Reply-To: <83bpdlyk9v.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 14 Apr 2010 21:13:48 +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:123682 Archived-At: > I started looking at what nhexl-mode does, and I'm puzzled by the > logic of its design. Why do you arrange for nhexl-jit to be called > via fontification-functions, if you also have it on post-command-hook? > Is one of them a remnant of an idea that was rejected? if so, which > one? If you really do need both, can you explain why? AFAIK I need both: nhexl-jit is used to add the hexdump lines to all the text that's displayed, whereas the post-command-hook is used to update the cursor highlighting (which is why it only updates the overlays on the old point position and the new point position). I guess the cursor updating could be more efficient by only changing the `face' text-properties on the overlay's before strings rather than building new overlays from scratch. I haven't tried that yet, but I'm afraid this will lead to problems because the redisplay code won't notice that a before-string was modified so it may forget to redisplay the corresponding part of the screen. > If invoking nhexl-jit via fontification-functions is really needed, > then where do you expect redisplay to invoke it? IOW, if you make > assumptions regarding the value of START and END arguments passed to > nhexl-jit by redisplay, what are those assumptions? I don't make any particular assumptions about start and end (at least not consciously). >> The behavior I see seems consistent with a situation where the redisplay >> "doesn't see" the newlines in the before-strings > I don't see any sign that redisplay "doesn't see" the newlines. I only say that because the performance behavior is very similar to what we get in long-single-line buffers. > The mere fact that you see several lines on the screen is the proof > that redisplay did see the newlines: that's how it knows that one line > ends and another begins. Yes, clearly it sees them in this sense. Stefan