Re: Redisplay: NS port, high CPU load

[Eli Zaretskii <eliz@gnu.org>]

> From: David Reitter <david.reitter@gmail.com>
> Date: Tue, 14 Jun 2016 20:07:01 +0800
> Cc: Anders Lindgren <andlind@gmail.com>,
>  Alan Third <alan@idiocy.org>,
>  emacs-devel@gnu.org
> 
> OK, I looked into this.  I don’t have time right now for a recipe, but what’s happening is that I’m loading (my version of) tabbar.el, which does this:
> 
> (add-hook 'first-change-hook 'tabbar-window-update-tabsets-when-idle)
> 
> Only when first-change-hook is set are those extraneous toolbar refreshes made.  The tabbar-window-update function at some point calls  (force-window-update (window-buffer)), which may be what triggers the toolbar refresh.

OK, thanks, this explains everything.  Indeed, calling
force-window-update will cause the tool bar to be redisplayed.

> So, I think that we should think about disabling hooks such as buffer-list-update-hook, first-change-hook, kill-buffer-hook, for temporary buffers.  In my view it just does not make sense to run the hooks for temporary buffers in any sensible scenario.

I'm not sure I agree.  Forcing redisplay for such buffers might not
make sense in most situations (though again, I'm not sure it makes no
sense at all), but a hook could do anything at all, and I see no
reason to summarily disable it in such buffers.  I think it's up to
the hook function to be selective if needed.

> I also think that this change might affect some modes, if only by triggering bugs.  Therefore I would argue that the change to ucs-normalize is the minimal change to fix my bug, and a good housekeeping change in general.

I'm okay with the change in ucs-normalize, but I don't think we should
do that on the release branch.  The situation you describe is quite
specialized, and the solution that avoids excess redisplay is to make
the hook function more selective about the buffer in which it runs.

So I think we are okay with the change you committed to master, and
this bug could otherwise be closed.

Thanks for looking into this.