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 13:34:35 -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 1271361833 28939 80.91.229.12 (15 Apr 2010 20:03:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 15 Apr 2010 20:03:53 +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 22:03:51 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 1O2VHu-0008Gz-U7 for ged-emacs-devel@m.gmane.org; Thu, 15 Apr 2010 22:03:47 +0200 Original-Received: from localhost ([127.0.0.1]:48763 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O2VHu-0005Lp-EZ for ged-emacs-devel@m.gmane.org; Thu, 15 Apr 2010 16:03:46 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O2VGI-0004aj-9f for emacs-devel@gnu.org; Thu, 15 Apr 2010 16:02:06 -0400 Original-Received: from [140.186.70.92] (port=38883 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O2VGG-0004ZK-JR for emacs-devel@gnu.org; Thu, 15 Apr 2010 16:02:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O2VGE-00015w-N5 for emacs-devel@gnu.org; Thu, 15 Apr 2010 16:02:04 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:46082) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O2Sxa-0006f1-0Q; Thu, 15 Apr 2010 13:34:38 -0400 Original-Received: from ceviche.home (faina.iro.umontreal.ca [132.204.26.177]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id o3FHYakL009614; Thu, 15 Apr 2010 13:34:36 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id D57AAB42CC; Thu, 15 Apr 2010 13:34:35 -0400 (EDT) In-Reply-To: (Eli Zaretskii's message of "Thu, 15 Apr 2010 07:05:57 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3514=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:123721 Archived-At: > post-command-hook also invokes nhexl-jit, albeit with different > arguments. So you may end up doing double work. That is true. But I don't know how to avoid it, and I don't think this redundancy is a big problem in practice. > Is it really the case that modifying an overlay string does not > trigger redisplay? That'd be a bug. If it works I don't know how it's implemented. But I haven't actually tried it anyway. >> > 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). > But then you should be aware that there's nothing in > fontification-functions or in the redisplay that makes sure they are > only invoked on the displayed portion of the buffer. Indeed, and the nhexl-jit part of the code itself doesn't make any such assumption: it just fontifies whatever jit-lock deems useful/necessary. The part where I make such an assumption (which turns out to be unwarranted because of the bug we're tracking) is in nhexl-flush-overlays where I assume that I can throw away the overlays that are currently not displayed without causing them to be immediately rebuilt by jit-lock. > As your C-v experiment proves, it really happens that nhexl-jit is > invoked on portions of the buffer that are outside the window. > And since nhexl-jit does not validate its arguments against window's > first and last line, it ends up doing unnecessary work. When jit-lock asks for part of a buffer to be fontified, it would be a bug for nhexl-jit (or font-lock-fontify-buffer for that matter) to not fontify it (because the corresponding piece of text is then labeled as `fontified' and if it gets displayed later on jit-lock won't be triggered so nhexl-jit won't have a chance to change its mind and fontify it after all). So it's not up to nhexl-jit to decide whether it's necessary or not. Stefan